Key export method

Abstract

1. A computer-implemented method for deriving a key for a hierarchical key structure, the method being executed by a first party and comprising the steps of: generating a target index for a target child key, the target index being generated based on at least a first result of inputting the target message into a first hash function; and deriving a target child key for a level in the hierarchy of the key structure based on a) a parent key of a previous level in the hierarchy, and b) a second result of inputting at least i) the parent key and ii) the target index into a second hash function.

Description

[Technical Field]

[0001] This disclosure relates to methods for deriving child keys (e.g., private keys) of a hierarchical key structure from external state. For example, the keys may be used to sign blockchain transactions and / or generate blockchain addresses. [Background technology]

[0002] In the context of blockchain technology, a "wallet application" or simply a "wallet" typically refers to an application that is configured to store, among other things, a collection of keys (i.e., public keys and / or private keys) owned by a particular party.

[0003] To maintain privacy on a public blockchain, it is recommended to avoid reusing public keys that are derived from private keys. This can lead to wallets becoming collections of randomly generated private keys that need to be securely stored and frequently backed up to ensure that keys are not lost or stolen. By avoiding key reuse, this type of wallet can quickly create a "bag of keys" problem.

[0004] To improve the efficiency of key storage and regeneration and solve this bag of keys problem, hierarchical deterministic (HD) wallets were invented. HD wallets offer additional benefits in terms of privacy and the ability to share branches of a wallet with different systems or subsystems. This type of wallet can generate many keys from a single random seed and is the most common type of blockchain wallet in use today.

[0005] Wallet implementations generally follow Bitcoin Improvement Proposal 32 (BIP32), which describes how multiple child keys should be derived from a parent key. Some implementations also use BIP44, which defines the purpose of branches within a wallet. In HD wallet implementations, a master private key is derived from a random seed. This master private key is used to derive multiple generations of keys (children, grandchildren, etc.).

[0006] Figure 4 shows the resulting tree-like structure that appears in an HD wallet. This data structure is a powerful mechanism for managing the security of a wallet and its ability to restore funds during recovery. Depending on the implementation, a user (i.e., wallet owner) or observer can create a sequence of public keys without the corresponding private key. Because fewer secrets need to be stored, there is less risk of exposure. Additionally, if keys are lost, they can be restored from the seed key.

[0007] The formula for deriving a child key from a parent key depends on whether the parent public key or the parent private key is used as input to the derivation function, with use of the parent private key resulting in a "hardened" child key and use of the parent public key resulting in a "normal" (i.e., non-hardened, according to BIP32 terminology) child key.

[0008] Child keys are generated using a child key derivation (CKD) function. The specific form of the CKD function depends on the particular wallet implementation, but generally, child keys are based on a parent key and an index. The index allows a parent key to spawn multiple child keys; that is, a parent key may have multiple child keys. Typically, the index takes a value in a sequence, with the first child key of the parent key taking the first value in the sequence (e.g., 0), the second child key of the parent key taking the next value in the sequence (e.g., 1), and so on.

[0009] Note that, at the time of this writing, it is not possible to derive a hardened child public key with only knowledge of the parent public key and chain code. Requiring payments to be made to a regular child key means that the receiver can only reveal the parent public key (and chain code), and the sender can send payments by deriving multiple regular (i.e., non-hardened) child keys. In this way, the receiver of funds does not need to explicitly give each address to the sender. This ensures that multiple payments can be sent while minimizing communication between the same two parties and enhancing privacy when transacting on a public blockchain.

[0010] Normal child private key sk i The formula is sk i = sk par + HMAC512 L (c par , pk par || index) (1) and the hardened child private key sk i The formula for ' is sk i ' = sk par + HMAC512 L (c par , sk par || index') (2) and ·sk par is the parent's private key, ·pk par is the parent's public key, ·

[0011]

number

[0012] is the left 32 bytes of the result of the HMAC function using the SHA512 hash function, ·c par is the chain code of the parent key, and c par= HMAC-SHA512 R (c grandparent , P grandparent index par ) and index is a counter of the child keys that starts at 0 and increases each time a new child key is calculated. By convention, this is 0≦index<2 for normal keys. 31 and for the hardened key, 31 ≦index'<2 32 is. [Prior art documents] [Patent documents]

[0013] [Patent Document 1] UK Patent Application No. 1913667.0 [Non-patent literature]

[0014] [Non-Patent Document 1] https: / / nchain.com / 2019 / 10 / 22 / benfords-wallet / [Non-patent document 2] https: / / github.com / bitcoin / bips / blob / master / bip-0032.mediawiki [Non-patent document 3] https: / / github.com / bitcoin / bips / blob / master / bip-0043.mediawiki [Non-patent document 4] https: / / github.com / bitcoin / bips / blob / master / bip-0044.mediawiki Summary of the Invention [Problem to be solved by the invention]

[0015] A protocol known as "Benford's wallet" (see https: / / nchain.com / 2019 / 10 / 22 / benfords-wallet / and UK Patent Application No. 1913667.0) can be used to increase privacy. The idea behind this is to split the transaction output into multiple outputs, where the split follows Benford's Law under a sufficiently large dataset of these outputs. The aim of the wallet is to obfuscate the full amount of the payment, so that recurring payments of the same amount are hidden. However, to be able to prove the full amount of the payment to an auditor, Benford's wallet accounts for including external data, such as an invoice, in the calculation of the public key that receives the payment in this way. This means that data related to the invoice must be stored, reintroducing the bag of keys problem.

[0016] It is therefore desirable to incorporate external data into the derivation of child keys without reintroducing the bag of keys problem. [Means for solving the problem]

[0017] According to one aspect disclosed herein, there is provided a computer-implemented method for deriving a key for a hierarchical key structure, the key structure including a hierarchy of levels, the hierarchy of levels including a master level and one or more child levels, the master level including a master key, each child level including one or more child keys, each child key at a given level being linked to one key at a preceding level, the one key at the preceding level being a respective parent key for each child key, the method being performed by a first party and comprising the steps of: generating a target index for a target child key, the target index being generated based on a first result of inputting at least the target message into a first hash function; and deriving a target child key for a level in the hierarchy based on a) the parent key of the preceding level in the hierarchy, and b) a second result of inputting at least i) the parent key and ii) the target index into a second hash function.

[0018] The inventors of the present application have realized that it is advantageous to link a child key to external data. The external data will be generally referred to below as a "message," but this message need not be, but is not excluded from being, a message in the sense of a communication (e.g., email) between one or more parties. In general, a message may be any type of user- or machine-generated data item. The message is used to generate an index, which in turn is used to derive the child key. That is, embodiments of the present invention change the nature of the index—instead of taking the next unused value in a sequence, the index is now based on a hash of the message.

[0019] External data can now be included in the derivation of child keys, providing evidence to a third party (e.g., an auditor) that the child keys are linked to external data, such as invoices. Unlike Benford wallets, wallet restoration only requires the HD wallet seed. The method also facilitates hassle-free wallet migration without any extra work performed by the user or a different wallet provider. While not limited to any particular wallet protocol, the solution does not modify the HD wallet protocol specified in BIP32, but instead gives additional meaning to the index used to derive keys. Deterministically deriving wallet data files using seeds and messages provides several advantages in terms of wallet migration and restoration, which are currently limiting for wallet users. These are discussed in detail below.

[0020] It should be noted that while the exemplary use cases provided herein are primarily related to blockchain, the described embodiments apply broadly to the use of keys in any relevant context. For example, a child key may be used as a private key for generating digital signatures, which have applications in many fields of technology. As another example, a child key may be used as a cryptographic key in any context.

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

[0022] [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 3A]FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic mock-up diagram of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] 1 is a diagram showing a schematic tree-like structure of keys in an HD wallet. [Figure 5] FIG. 10 illustrates a schematic diagram of the generation of a child extended private key and chaincode. [Figure 6] FIG. 10 is a schematic diagram illustrating an exemplary child key derivation function for an HD wallet. [Figure 7] 1 is a diagram illustrating a schematic diagram of an exemplary system according to some embodiments of the present invention; [Figure 8] Schematic of an external data hierarchical deterministic (EDHD) wallet structure when using a random key index - the diagram shows how a random output (i.e., the key index of an EDHD wallet) is generated when a hash function is used on some input (i.e., external data). [Figure 9] FIG. 1 is a diagram illustrating a schematic of transactions generated according to Benford's Law. [Figure 10] FIG. 10 is a schematic diagram illustrating an example of an EDHD wallet structure in which key derivation branches are characterized by digital certificates. DETAILED DESCRIPTION OF THE INVENTION

[0023] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is tightly connected to the other blockchain nodes 104.

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

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

[0026] Each block 151 also contains a block pointer 155 that points backward to previously created blocks 151 in the chain, defining a sequential order up to block 151. Each transaction 152 (other than coinbase transactions) contains a pointer back to the previous transaction, defining an order in the sequence of transactions (note that sequences of transactions 152 are allowed to diverge). The chain of blocks 151 traces 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.

[0027] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. 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." This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. This term refers to an ordered set of transactions that a node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions that attempt to consume the same output.

[0028] For a given current transaction 152j, its (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is fulfilled or “consumed” in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even transmitted to the network 106, but the previous transaction 152i must exist and be approved for the current transaction to be valid. Thus, “predecessor” herein refers to a predecessor in the logical sequence linked by the pointer, not necessarily to the time of creation or transmission in the temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A previous transaction 152i may also be referred to as an antecedent or predecessor transaction.

[0029] The input of the current transaction 152j also includes the input's authorization, e.g., the signature of the user 103a to whom the output of the previous 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 the amount defined in the input of the previous transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0030] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or organization, wants to establish a new transaction 152j (either manually or through an automated process used by the party), the establisher sends the new transaction from their computer terminal 102 to a recipient. The establisher or recipient ultimately transmits this transaction to one or more blockchain nodes 104 of the network 106 (currently typically a server or data center, but in principle could be other user terminals). It is also not excluded that the party 103 establishing the new transaction 152j may transmit the transaction directly to one or more blockchain nodes 104 and, in some instances, not to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol generally requires the blockchain nodes 104 to check that the cryptographic signature of the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of a party 103 included in the input of a new transaction 152j matches a condition defined in the output of a previous transaction 152i to which the new transaction allocates, which condition generally includes at least checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, the condition may be determined solely by the blockchain node protocol, or by a combination thereof.In any 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 thus forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0031] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether that output has already been validly fulfilled by the input of another onward 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 fulfill has not already been fulfilled by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated for a warning) and is not recorded in the blockchain 150. This prevents double spending, where a transactor attempts to allocate the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining account balances. Again, because there is a defined order of transactions, an account balance always has a single, defined state.

[0032] In addition to approving transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process supported by "proof of work," typically referred to as mining. At a blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and others are not excluded. A property of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0033] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof that can then be easily checked by other blockchain nodes 104 in the network (given the hash solution, it is easy to check that it satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it to a threshold consensus of other nodes that enforce the rules of the protocol. The ordered set of transactions 154 is then recorded in the blockchain 150 by each of the blockchain nodes 104 as a new block 151. The new block 151n is also assigned a block pointer 155 that points backward to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of hashing, required to create the proof-of-work solution signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it allocates the same output as a previously approved transaction, also known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 of the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks on each blockchain node 104 of the network 106.

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

[0035] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional authorized amounts of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (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). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." This special type of transaction generally forms the first transaction of a new block 151n. The proof of work signals the node's intent to follow the rules of the protocol, which allow this special transaction to be subsequently fulfilled. The rules of the blockchain protocol may require a maturity period, e.g., 100 blocks, before this special transaction can be fulfilled. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is discussed below.

[0036] Due to the resources involved in approving and publishing transactions, at least each of the blockchain nodes 104 generally takes the form of a server including one or more physical server units, or even an entire data center, although in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0037] 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 or roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that all 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.

[0038] Further connected to the network 101 are computing devices 102 for each of a number of participants 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in approving 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 participants may act as storage entities that store copies of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0039] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called “clients”) may be 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 fulfill the roles required of blockchain nodes. Instead, each participant 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain nodes 106. For illustrative purposes, two participants 103 and their respective devices 102 are shown: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many additional such participants 103 and their respective computing devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely for purposes of illustration, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and all references herein to Alice or Bob may be replaced by "first party" and "second party" respectively.

[0040] The computing equipment 102 of each participant 103 includes a respective processing unit including 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 participant 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units employing 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 participant 103 stores software including a respective instance of at least one client application 105 arranged to execute on the processing unit. It will be understood that all actions attributed to a given participant 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each participant 103 includes 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 participant 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

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

[0042] The client application 105 includes at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, approve (e.g., sign), and then submit transactions 152 to one or more Bitcoin nodes 104 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0043] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; rather, any client function described herein may instead be implemented in a suite of two or more different applications that interface by, for example, an API or one is a plug-in to the other. More broadly, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0044] An instance of a client application or software 105 on each computing device 102 is operatively 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 node 104 to query the blockchain 150 regarding any transactions in which the respective party 103 is a recipient (or, in embodiments, to verify the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality of each computing device 102 is configured to assemble and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements 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.

[0045] When a given party 103, e.g., Alice, wants to submit a new transaction 152j to be included in the blockchain 150, the party 103 assembles the new transaction according to the relevant transaction protocol (using the wallet functionality of the party's client application 105). The party 103 then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which the party 103 is connected. For example, this could be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be discussed in more detail shortly. In some transaction protocols, conditions for approval may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions could simply be a built-in feature of the node protocol or defined by a combination of the script and the node protocol.

[0046] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., the newly received transaction 152j is "approved"), every blockchain node 104 that receives the transaction 152j adds the newly approved 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 approved transaction 152 toward one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that the transaction 152j is quickly propagated throughout the network 106, assuming the transaction 152j is valid.

[0047] Once placed in an ordered pool 154 of pending transactions 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 their respective pool 154 that contains the new transaction 152j. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions; whoever succeeds first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 containing the new transaction 152j, the ordered set 154 immutably becomes part of one of the blocks 151 of the blockchain 150. Each transaction 152 contains a pointer back to earlier transactions; thus, the order of transactions is also immutably recorded.

[0048] Different blockchain nodes 104 initially receive different instances of a given transaction and therefore may have conflicting views of which instance is "valid" before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then later discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance that it originally accepted (i.e., the instance that was not published in block 151).

[0049] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based model, each transaction defines the amount to be transferred by referencing an absolute account balance, rather than by referencing the UTXO of a previous transaction backward in a sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (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 signed in a transaction. This data field may point backward to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0050] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains 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 to all possible embodiments. Note that the exemplary UTXO-based protocol is described in relation to Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0051] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO is not already fulfilled). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In an embodiment, 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 the node 104.

[0052] Suppose Alice 103a wishes to create transaction 152j to send the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." Transaction 152j takes the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and sends at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in Figure 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 immediate next transaction in the pool 154. Tx1 may point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0053] The predecessor transaction Tx0 may already be approved and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least by the time Alice submits her new transaction Tx1 to the network 106. The predecessor transaction Tx0 may already be included in one of the blocks 151 at that time, or may still be waiting in the ordered set 154, in which case the predecessor transaction Tx0 will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “predecessor” and “subsequent” as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transactions (e.g., which transactions point backward to which other transactions). The terms may be equally interchangeable with "predecessor" and "successor," or "ancestor" and "descendant," "parent" and "child," etc. It does not necessarily imply the order in which those transactions are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child") that points to a predecessor transaction (ancestor transaction or "parent") is not approved until and unless the parent transaction is approved. A child that arrives at a blockchain node 104 before its parent is considered an orphan. The child may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0054] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be approved and, therefore, for the UTXO to be successfully fulfilled. Generally, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines unlocking conditions that generally include a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0055] A lock script (aka scriptPubKey) is a piece of 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 required to consume a transaction output 203, for example, the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the lock script's criteria. For example, an unlock script might include Bob's signature. An unlock script appears in the transaction's input 202.

[0056] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 must contain Alice's signature Sig P for UTXO0 to be fulfilled (or, more precisely, for any subsequent transaction attempting to fulfill UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer that points back into Tx1 (e.g., by the Tx0 transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 also includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predefined portion of data (sometimes called a "message" in the cryptography art). <Sig P A 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 by a combination of these.

[0057] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts, i.e., <Sig P A > <P A > || [Checksig P A ] where "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function included by the lock script (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. In either case, when executed together, the scripts will use Alice's public key P, included in the lock script of the output of Tx0.A is used to authenticate that the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

[0058] The details of authentication via public-private cryptography 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 and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature with the message, thus allowing all holders of the public key to authenticate the signature. Thus, it should be noted that all references 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.

[0059] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, if Alice's signature is provided in Tx1 and is authenticated), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending 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 propagated throughout the network 106. Once Tx1 is approved and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it consumes unspent transaction outputs 203. If Tx1 attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO of the prior transaction Tx0 has already been spent (i.e., whether that UTXO already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database indicating which UTXOs 203 of which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it has already formed a valid input to another valid transaction in blockchain 150.

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

[0061] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. A given UTXO cannot have a portion of the amount defined in the UTXO "left over" as spent while another portion is consumed. However, the amount from a UTXO can be divided among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be divided among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change or pay another party in the second output of Tx1.

[0062] In practice, Alice must also typically include a fee to any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus, while technically valid, may not be propagated and included in the blockchain 150 (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 its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 of a given transaction 152 and the total amount specified in the output 203 is automatically given to the blockchain node 104 that publishes that 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 one of transaction 152's UTXOs 203 itself.

[0063] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere on the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of a wallet function within the client application 105 to collate the values ​​of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. The wallet function can do this by querying a copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

[0064] Note that script code is often expressed generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to express specific functionality. "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, can store data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data in the blockchain 150. For example, the data could include a document that is desired to be stored in the blockchain.

[0065] Generally, the input to a transaction is a public key P AIn an embodiment, 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 signature signs depend on the SIGHASH flag, which is a 4-byte code typically included at the end of the signature (and therefore fixed at the time of signing) that selects which outputs are signed.

[0066] A lock script may be generally referred to as a "scriptPubKey," referring to the fact that it contains the public key of the party to whom each transaction is locked. An unlock script may be generally referred to as a "scriptSig," referring to the fact that it provides the corresponding signature. However, more broadly, it is not required in all applications of blockchain 150 that the condition for a UTXO to be fulfilled include authenticating the signature. More broadly, a scripting language may be used to define any condition or conditions. Therefore, the broader terms "lock script" and "unlock script" may be preferred.

[0067] Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the urging of either party or a third party). The side channel 107 allows for the exchange of data outside of the blockchain network. Such communication may be referred to as “off-chain” communication. For example, it may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing toward the chain 150 until one of the parties chooses to broadcast the transaction 152 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.

[0068] 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 local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 referred to anywhere herein may also be "off-chain," i.e., include any one or more links via one or more networking technologies or communication media for exchanging data separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links may be referred to as the side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange particular information, data, etc. over the side channel 107, this does not necessarily imply that all of this data must be transmitted over the exact same link or even the same type of network.

[0069] Client Software 3A shows an example implementation of a client application 105 for implementing embodiments of the presently disclosed schemes. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as assembling transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106, according to the schemes discussed above and as will be discussed in more detail shortly.

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

[0071] Note: While various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting; instead, the functions may be implemented in a suite of two or more different applications, for example, one that plugs into the other or that interfaces via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between two or more applications. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere herein to a single or given application 105, etc., it will be understood that this is merely exemplary and that, more broadly, the described functionality may be implemented in any form of software.

[0072] 3B provides a mockup of an example user interface (UI) 500 that might be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by the client 105b on Bob's device 102b, or by a client on any other participant's device.

[0073] 3B illustrates a UI 500 from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are rendered as different UI elements via user output means.

[0074] For example, the UI elements may include one or more user-selectable elements 501, which may be buttons on different screens, or different options in a menu, etc. User input means are arranged to allow the user 103 (in this case, Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen or by speaking the name of the desired option (note that the term “manual” as used herein is merely intended to contrast with automatic and is not necessarily limited to the use of one hand or multiple hands). The options allow the user (Alice) to select a message to be used when deriving a child key by an embodiment.

[0075] Alternatively or additionally, the UI element may include one or more data entry fields 502 through which a user can enter messages to be used in deriving child keys according to an embodiment. These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touchscreen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0076] Alternatively or additionally, the UI elements may include one or more output information elements 503 for outputting information to the user, which may be rendered on a screen or audibly, for example.

[0077] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not important. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is a schematic mockup only, and may in fact include one or more additional UI elements that are not shown for the sake of simplicity.

[0078] HD Wallet BIP32 The HD Wallet Protocol, which is compliant with the BIP32 specification, has two core mechanisms: 1. Key derivation - A system for deriving a tree of key pairs from a single seed. 2. Derivation path - defines the wallet structure on such a tree. will be detailed below.

[0079] Below we provide an overview of the steps involved in creating an HD wallet with the BIP32 protocol, for a complete discussion please see https: / / github.com / bitcoin / bips / blob / master / bip-0032.mediawiki

[0080] Key derivation I. Generate a binary seed. The user first chooses a seed S, typically a 12-word phrase (128-512 bits). The specifications outlined in BIP39 are often used to generate a binary seed from a mnemonic code. Users may also decide to protect their mnemonic with a passphrase (see BIP39 for further details).

[0081] II. Generate the Master Extended Private Key The master private key m is derived from the seed as follows: 1.

[0082]

number

[0083] where opad is the outer padding of size 128 bytes consisting of repeated bytes of value 0x5c and ipad is the inner padding of size 128 bytes consisting of repeated bytes of value 0x36. 2. Let I be two 32-byte sequences, I L and I R Divide into. 3.parse256(I L ) to interpret the 32-byte sequence as a 256-bit number (most significant byte first) of the master extended private key m, and R as a 256-bit number, the master chain code.

[0084] III. Generate the Child Extended Private Key. Given a parent extended key and a key index i, we can compute the corresponding child extended key. See BIP32 for additional CKD functions for deriving public child keys from public and private parent keys. The child private key sk i is the parent private key sk par and their corresponding chaincodes c par From the function CKD priv ((sk par , c par ), i)→(sk i , c i ) (3) It is derived using the function CKD priv When executing, the following steps are performed: 1. Key index i ≥ 2 31 , i.e., whether the child is a hardened key. i. Yes => Reinforced child, then function I = HMAC_SHA512(Key = c par , Data = 0x00 || ser 256 (sk par ) || ser 32 (i) where ser 256 (sk par ) is the integer sk par as a sequence of 32 bytes, and 32 (i) serializes the 32-bit unsigned integer i as a sequence of 4 bytes, most significant byte first. ii. No => normal child, function I = HMAC_SHA512(Key = c par , Data = ser P (sk par ·G) || ser 32 (i) where ser P (sk par ·G) is the coordinate pair sk par ·G = (x, y) is the compressed form of SEC1, i.e., (0x02 or 0x03) || ser 256 Serialize it as a byte sequence using (x), where the header byte depends on the parity of the omitted y coordinate. 2. Let I be two 32-byte sequences, I L and I R Divide into. 3. The returned child key sk i = parse256(I L ) + sk par (mod n). 4. Returned chaincode c i = I R . This process is shown diagrammatically in FIG.

[0085] IV. Serializing the Extended Key Format. An extended public (xpub) or extended private (xprv) key is a 78-byte data structure [magic][depth][parent fingerprint][key index][chaincode][key] A description of the individual data elements is summarized in Table 1.

[0086] Note that the parent fingerprint is a fast way to detect parent and child nodes in wallet software. Internally, the full 160-bit identifier may be used to address any hash collisions in the fingerprint.

[0087] [Table 1]

[0088] Before converting to a base58 representation, a 32-bit checksum (derived from a double SHA-256 checksum) is first added, resulting in a string of up to 112 characters that either starts with "xprv" or "xpub" on the mainnet, or "tprv" or "tpub" on the testnet.

[0089] When importing a serialized xpub, an implementation must also verify that the X coordinate of the public key data corresponds to a point on the curve. If the X coordinate of the public key data does not correspond to a point on the curve, the extended public key is considered invalid.

[0090] Derived Path The 32-bit key index i ranges from 0x00 to 0x7fffffff (0 to 2) for normal keys. 31 - 1), and 0x80000000 to 0xffffffff (2 for hardened keys). 31 ~2 32 ) range. Subscript notation (i h ), or more commonly a prime symbol, is used to denote a hardened key. Blockchain developers typically use the ASCII apostrophe rather than the Unicode prime symbol. For example, the first normal key (0x00) has i = 0, and the first hardened key (0x80000000) has i' = 0'.

[0091] Figure 6 shows a child key derivation path in a schematic diagram taken from the BIP32 specification. A derivation path is defined as an n-tuple of n key indices separated by " / ". For BIP32 HD wallets, the path is three levels or depth (m / i / j / k), m / account' / change / address_index is defined as:

[0092] The first level i after the master private key m contains the disclosed BIP32 wallet structure, where the key space can be divided to allow users to organize their funds into different "accounts", similar to regular bank accounts for different departments of an organization, for example. The default account is number 0' (hardened key index) and is sequentially incremented.

[0093] At the second level j, each account consists of two key pair chains: an internal key pair chain and an external key pair chain. The external key chain (constant index j = 0) is used to generate new public receiving addresses, while the internal key chain (constant index j = 1) is used for all other operations such as address changes or anything that does not need to be communicated externally.

[0094] The last level k is numbered from index 0 and represents consecutively increasing addresses.

[0095] BIP43 - Purpose field The BIP43 specification (https: / / github.com / bitcoin / bips / blob / master / bip-0043.mediawiki) was introduced to standardize the tree-structured fields defined in BIP32. In particular, the BIP43 specification redefines the first level following the master key as a special-purpose field. The derivation path is: m / purpose' / * where * represents subsequent levels depending on the data in the destination field. If this is set to zero (i = 0'), we can expect there to be two more levels in the derivation path, as this is the default BIP32 wallet structure.

[0096] BIP44 - Multi-Account Hierarchy The application of BIP43 with the purpose field set to 44' corresponds to a predefined 5-layer tree structure according to BIP44 (https: / / github.com / bitcoin / bips / blob / master / bip-0044.mediawiki). In particular, it introduces handling of multiple coins in different branches of HD wallets, and the default value is assigned to Bitcoin (j = 0'). Here, the derivation path is: m / purpose' / coin_type' / account' / change / address_index is defined as

[0097] address gap limit BIP44 introduces the concept of an address gap limit for account discovery purposes. Wallet software can be programmed to stop searching consecutive unused addresses beyond a certain limit, as the address index is successively incremented. The gap limit is not standardized and is often user-configurable. Typically, the gap limit is set to 20 keys, but some wallets impose limits of 100 or even 1000 keys. Note that the gap limit only applies to sibling keys, not parent-child keys. Assuming standard derivation paths are used, the search is often limited to two levels deep.

[0098] Account Discovery When a user imports their seed from an external source, the wallet software can use the address gap limit to discover accounts in the following way: 1. Set index = 0. 2. Derive the node of the account corresponding to the index. 3. Derive an external chain node for this account. 4. Scan external chain addresses and adhere to the gap limit. 5. If no transactions are found on the external chain, stop discovery. 6. If there are some transactions, increase the account index by 1 and repeat from step 2.

[0099] Since internal chains only receive coins coming from related external chains, the blockchain scan only includes external chains. Wallet software should warn when a user is about to exceed the gap limit of an external chain by generating a new address.

[0100] Wallet restoration Different wallet providers have different protocols for restoring funds during wallet recovery. Companies that offer HD wallet services to exchanges can easily have thousands of unused contiguous addresses and generally ignore the gap limits disclosed in BIP44. They instead maintain a list of all generated addresses and index those addresses individually rather than in the HD wallet data structure. Keeping a cache of known transactions in this way makes the process more time-efficient, eliminating the need to re-query the blockchain every time a user logs into the software, while also allowing light clients to scale their user capacity with just a handful of nodes.

[0101] Wallet providers that track UTXOs or entire transactions tend to store this information on their wallet servers. While HD wallets that rely on full nodes may keep a complete index of transactions, the server's system is more likely to maintain a running index that is appended to each new address. For every block published, the wallet software matches each transaction in the new block with each address in the wallet server. This process is made more efficient using pre-indexed data and / or with the help of Bloom filters.

[0102] Child Key Derival Embodiments of the present invention provide a novel method for deriving child keys in a hierarchical key structure. Generally, a hierarchical key structure includes multiple levels, with each level containing one or more keys linked to at least one key in the preceding level. The exception to this is the very first level, usually called the master level, which contains a master key. The master key is usually derived from a seed, which may be any data. After the master level, there are one or more child levels. A key at the n-1th level may be a parent key to one or more child keys at the nth level. Similarly, a key at the nth level may be a child key of a parent key at the n-1th level and also a parent key to one or more child keys at the n+1th level. Not all keys at a given level must be parent keys. For example, a key structure may have many branches of keys tracing back to a master key. Some branches may be longer than others, i.e., they contain keys that belong to higher (i.e., larger, further away, or deeper) levels than other branches.

[0103] FIG. 7 illustrates an exemplary system 700 for implementing an embodiment of the present invention. The system includes a key derivation entity 701 configured to derive one or more child keys of a key structure. Although BIP32 is provided as an exemplary protocol for deriving the key structure, the key derivation entity 701 is not limited to deriving keys that comply with that protocol. For example, the length of a key derived by the key derivation entity 701 may differ from the length required by BIP32. Conversely, the key derivation entity 701 may derive a key that does comply with BIP32 in all requirements. Furthermore, the key derived by the key derivation entity 701 is not necessarily used as a signing key for signing blockchain transactions or for use as a blockchain address, e.g., as a public key for a pay-to-public-key hash (P2PKH) address.

[0104] In some examples, the key derivation entity 701 may be configured to perform some or all of the operations attributed to Alice 103a (or actually Bob 103b) as described with reference to Figures 1-3. The system may include one or more nodes 104 of the blockchain network 106. Additionally or alternatively, the system may include one or more third parties 702, e.g., users, organizations, machines, etc. In some examples, at least one third party 702 may be configured to perform some or all of the operations attributed to Alice 103a (or actually Bob 103b) as described with reference to Figures 1-3.

[0105] The key derivation entity 701 has an existing key structure that includes one or more parent keys. A master key is a parent key to one or more child keys. One or more child keys that belong to a deeper level of the key structure may themselves be parent keys to one or more child keys. For example, a parent of a child key may itself be a child key of a master key. Alternatively, the key derivation entity 701 generates a key structure for the first time, and the generated key structure includes at least one parent key. The key structure is generated based on a seed. In particular, a master key is generated based on the seed, and all other keys are derived at least indirectly from the master key.

[0106] The key derivation entity 701 has a message that the key derivation entity 701 wants to link to a child key in the key structure. The message can be any type of external data. Here, external data refers to data that is not typically needed to derive a child key. For example, a parent key is not classified as external data because it is always needed to derive a child key. Examples of external data include communication messages (text, email, etc.), personal identifiers (e.g., name, date of birth, address, passport number, etc.), invoices, text documents (e.g., legal documents), etc.

[0107] The message is used to derive an index, which is in turn used to derive the child key. The index is based on (i.e., is a function of) the hash of the message. In other words, the message is hashed and the result is used to generate the index. In some examples, the result is the index. In other examples, one or more additional operations are performed on the result to generate the index. An example of an additional operation is a modulo operation, which may be used to convert the hash result to an index of a particular size, if necessary. It is not excluded that other operations may be performed to convert the hash result to a particular size. For example, if a 4-byte index is required, the first 4 bytes of the hash result may be selected. Another choice may be made, for example, taking the last 4 bytes.

[0108] Any hash function (e.g., SHA256) may be used to hash the message. In some instances, more than one hash function may be applied to a message, and / or a given hash function may be applied to a message more than once.

[0109] After generating the index, the key derivation entity 701 derives a child key based on (i.e., as a function of) the parent key and the index. More specifically, the child key is based on the parent key and a hash of at least the parent key and the index. That is, generally, the child key sk i teeth, sk i = f(sk par , hash(sk par , i)) where f() is the child derivation function, and sk par is the parent key. Usually, sk i Note that although denotes a private key, other types of keys may be used, e.g., a public key.

[0110] In some examples, the child key is generated by summing the parent key and the hash result, i.e., sk i = sk par + hash(sk par , i) where + represents elliptic curve addition.

[0111] The hash function may be any hash function and may or may not be the same as the hash function used to generate the index. In some examples, the child key may be based on a portion (i.e., a component) of the hash result. For example, the hash result may be larger than the key size required by the key derivation entity 701. In that case, the key derivation entity 701 may take a portion (e.g., the left n bytes) of the hash result and use that portion as the child key. In examples where a chaincode is required to derive the key (discussed next), another portion (e.g., the remainder) of the hash result may be used as the chaincode for the child key.

[0112] The child key is the parent key's chain code c par A function of, i.e., sk i = f(sk par , hash(sk par , c par , i)) It may be the case.

[0113] Generally, the keys in a key structure are derived based on a parent key and a hash result (which is based on the parent key and an index and, in this example, the parent key's chaincode). The child key's chaincode is part of the hash result, and the other part of the hash result is used to derive the child key itself. The chaincode is added entropy that ensures that the child key does not directly depend on its parent key.

[0114] After deriving a child key, the key derivation entity 701 may choose to store the message (used to generate the index) or discard the message. Similarly, after using the child key for a particular purpose, the key derivation entity 701 may choose to store the child key (and / or chaincode) or discard it.

[0115] As mentioned above, any suitable hash function may be used to generate the child keys. As a particular example, the hash function may be an HMAC function, e.g., HMAC-512. Other HMACs may be used depending on the required key length. The HMAC takes two inputs. As an example, one input may be the parent chain code and the other input may be the parent key and the index concatenated. Other combinations of inputs may be used, for example, the parent key as one input and the chain code concatenated with the index as the other input, or the parent key as one input and the index as the other input.

[0116] Those skilled in the art will be familiar with public-private key pairs. Briefly, a public key is generated by applying a function, e.g., elliptic curve multiplication of a generator point, to a private key. Key derivation entity 701 may use the described techniques to generate the private or public key.

[0117] In some cases, the parent key used to derive the child key is a private key. The resulting child key is also a private key. Such keys are often called hardened keys. sk child = sk parent + HMAC-SHA512 L (c parent , sk parent || index) It should be noted that hash functions may take other forms.

[0118] In other instances, the parent key used to derive the child key is a public key. In this case, the child key is derived based on the parent key and a public key corresponding to the hash result. That is, the hash result is converted into a public key, and the child key is based on that public key, i.e., pk child = pk parent + HMAC-SHA512 L (c parent , pk parent || index)·G where ·G denotes elliptic curve multiplication by a generator.

[0119] In yet other instances, the parent key outside the hash function may be a private key, and the parent key input to the hash function may be a public key. The resulting child key is a private key. Such keys are often referred to as unhardened keys, sk child = sk parent + HMAC-SHA512 L (c parent , pk parent || index) It may be given by

[0120] The key derivation entity 701 derives a public key corresponding to the child private key, e.g., pk child = sk child G can be derived.

[0121] Rather than being an asymmetric cryptographic key, the key may instead be a symmetric key.

[0122] In general, the child keys derived by key derivation entity 701 may be used for any suitable application, such as encrypting and decrypting messages. For example, a child public key may be used to encrypt a message, or a child private key may be used to decrypt a message encrypted with the corresponding child private key. If the child keys are symmetric keys, the same child key may be used to encrypt and decrypt a message.

[0123] The child key may be used to generate a digital signature, i.e., the child key may be a private key used to generate a digital signature based on a message and the private key. The signature may be verified using the corresponding public key.

[0124] One application in which a child key may be used is related to blockchain transactions. For example, the child key may be a public key to which an output of a blockchain transaction is locked, e.g., using a P2PK or P2PKH output. The key derivation entity 701 may generate a transaction including an output locked to the child key. Alternatively, the key derivation entity 701 may provide the child key to a third party 702, which may generate a transaction including an output locked to the child key. The key derivation entity 701 may provide the third party 702 with the child key itself or a blockchain address based on the child key, e.g., a hash of the child key. Note that generating a transaction may include generating a transaction template that is missing at least one field. The transaction template may be passed to the third party 702 or the key derivation entity 701 for completion, depending on who generated the transaction template. The complete transaction may then be sent to the blockchain network 106.

[0125] If the blockchain includes a transaction locked to a child public key, the key derivation entity 701 may generate a transaction that references that output and includes an input configured to unlock it. The input may include a signature generated using the corresponding child private key. Depending on the lock script of the referenced output, the input may also include the child public key.

[0126] The key derivation entity 701 may want or be required to prove to the third party 702 that the child key was generated based on the message. The information needed to prove the link depends on how the child key was derived. At a minimum, the parent key and the message are required. The key derivation entity 701 may send one or both data items to the third party 702, depending, for example, on whether the third party 702 already has access to the parent key or the message. For example, the parent key may be a public key known to the third party 702. The third party 702 may generate an index based on the message, i.e., by hashing at least the message. The parent key and index may then be hashed and combined with the parent key to derive the child key. If the child key is derived using the parent key's chaincode, the third party 702 also needs knowledge of the chaincode, which may be provided by the key derivation entity 701.

[0127] As an optional feature, the key derivation entity 701 may embed a digital certificate into the key structure. A digital certificate is issued to a party by a certificate authority and certifies that a data item belongs to or is otherwise associated with a particular party. In this case, the digital certificate is issued to the key derivation entity 701 (or at least the party operating the key derivation entity 701). The digital certificate may certify that a key belongs to the key derivation entity 701. The key being certified may be a key of the key structure, e.g., a master key. The digital certificate may be embedded in the key structure by generating an index of child keys based on the digital certificate. In other words, the message used to generate the index of child keys may include the digital certificate. The digital certificate may belong to the key owner (i.e., the key derivation entity 701) or the sender of the funds, and / or may include a message in addition to the certificate to create a link between an invoice and the person paying the invoice, e.g., for auditing reasons. While certifying a key provides cryptographic proof of identity, embedding a digital certificate into a key derivation function (via an index) does not provide cryptographic proof of identity, but it does create a link between a key and someone's identity for auditing purposes, for example.

[0128] Additionally or alternatively, the master key may be an attested key. That is, the master key may be attested, but not necessarily embedded in the key structure. Note that the attested key is typically a public key, since the party whose key is being attested would not want to reveal their private key. This provides a holistic solution to the idea of ​​auditing invoices via HD wallets by linking the identity of the key owner to the wallet.

[0129] Returning now to the derivation of child keys, the key derivation entity 701 may derive multiple different child keys. Each child key may be derived as described above. That is, each child key may be derived based on a respective index, which is based on the message. In some examples, a different message is used for each newly derived child key. Alternatively, the same message may be used for different keys. In that case, however, the child keys must have different parent keys to ensure that no two child keys are the same.

[0130] Some of the child keys may have the same parent key. That is, some of the child keys derived using the described techniques may be derived at the same level of the key structure and linked to the same parent key. Some of the child keys may have different parent keys, but the different parent keys belong to the same level of the key structure so that the child keys belong to the same level. Some of the child keys may have parent keys that belong to different levels of the key structure. In this case, child keys derived directly based on a message exist at different levels of the key structure. It is not excluded that some of the newly derived child keys may be children of previously derived child keys. That is, a child key derived directly based on a message may be the parent of one or more child keys that are also generated directly based on the respective message.

[0131] In some examples, when deriving multiple child keys based on the same parent key, the same message may be used to generate the index, but the message may be concatenated or otherwise combined with a different data item. That is, the index is based on a hash of the message and the data item. The data item may be a counter value that is incremented for each additional child key. For example, the index for a first child key may be the hash of the message concatenated with a first counter value (e.g., 0), the index for a second child key may be the hash of the message concatenated with a second counter value (e.g., 1), and so on.

[0132] In other examples, each message used to generate an index for a different child key may be a respective portion of the same overall larger message, e.g., the overall message may be divided into several chunks, with each chunk of the message being used to generate a respective index used to derive a respective child key.

[0133] In some other examples, a child key whose index is based on a hash of a message may be the parent of one or more child keys whose respective indexes are generated in the normal sense, e.g., using incrementing values ​​of a sequence, similar to BIP32. In these examples, the key derivation entity 701 may choose to derive child keys for only a single level of the key structure based on the message.

[0134] The key derivation entity 701 may send one or more of the multiple child keys to a third party 702. The key derivation entity 701 may additionally or alternatively generate a respective blockchain address for each of the multiple child keys and send those addresses to the third party 702. The addresses may be included in one or more transaction templates, e.g., one template for each address.

[0135] The key derivation entity 701 may generate one or more blockchain transactions (which may be transaction templates), each having at least one output locked to one of the derived child keys. Each transaction may include a single output locked to a respective one of the child keys, or one or more transactions may include two or more outputs locked to a respective one of the child keys. The key derivation entity 701 may send the transactions to the blockchain network or to a third party 702. The transactions and the number of outputs for those transactions may be based on the techniques described in UK Patent Application No. 1913667.0.

[0136] Further specific examples of the described embodiments are discussed below.

[0137] External Data HD Wallet We disclose a novel method for including external data (ED) in key derivation for HD wallets ("EDHD wallets"). Instead of explicitly including the external message in the private-public key pair calculation, we disclose that the external message is mapped to an index in the key derivation path within the HD wallet.

[0138] A user (i.e., key derivation entity 701) can either allocate an HD wallet to be used only for keys that depend on the external data, or incorporate the external data into an existing wallet by dedicating an entire branch to keys corresponding to the external data. In the example of Figure 6, the branches extend from left to right, starting from the master node (i.e., the master key). For example, one branch shown in Figure 6 consists of the following nodes: m, m / 0, m / 0 / 0, m / 0 / 0 / 0. Another branch consists of the following nodes: m, m / i, m / i / 1, m / i / 1 / 1.

[0139] For example, if the derivation path follows BIP44, a user might select an account index (depth 3) to incorporate external data related to the account into all derived child keys on that branch. Alternatively, they might associate an address index (depth 5) with individual invoices within a branch. Below we explore the implications of incorporating external data at different depths in HD wallets and along different branches.

[0140] To derive a particular key in a wallet, we disclose the following calculation: Assuming we have a message that we want to use to fingerprint the public key, we first take the modulo 2 of the hash (using, for example, the SHA256 hash function) of the message m. 32 , index = hash(m) mod 2 32 (4) , so that this can subsequently be used as the index of the child key in the derivation of the HD wallet. 32 Note that is given by the right 4 bytes of the result of the SHA256 hash function. For the purpose of recovering the key, we will split the result into the range 0≦index<2 32 Note that this is specific to BIP32 wallets, and for other protocols a different range of possible index values ​​may be chosen. For example, if the index can take on a range of values ​​given by 5 bytes, then the index should be limited to index = hash(m) mod 2 40 is given by

[0141] We then choose a key that depends on this message, defined as equation (1) or equation (2) for the normal key and the hardened key, respectively. Note that we are not modifying the HD wallet protocol here, we are just giving meaning to the index.

[0142] In the HD wallet protocol, a maximum of 2 31Indices up to 2 are reserved for normal keys. 31 Note that indices above 2 are used for hardened keys. 32 Since we chose to restrict it to , in this protocol, it is equally likely that a child key is hardened or normal. If we want to explicitly choose whether we want a hardened or normal key, we simply compute the index as for a normal key: index = hash(m) mod 2 31 (5) Regarding the strengthened keys, index' = (hash(m) mod 2 31 ) + 2 31 (6) These ranges mean that in binary representation, normal key indices always start at 0, while hardened key indices always start at 1, since the index is always exactly 32 bits long. This concludes the description of how external data should be mapped to a specific key.

[0143] Figure 8 shows the resulting wallet structure when generating key indices in this manner. Because hashing some data produces unpredictable outputs, key indices for EDHD wallets are generated randomly rather than sequentially incremented as in regular HD wallets.

[0144] External Data Audit Based on the exemplary definition above, a merchant (an example of a key derivation entity 701) has the space to generate over 2 billion invoices per year. This is more than enough for large consumer device companies or "Big Tech" companies that manufacture, for example, desktop and laptop computers, tablets, smartphones, and smart speakers, which may sell on the order of hundreds of millions of devices per year. Large companies may create new EDHD wallets each year as they complete their audits for that tax year.

[0145] Recall that one of the reasons for introducing external data into the key pair calculation is to provide a provable link between the external data and the digital key for audit purposes. In this case, to prove that the child key is derived from the external data, the index used to derive the child key needs to be provided to the auditor (e.g., third party 702). This requires sharing the preimage of the HMAC512 function, and therefore the parent key must also be shared. For hardened keys, this would mean sharing the parent private key, but such sharing is discouraged by blockchain standards, and we recommend that it not be done. One approach to solving this problem is simply to require that EDHD wallets contain only regular keys, so that all keys can be easily audited. This is done by restricting the scope of the result to include only regular keys, as shown in Equation (5).

[0146] The second technique is to modify the BIP32 procedure to simplify audits of hardened keys. This is demonstrated in Benford's wallet, where an extra step was added to include the invoice message in the HMAC256 calculation. This method creates a provable link between the public key and the invoice, but cannot be used to prove that a child key is linked to a parent key.

[0147] A third approach is to assume that the HD wallet protocol is secure. Effectively, this means that there is an industry standard for how HD wallets are derived, and no one can change it. Currently, the serialization format for HD wallet keys (stored in the wallet software but not visible in on-chain transactions) includes four bytes that indicate the index corresponding to the key in its derivation from its parent key. If this index can be assumed to be correct, hardened keys can be audited by verifying that the index given in this position corresponds to the correct external data. This assumption also leads to the expectation that wallet providers will be incentivized to act honestly in order to maintain their reputation.

[0148] Generally, auditor requirements are much lower than those for cryptographic proofs. After all, auditors only need some form of evidence that the invoices provided by merchants are valid. Using an EDHD wallet with hardened keys still gives merchants the means to identify their public keys associated with specific invoices. Merchants can provide these to auditors along with the invoices, and since the output values ​​add up to the invoice value, they can fully convince the auditor of their validity. It is therefore up to the user's discretion whether they wish to employ any of the above suggested techniques for auditing purposes.

[0149] The disclosed solution allows HD wallets to rely on external data so that they can be audited, and among other things, the solution still allows keys to be restored in the event of loss without the need to know the relevant external data.

[0150] Gap Limit Restrictions The EDHD wallet protocol takes advantage of HD wallet recovery, where all private / public key pairs can be regenerated from just the seed. To ensure that the wallet is not lost, the seed can be stored securely (or split into shares and distributed for security). To rekey a wallet, most wallet implementations search the UTXO set stored on the wallet server (storing a user's transaction history eliminates the need to scan the blockchain) until they reach an address gap limit, typically set to 20 per BIP44 guidelines. This means that if there are 20 consecutive addresses that have not received payments, the wallet software stops the search process and assumes that no further keys exist in the wallet.

[0151] Consider a scenario where Alice, a user of an enterprise HD wallet, generates and distributes 20 receiving addresses to her clients (the maximum possible given the gap limit of 20). Alice is waiting for payments from her clients, but none of those clients respond to Alice's payment request, and Alice needs to generate more addresses for several new potential clients.

[0152] If a user generates 20 addresses in quick succession in this manner, the wallet software must be programmed so that the 21st address generated wraps around to the first and reuses the first address generated.

[0153] Under normal circumstances, addresses are not reused and a new address is assigned for every payment, following cryptographic best practices for secure digital key management.

[0154] This simple example above highlights the restrictive nature of sequential address generation, which is a core requirement for wallets that implement address gap limits, but wallet software can circumvent this issue by making tradeoffs in cryptographic security.

[0155] The address gap limit remains an issue when migrating seeds between different wallet services due to differences in the restoration process of each wallet provider. As a result, if a user decides to use a new wallet provider, the tracking of addresses within the wallet server may not work. Therefore, the restrictive nature of the gap limit may prove troublesome for users who need to research in advance whether a wallet migration is possible.

[0156] EDHD Wallet Recovery Now consider a merchant with an EDHD wallet and a collection of invoices. The merchant backs up their seed with a trusted third party 702 and uses their wallet for daily operations. If the merchant loses their wallet data file but still has their invoices, the merchant can use their backed-up seed and set of invoices to immediately identify which public key or which set of keys in the case of a Benford-EDHD wallet was used for each invoice.

[0157] If a merchant loses both the wallet data file and the invoice, there are two things to check for when restoring the wallet: 32Since it is only a list of indices, it is still possible by brute-forcing which public keys were used. That is, a merchant may generate all possible addresses and check if there are UTXOs paid to any of those addresses. Note that if all invoices are lost, full recovery of all keys in the EDHD wallet would require lifting the address gap limit so that the software searches all addresses in a 4-byte range. In terms of security, the invoice itself does not need to be as secure as the wallet seed, as leaking the invoice would only result in some loss of privacy that is not detrimental to the merchant.

[0158] There is a further option to store the external data used to derive the child keys, so that there is a list of indexes to be derived. As explained by BIP39, one could store the indexes explicitly or store a mnemonic corresponding to each index. If this data is compromised, an attacker would have no way of identifying a specific address or transaction without knowing the parent key of the derivation path. In the case of external data corresponding to invoices, these must be stored anyway for audit purposes, and there is no extra work involved in storing external data.

[0159] In terms of wallet migration, the fact that the wallet data file is derived deterministically from the seed and invoice makes it very easy to migrate between wallets. This is because the index used to calculate the key is known or can be calculated from the invoice. This is because the only data needed is the seed and invoice, everything else (i.e., key regeneration) comes deterministically. Currently, this is a severe limitation for users who want to migrate their seeds from different wallet providers due to the differences in key derivation paths mentioned above.

[0160] Features and Benefits When a wallet data file is deterministically derived from a seed and invoice (or more broadly, other external data), several unique advantages arise that are not currently available to wallet users. As mentioned above, one of these is the ability to easily migrate between different wallet providers. Another is that, because an invoice was used to generate the key, instead of relying on whether the keys were used in some sequential order, the key can now be identified before funds are received. Embodiments of the present invention can be utilized to provide any one or more of the following examples: Scalable – Not limited by the sequential nature of regular HD wallets. · Customizable - More flexibility to include external data for different purposes. ·Recoverable - Transactions and invoices can be restored from the seed only. Interoperable – easy transfer of data between different wallet providers. Auditable - Presents a novel way to identify and structure keys within a wallet.

[0161] Theoretical Benchmarking Here, we provide a series of theoretical analyses in response to the issues related to wallet recovery and the risk of potential hash collisions when using our disclosed indexing solution for external data. Unless explicitly stated, the following theoretical discussion is based on four assumptions: a) not knowing the address gap limit, b) not knowing the key derivation path, c) Always use only P2PKH scripts to generate addresses, and d) Have access to the entire set of UTXOs stored on the wallet server

[0162] Wallet restoration Recovering the private-public key pair used in the EDHD wallet involves two steps: 1. Generate all possible keys using all possible derivation paths, and 2. Verify which keys are active (keys associated with unspent transactions)

[0163] Below, we analyze the computational complexity for brute forcing all possible keys in a wallet using two approaches: account / index brute force and message brute force.

[0164] Account / Index Brute Force In theory, an infinite number of keys can be generated by adding new levels to the derivation path. Active key identification assumes the use of BIP44, where the first three levels are fixed. For example, for Bitcoin, the first three levels are m / 44' / 0', followed by account (hardened addresses only), change (always 0), and address index. Therefore, brute-forcing a wallet using this technique requires searching all possible accounts and indices in the derivation path.

[0165] If we don't use an address gap limit to break the search for active keys, we need to brute force all possible accounts (31 bits, i.e., about 2 billion accounts). Each account has a 32-bit key, i.e., about 4 billion address indices, about 2 billion hardened keys, and about 2 billion regular keys. Therefore, for each of the 2 billion accounts, we must generate 4 billion addresses and then check which ones have unspent transactions in the UTXO set.

[0166] If we benchmark the "expected key search rate" used to look up vanity addresses, we can assume that a modern GPU can process 15 million to 2 billion keys per second (Mkey / s). Therefore, the time required to generate 4 billion possible keys per account is between 2 seconds and 5 minutes (number of keys / GPU processing power).

[0167] Then, for each key, we verify whether it has any unspent transactions in the UTXO set; assuming the UTXO set is stored in RAM and therefore the test is very quick, we estimate that the entire process of generating a key and checking UTXOs takes between 5 seconds and 5 minutes, depending on the GPU used. Because all possible indexes must be searched, the time to complete this process is constant whether we are searching 1 active address or 1000 active addresses, unless we know the number of active addresses (in which case we can stop early when that number is reached).

[0168] Since we assume that we do not know any information about the account, 31 The account space (consisting of 1000,000,000 bits) must also be searched. Therefore, the brute force process must be repeated for approximately 2 billion possible accounts. Using the fastest GPU (5 seconds to brute force approximately 4 billion address indices), this requires 5 seconds per account, so searching approximately 2 billion accounts would require approximately 340 years.

[0169] If the process is parallelized, for example by running 100 GPUs in parallel, the time could be reduced to 3.4 years. Note that one such GPU could cost £2000-£3000 excluding electricity for three years, so it is a large investment to restore one wallet and probably infeasible for most users.

[0170] If we reintroduce a gap limit of 20 inactive addresses, the brute force process becomes much quicker than 5 seconds, and we can safely assume it takes less than 1 millisecond per account. If we wanted to test this for all accounts, 1 millisecond x 2 billion possible accounts would require a total of about 25 days.

[0171] If a gap limit is also introduced into account generation, perhaps only a few hundred accounts need to be checked, rather than all 2 billion possible accounts. In this case, the entire process can be completed in a second or so. Note that this is true even for higher gap limits (e.g., 100).

[0172] Key Brute Force Example Here, we compare the time required to brute force the keys of an HD wallet using two widely used GPUs. In the first experiment, we considered a high-level GPU, GeForce RTX 2080 SUPER (2000Mkey / s), and in the second experiment, we considered a mid-level GeForce GTX 780 Ti (50Mkey / s). Note that the "Size" column refers to the total number of key index bits in the randomly generated derivation path (e.g., one derivation path is 32-bit deep, two are 64-bit deep, etc.). The results of the study are shown in Table 2.

[0173] [Table 2]

[0174] The calculations show that a single 32-bit key index can be easily brute-forced using either type of GPU (2 seconds or 85 seconds in our example above). Note that this is independent of the index chosen, i.e., address index or account.

[0175] However, it is more complicated when the two indexes (e.g., both the address index and the account) are randomly generated. In fact, the address index (32 bits) plus the account (32 bits) has a total size of 64 bits, which is too computationally expensive to brute force, even using a top-tier GPU. This would require 292 years just to generate all the keys, excluding the time to check which public keys have valid unspent transactions.

[0176] A hybrid solution could be to randomly create only a partial subspace of the index. For example, the account index could be limited to 8 or 16 bits, with the remaining bits being deterministically generated or simply set to 0. In general, a hybrid key index can be calculated as follows, with respect to a regular key: index hybrid = hash(m) mod 2 16 (7) and padding it with leading zeros to produce a 32-bit integer. For the hardened key, index hybrid ' = (hash(m) mod 2 16 ) + 2 31 (8) It can be calculated as:

[0177] [Table 3]

[0178] Table 3 summarizes the time required to brute-force the random address index, account, and hybrid solutions. The results reveal a trade-off between the time to brute-force the keys derived from the random index and the likelihood of hash collisions, which is increased when using a smaller bit space for the random component of the hybrid index. For users who want to embed external data to multiple derivation depths (e.g., at the address and account level), we recommend choosing a hybrid solution for any additional random key index. For example, a 32-bit randomly generated address index could be used in conjunction with an 8-bit or 16-bit hybrid random account index. These key indexes could be provided together, for example, during any audit process. However, if the indexes need to be considered separately, for example, during identity verification, it is advisable to use a larger 16-bit hybrid random index to minimize the likelihood of hash collisions.

[0179] Message Brute Force An alternative to account / index brute force is to brute force the message m instead of the entire account, i.e., index space. Message brute force consists in generating all possible messages, such as invoices or any other information used to generate the key, instead of the key itself. This approach is more efficient than an exhaustive key search when the message space is smaller than the account / index space, since the possible keys generated from the small message space are a subset of all possible keys. For example, if the invoice message is: m = 'Sold bicycle for 3 BSV with frame number XXXX and date YY / YY / YYYY' If we know that the message is represented as a string with constant parts and some variables, then instead of brute-forcing around 4 billion address indices, we can brute-force the variable parts XXXX and YY / YY / YYYY of the message.

[0180] Suppose we want to mine invoices from the past 10 years, then there are 3,650 different values ​​for the variable YY / YY / YYYY (365 days x 10 years). Also, assuming a maximum of 1,000,000 invoices per year generated by some logic, we have 1,000,000 different values ​​for the variable XXXX. Thus, the space to be searched is 1,000,000 x 3,650 = approximately 3.6 billion combinations, which is the same size as brute-forcing an address index. In this case, brute-forcing an index or message has similar complexity and therefore requires a similar amount of time.

[0181] Mining invoices can be useful if the searched space can be made small. For example, if you have a maximum of 1,000 possible invoices and only consider one year, you have 1,000 x 365 = 365,000 combinations that can be brute-forced in about 0.2 milliseconds (instead of 5 seconds). Brute-forceing all accounts would require about 5 days (instead of 340 years) to complete. Note that running an expensive GPU to its full capacity for 5 days just to brute-force one HD wallet is still not a cost-effective option, and therefore account management should be solved using deterministic techniques.

[0182] Hash collisions We now evaluate the probability that two messages m (external data) generate the same 32-bit index and therefore map to the same child key in the EDHD wallet. This problem is a generalization of the birthday paradox, and therefore, given n messages in the range [1, d], we can use the following (approximated) formula to calculate the probability that at least two key indices are the same:

[0183]

number

[0184] Therefore, the range d = 2 32 The collision probability at

[0185]

number

[0186] is.

[0187] Some examples are given in Table 4, where, for example, 10,000 messages are inserted with a 1.1% collision probability, while 100,000 messages are inserted with a collision probability of about 68.8% (which means that, on average, only 31.2% of the messages have a unique derived path). If we want to avoid collisions, we generally -6 A collision probability less than is considered acceptable and therefore reasonable for wallet implementations, which means that no more than 100 keys per account should be generated using message m (e.g., invoices). To increase the number of keys per account, collision management tools may be implemented. As an example, message m may be slightly modified (e.g., increment a counter) if it generates an index that is already in use.

[0188] Alternatively, collisions can be tolerated. This does not result in any funds being lost, as the only effect is that addresses are reused (which may result in a negligible loss of privacy). In addition to the public key, other factors such as the invoice amount and time may also be used to uniquely link an invoice to a transaction. The estimated number of collisions, for inserting n keys, can be calculated as follows:

[0189]

number

[0190] As shown in the last column of Table 4, as the number of messages increases, we expect some collisions; for example, when 50,000 messages are used, we expect 0.29 iterations, and when 100,000 messages are used, the expected number of iterations rises to 1.16. This means that when generating keys starting from 100,000 different messages, on average, two of those messages will share the same public key (i.e., two invoices will share the same address).

[0191] [Table 4]

[0192] Benford wallet The wallet design, known as Benford's wallet, provides a mechanism to protect the privacy of both merchants and users transacting on a public blockchain while ensuring regulatory compliance. Briefly, invoice data is used to derive output addresses, which are useful for audits. At the same time, the invoice value is obfuscated by distributing it across these multiple output addresses in multiple transactions, which promotes on-chain privacy.

[0193] The protocol uses either chaincodes or shared secrets interchangeably to link invoice messages m across different output addresses.

[0194]

number

[0195] Modify the generalized BIP32 CKD function shown in (3) by introducing an additional step after equation (1) or (2) to derive a normal or hardened private key from the hash of m as

[0196] Both methods reintroduce the bag of keys problem, as external data is included by adding an additional step to the child key derivation path. The method described above for the EDHD wallet solves this problem, as it works within the existing BIP32 framework without introducing any additional steps that could lead to a bag of keys scenario.

[0197] To get the best of both worlds, a Benford wallet can be combined with an EDHD wallet: for example, an invoice can be embedded in the HD wallet according to the index mapping described above, while obfuscating the invoice value by splitting the transaction into different output addresses according to Benford's Law.

[0198] Because the Benford wallet takes one invoice and generates several output addresses from it, a little care needs to be taken to adjust this to the EDHD wallet method of mapping one invoice to one output address, as already shown. There are several options for doing this. 1. Add a counter - m Benford A new invoice message is generated for each output address by concatenating an integer n at the beginning of invoice message m so that = n || invoice. The counter is incrementally incremented to the total number of output addresses that belong to a single invoice. For example, if n = 3, then key derivation entity 701 may derive three indices and corresponding keys as index i = hash(m Benford,i ) mod 2 31 Generate it using m Benford,0= 0 || invoice m Benford,1 = 1 || invoice m Benford,2 = 2 || invoice is. 2. Split the invoice - The message is split into n equal chunks of data across n different output addresses. 3. Two depths of derivation paths - The output values ​​for a single invoice can be split into two depths of derivation paths. For example, the invoice message (m Benford = invoice) can be used to derive the parent key, and then the remaining output addresses are the first n - 1 child keys. This method also means that there is no penalty in wallet recovery time when embedding external data across different depths in the derivation path.

[0199] These techniques, as described, require knowledge of n partitions of the invoice value. The random partition represented by n can be deterministically derived from the invoice message itself in the same way that the key index is derived in equation (4), but modulo modified to a practical upper bound on the number of invoice partitions (e.g., 10 partitions). This gives a description of the Benford EDHD wallet.

[0200] Random partitioning to achieve Benford's law For Bob (i.e., key derivation entity 701) to randomly split the 3 BSV invoice across many outputs and many transactions, there are two tasks to perform. 1. Randomly select the number of outputs and transactions to use. 2. Randomly divide the value of the BSV invoice across a selected number of outputs.

[0201] We achieve these goals in two steps, using two different random splitting methods. The first step involves splitting a small integer and obtaining a uniformly random selection of this set. The second step uses uniformly random slices of a large value to create a set of splits that add up to a large number (the invoice value in satoshis). The randomization involved in both steps results in Benford's law being applied to the transaction number, the number of transactions per output, and the output value itself.

[0202] In what follows, we only require that one parameter, N, needs to be pre-selected by user Bob. This is defined to be N = maximum number of outputs. In a real-world scenario, we expect this number to be small, e.g., less than 20.

[0203] I. Distribution of Transactions and Outputs. User Bob defines an integer N as above, which represents the maximum number of outputs Bob is willing to distribute an invoice across. We describe the process of outputting m transaction templates with a total of n outputs, where n≦N.

[0204] Step 1: Identify or find integer partitions of each integer k such that 1 ≤ k ≤ N. An integer partition is a distinct combination of (unordered) numbers that sum to n. For example, the integer partitions of k = 3 and k = 4 are: 3, 4, 2+1, 3+1, 1+1+1, 2+2, 2+1+1, 1+1+1+1 It can be seen that there are three possible integer divisions of 3 and five possible integer divisions of 4. The number of integer divisions does not vary linearly. The following table shows the number of divisions for each integer k≦50.

[0205] [Table 5]

[0206] Step 2: Choose a single partition uniformly and randomly from all possible partitions for each k such that 1 ≤ k ≤ N. For some integers m, n, with 1 ≤ m ≤ n ≤ N, call this partition n1+ … + n m = n. Each term can be written as n i This is interpreted as defining a transaction with n outputs. That is, m transactions are constructed, and for 1 ≤ i ≤ m, transaction i has n i , and has n outputs. Figure 9 shows this diagrammatically. The total number of outputs is n.

[0207] These two steps complete the initial setup of our value partitioning process in the next section. In addition to the required single integer input N, we propose several arbitrary inputs that user Bob can provide. 1. Minimum number of transactions or outputs: This can be used to avoid trivial cases. 2. Maximum Number of Transactions: This can be used to cap the overhead due to transaction fees or the amount of data sent between sender and receiver. In some cases, the number of transactions defines the minimum number of inputs required from the sender, which can be capped by this optional parameter.

[0208] II. Invoice Value Variance Given the invoice value L BSV and the list of m transaction templates obtained in the previous process, the following procedure may be used to fill in the n outputs. 1. (The smallest unit is 1 Satoshi, 10 -8 (Because it is BSV) 10 -8 n - 1 numbers U1, U2, ..., U with precision n-1 Generate a uniform random number ∈(0,1). 2.U i Sort in ascending order, 0 (1) (2) <… <U​​(n-1) <1. 3. Split X for i = 1, 2, ..., n i = U (i) -U (i-1) where U (0) = 0 and U (n) = 1.

[0209] Now, to form n values, use X i ' and m transaction templates with n outputs, one for each of the n values. split x i ' follows Benford's law in its general interpretation, i.e., X i The smaller the first digit of i is likely to occur. The scaling factor L does not affect the distribution of leading digits. We give a detailed proof for L = 1 and extend the result to any value of L greater than 0.

[0210] Link to identity certificate Digital certificates are signed and issued by a CA, which acts as a trusted third party 702 in verifying the link between a user's identity and the subject public key specified in the certificate. If a user wants to certify several keys, requesting certification from a commercial CA can be quite costly. However, cryptographic best practices for digital key management recommend avoiding public key reuse. Therefore, it is much more efficient and cost-effective for users transacting on a blockchain network to employ a deterministic method for linking their identity data to an entire wallet of keys.

[0211] Parent key certification The simplest way to link identity data to a set of keys in an HD wallet is to certify the master public key, or the account keys derived from it, so that there is a link to the identity certificate for each account holder. For addresses generated from normal (i.e., non-hardened) child keys, a provable link to the wallet, and therefore the account holder's identity, can be established. Thus, identity audits can be performed on normal child address keys, since they can be provably linked to the parent that issued the identity certificate.

[0212] You can also verify that a child key was used after its parent key was certified (i.e., the digital certificate pre-existed) as follows: 1. Timestamp - Digital certificates typically include a timestamp, which may be used as evidence that the certificate was created before the child key was used in the chain. 2. On-chain digital certificates - if the certificate itself is issued on-chain, or the hash commit is registered on-chain, this also provides evidence that the certificate existed before the child key (or at least before the child key was used on-chain, which is functionally equivalent).

[0213] Note the difference here from the less strict case of invoice audit, where evidence of a link to external data is sufficient. For identity audit, we look for cryptographic proof to correctly verify the user's identity with respect to the child keys in the HD wallet. Then, by providing identity certificates for the parent keys and deriving the child keys using invoice-based indexes, we get an audit-friendly system.

[0214] Mapping digital certificates to key indexes An alternative way to link a user's identity to a key in an HD wallet is to map a digital certificate to a key index using the method described above. This can be achieved by simply setting the external data in Equation 4 to m = digital certificate. However, it should be emphasized that using this method does not provide cryptographic proof of the user's identity for the same reasons described above.

[0215] Therefore, an additional protocol must be put in place to check that the wallet owner knows the private key for the subject public key specified in the digital certificate. Such a protocol may utilize various proof methods based on digital signatures, knowledge of hash preimages (where appropriate), or zero-knowledge proofs, to allow the user to cryptographically prove ownership of the certified private-public key pair.

[0216] Mapping identity data to the account level allows for entire branches of keys to be split according to different digital certificates. Figure 10 shows how different digital certificates might be used to structure an EDHD wallet by "identity," "merchant," and "education" branches. Account-level key indices are now random because they are calculated from the hash of the respective digital certificate. Recall that random indices resulting from the hash of some external data at the account level should be limited to a smaller bit space based on the above considerations regarding wallet recovery.

[0217] The full derivation path for BIP44 Bitcoin EDHD wallets is m / 44' / 0' / (hybrid_random_account') / 0 / (random_address_index) where the hybrid_random_account' key index is generated using equation 8 when m = digital certificate, and the random_address_index is generated using equation 5 when m = invoice message. The structure of each branch can be further developed to suit different business applications. Considering the "merchant" branch, the merchant can allocate a depth-4 child key to correspond to the refund, and a hash preimage (i.e., the original invoice) is needed to create a depth-3 child key so that the refund may be authorized by transferring the UTXO amount from the invoice key to the depth-4 child key generated for the refund.

[0218] The method of mapping digital certificates to key indexes can also be extended to create links between different identities. For example, one might incorporate someone else's identity certificate into one's wallet, and for example, a recipient's identity certificate and invoice could be mapped to an output address used by a merchant's wallet. Certificates and invoices could be combined as follows: index = hash(digital certificate || invoice) mod 2 32 (13)

[0219] Now we have a way to link the identity of the user (buyer) to the sale (invoice) all within the merchant's wallet software. This is especially useful for high value transactions, e.g., selling a car or house.

[0220] conclusion Other variations or use cases of the disclosed technology will be apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0221] For example, some embodiments above have been described in terms of 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 broadly to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More broadly, all 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 above.

[0222] 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, propagating, 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, network entities may perform the function of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

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

[0225] It will be appreciated that the above embodiments have been described by way of example only. More broadly, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0226] Statement 1. 1. A computer-implemented method for deriving keys for a hierarchical key structure, the key structure including a hierarchy of levels, the hierarchy of levels including a master level and one or more child levels, the master level including a master key, each child level including one or more child keys, each child key at a given level being linked to one key at a preceding level, which key at the preceding level being a respective parent key for each child key, the method being performed by a first party; generating a target index for the target child key, the target index being generated based on at least a first result of inputting the target message to a first hash function; a) deriving a child key for a target level in the hierarchy based on a parent key of a preceding level in the hierarchy, and b) a second result of inputting at least i) the parent key and ii) an index of the target into a second hash function.

[0227] Statement 2. 10. The method of statement 1, wherein the target child key is based on a first portion of the second result.

[0228] Statement 3. The method of statement 2, comprising the step of generating a target chaincode for the target child key, the target chaincode being based on a second portion of the second result.

[0229] Statement 4. The method of any preceding statement, wherein the target child key is derived by iii) inputting the chain code of each of the parent keys into a second hash function.

[0230] Statement 5. The method of any preceding statement wherein the second hash function is a hash-based message authentication code (HMAC) function.

[0231] Statement 6. The method of either of the preceding statements where the parent key is a private key and the target child key is a private key.

[0232] Statement 7. The method of statement 6, wherein the parent key input to the second hash function is the public key corresponding to the parent key.

[0233] statement 8. The method of statement 6 or statement 7, comprising generating a target public key corresponding to the target child key.

[0234] Statement 9. 6. The method of any of statements 1 through 5, wherein the parent key is a public key, the target child key is a public key, and the target child key is derived based on the public key corresponding to the second result.

[0235] Statement 10. generating a blockchain transaction including the output locked to the target child key and transmitting the blockchain transaction to the blockchain network and / or the second party; calculating a target blockchain address based on the target child key and sending the target blockchain address to the second party; and / or The method of any preceding statement including any one or more of the steps of sending the target child key to a second party to generate the target blockchain address.

[0236] Statement 11. the blockchain includes a blockchain transaction including an output sent to a target blockchain address, and the method comprises: deriving a sequence of candidate child keys and corresponding candidate blockchain addresses, each candidate child key derived based on the parent key and b) a second result of inputting at least i) the parent key and ii) a respective candidate index into a second hash function, each candidate index being a respective value in a sequence of possible values ​​that the index may take, and different for each candidate child key; identifying a blockchain transaction that includes an output sent to at least one of the candidate blockchain addresses; and determining, based on the identification, that the target child key is a candidate child key having a corresponding candidate blockchain address to which the output of the identified blockchain transaction is locked.

[0237] Statement 12. 11. The method of statement 10, wherein the blockchain includes a blockchain transaction including an output sent to a target blockchain address, and the method includes using the target blockchain address to identify the blockchain transaction.

[0238] Statement 13. The method of any preceding statement, wherein the target child key is a public key and the method includes using the target child key to encrypt a message, or wherein the target child key is a private key and the method includes using the target child key to decrypt a message encrypted with the corresponding public key.

[0239] The encrypted message may be sent to or received from different parties.

[0240] Statement 14. The method of any preceding statement including the step of proving the link between the target child key and the message by providing at least the parent key and the target message to a third party.

[0241] If the target child key is generated based on a chaincode of the parent key, said chaincode may also be provided.

[0242] Statement 15. The method of any preceding statement wherein the target message includes a digital certificate issued by a certification authority.

[0243] Statement 16. The method of any of the preceding statements wherein the master key is a certified public key certified by a digital certificate issued by a certificate authority.

[0244] Statement 17. The method of statements 15 and 16, wherein the target message includes a digital certificate attesting to the certified public key.

[0245] Statement 18. 15. A method of statement in which a digital certificate certifies a public key owned by a third party.

[0246] For example, the third party may be a customer that generates a blockchain transaction that includes an output locked to a child key derived based on the target message.

[0247] Statement 19. deriving one or more additional child keys, wherein generating each additional child key comprises: generating a respective index for each child key, the respective index being generated based on at least a respective first result of inputting the respective message to a first hash function; a) deriving each child key for a level in the hierarchy based on a respective parent key for a preceding level in the hierarchy, and b) a respective second result of inputting at least i) the respective parent key and ii) the respective index into a second hash function.

[0248] Statement 20. The method of statement 18, wherein some or all of the additional child keys are derived based on the same parent key as the target child key.

[0249] Statement 21. The method of statement 18 or statement 19, wherein some or all of the additional child keys are derived based on a different parent key compared to the target child key.

[0250] Statement 22. The method of statement 20, wherein the target child key is a parent key of one or more of the additional child keys.

[0251] Statement 23. The method of statement 18 or statement 19, wherein some or all of the additional child keys are at the same level in the hierarchy as the target child key.

[0252] Statement 24. 19. The method of statement 19, wherein the respective indexes used to derive each of the target child key and one or more of the additional child keys are derived based on respective first results of inputting at least the message and the respective counter value into a first hash function.

[0253] Statement 25. 19. The method of statement 19, including the step of dividing the entire message into a plurality of components, wherein respective indexes used to derive each of the target child key and one or more of the additional child keys are derived based on respective first results of inputting at least different components of the entire message into a first hash function.

[0254] Statement 26. deriving one or more additional child keys, wherein deriving each additional child key comprises: 18. The method of any of statements 1 to 17, comprising: a) deriving a target child key; and b) deriving respective child keys based on respective second results of inputting at least i) the target child key and ii) a respective index into a second hash function, wherein the respective indexes are respective values ​​of the sequence.

[0255] Statement 27. generating a respective blockchain address corresponding to each generated child key; and sending the respective blockchain addresses to different parties.

[0256] Statement 28. generating one or more blockchain transactions, each including one or more outputs, each output locked to a respective one of the generated child keys; 28. The method of any of statements 18 to 27, comprising: transmitting one or more blockchain transactions to a blockchain network; and / or transmitting one or more blockchain transactions to different parties.

[0257] Statement 29. wherein said deriving the target child key comprises recovering the target child key, and wherein said recovering the target child key comprises: generating a master key based on the corresponding seed; and deriving a parent key of the target child key based on the master key.

[0258] A parent key may be derived directly from a master key, i.e., the parent key of a target child key is itself a child key of the master key. Alternatively, a parent key may be derived indirectly from a master key by deriving one or more keys belonging to different levels of the key structure.

[0259] Statement 30. a memory including one or more memory units; A computing device comprising: a processing device including one or more processing units, wherein a memory stores code arranged to be executed on the processing device, the code, when on the processing device, being configured to perform the method of any preceding statement.

[0260] Statement 31. A computer program embodied on a computer readable storage and configured to perform the method of any preceding statement when executed on one or more processors. [Explanation of symbols]

[0261] 100 systems 101 Packet Switched Network 102 Computer terminals, computer equipment, and devices 102a Computer Equipment 102b Computer Equipment 103 Users, Agents, and Parties 103a User, first participant, Alice 103b New user or entity, second party, Bob 104 Blockchain nodes, Bitcoin nodes 105 Client Applications 106 Peer-to-peer (P2P) networks, Bitcoin networks, blockchain networks 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151 blocks of data, latest block 152 transactions, new transactions 152i Previous transaction, new transaction 152j Current Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Pools 155 Block Pointer 201 Header 202 Input 203 Output 400 System 401 Transaction Engine, Requester 402 User Interface (UI) Layer, Verifier 403 Function 500 User Interface (UI) 501 UI elements 502 UI elements, data entry fields 700 System 701 Key Derivation Entities 702 Third party

Claims

1. 1. A computer-implemented method for deriving keys for a hierarchical key structure, the key structure including a hierarchy of levels, the hierarchy of levels including a master level and one or more child levels, the master level including a master key, each child level including one or more child keys, each child key at a given level being linked to one key at a preceding level, the one key at the preceding level being a respective parent key for each of the child keys, the method comprising: generating a target index for a target child key, the target index being generated based on at least a first result of inputting the target message to a first hash function; a) deriving a child key for the target level in the hierarchy based on a parent key of a preceding level in the hierarchy, and b) a second result of inputting at least i) the parent key and ii) an index of the target into a second hash function; and deriving one or more additional child keys, wherein generating each additional child key comprises: generating a respective index for each of the child keys, the respective index being generated based on at least a respective first result of inputting the respective message to the first hash function; a) deriving the respective child keys of a level in the hierarchy based on a) a respective parent key of a preceding level in the hierarchy, and b) a respective second result of inputting at least i) the respective parent key and ii) the respective index into the second hash function, the method further comprising:

10. A method comprising: dividing an entire message into a plurality of components; and wherein the respective indexes used to derive each of the target child key and one or more of the additional child keys are derived based on respective first results of inputting at least different components of the entire message into the first hash function.

2. 2. The method of claim 1, wherein the target child key is based on a first portion of the second result.

3. 3. The method of claim 2, further comprising generating a target chaincode for the target child key, the target chaincode being based on a second portion of the second result.

4. 4. The method of claim 1, wherein the target child keys are derived by iii) inputting the chain codes of each of the parent keys into the second hash function.

5. 5. The method according to claim 1, wherein the second hash function is an HMAC function.

6. 6. The method of claim 1, wherein the parent key is a private key and the target child key is a private key.

7. 7. The method of claim 6, wherein the parent key input to the second hash function is a public key corresponding to the parent key.

8. 8. A method according to claim 6 or claim 7, comprising generating a target public key corresponding to the target child key.

9. 6. The method of claim 1, wherein the parent key is a public key and the target child key is a public key, and the target child key is derived based on the public key corresponding to the second result.

10. generating a blockchain transaction including the output locked to the target child key and transmitting the blockchain transaction to a blockchain network and / or a second party; calculating a target blockchain address based on the target child key and sending the target blockchain address to the second party; and / or 10. The method of claim 1, further comprising any one or more steps of sending the target child key to the second party to generate the target blockchain address.

11. wherein the blockchain includes a blockchain transaction including an output sent to the target blockchain address, and the method comprises: deriving a sequence of candidate child keys and corresponding candidate blockchain addresses, each candidate child key derived based on the parent key and b) a second result of inputting at least i) the parent key and ii) a respective candidate index into a second hash function, each candidate index being a respective value in a sequence of possible values ​​that the index may take, and which is different for each candidate child key; identifying a blockchain transaction that includes an output sent to at least one of the candidate blockchain addresses; and determining, based on the identification, that the target child key is the candidate child key having the corresponding candidate blockchain address to which the output of the identified blockchain transaction is locked.

12. 11. The method of claim 10, wherein the blockchain includes a blockchain transaction including an output sent to the target blockchain address, and the method includes using the target blockchain address to identify the blockchain transaction.

13. 13. The method of any one of claims 1 to 12, wherein the target child key is a public key and the method comprises using the target child key to encrypt a message, or wherein the target child key is a private key and the method comprises using the target child key to decrypt a message encrypted with a corresponding public key.

14. 14. The method of any one of claims 1 to 13, comprising the step of proving the link between the target child key and the message by providing at least the parent key and the target message to a third party.

15. 15. The method of any one of claims 1 to 14, wherein the target message includes a digital certificate issued by a certificate authority.

16. 16. The method of any one of claims 1 to 15, wherein the master key is a certified public key certified by a digital certificate issued by a certification authority.

17. 17. The method of claim 15 or claim 16, wherein the target message includes the digital certificate attesting to a certified public key.

18. 16. The method of claim 15, wherein the digital certificate certifies a public key owned by a third party.

19. 19. The method of any one of claims 1 to 18, wherein some or all of the additional child keys are derived based on the same parent key as the target child key.

20. 19. The method of any one of claims 1 to 18, wherein some or all of the additional child keys are derived based on a different parent key compared to the target child key.

21. 20. The method of claim 19, wherein the target child key is the parent key of one or more of the additional child keys.

22. 19. The method of any one of claims 1 to 18, wherein some or all of the additional child keys are at the same level in the hierarchy as the target child key.

23. 23. The method of any one of claims 1 to 22, wherein the respective indexes used to derive each of the target child key and one or more of the additional child keys are derived based on a respective first result of inputting at least the message and a respective counter value into the first hash function.

24. deriving one or more additional child keys, wherein deriving each additional child key comprises:

18. The method of claim 1, comprising: a) deriving the target child key, and b) deriving the respective child keys based on respective second results of inputting at least i) the target child key and ii) a respective index into the second hash function, wherein the respective index is a respective value of a sequence.

25. generating a respective blockchain address corresponding to each generated child key; and sending the respective blockchain addresses to different parties.

26. generating one or more blockchain transactions, each including one or more outputs, each output locked to a respective one of the generated child keys; 26. The method of any one of claims 1 to 25, comprising transmitting the one or more blockchain transactions to a blockchain network and / or transmitting the one or more blockchain transactions to different parties.

27. The deriving of the target child key includes recovering the target child key, and the recovering of the target child key includes: generating the master key based on a corresponding seed; and deriving the parent key of the target child key based on the master key.

28. a memory including one or more memory units; 28. A computing device comprising: a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code, when on the processing device, being configured to perform the method of any one of claims 1 to 27.

29. 28. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 27 when executed on one or more processors.

Images