Merkle Proof Entity

Abstract

1. A computer-implemented method for providing proof that a blockchain transaction exists on a blockchain, the method being performed by a Merkle Proving Entity configured to store a set of transaction identifiers for each blockchain transaction but not publish new blockchain blocks to the blockchain network, the method comprising: obtaining a target transaction identifier for a target blockchain transaction, the target transaction identifier forming part of the stored set of transaction identifiers; obtaining a target Merkle proof for the target blockchain transaction, the corresponding target Merkle root being included in a block header of the blockchain; and outputting the target Merkle proof for use by a requesting party as proof that the target blockchain transaction exists on the blockchain.

Description

[Technical Field]

[0001] The present disclosure relates to methods for providing and obtaining proof that a blockchain transaction exists on a blockchain. [Background technology]

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

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

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

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., a certain number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit node performance. Publishing only block headers allows participants to ensure the ongoing integrity of the blockchain.

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

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

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of all accounts is stored and periodically updated by nodes, separate from the blockchain. Summary of the Invention [Means for solving the problem]

[0009] Merkle proofs are commonly used to verify the existence of a transaction on a blockchain. A party (e.g., a user) who wants to verify the existence of a particular transaction on the blockchain can look for a Merkle proof from a blockchain node. If the received Merkle proof can be used to trace the transaction to a value that matches the Merkle proof included in a block on the blockchain, the user can be confident that the transaction exists on the blockchain. Note that for absolute certainty, additional confirmations may be required.

[0010] Currently, the only entities that provide Merkle proofs are blockchain nodes (also known as miners). As mentioned above, blockchain nodes' primary role is to validate transactions and construct and publish blocks.

[0011] As the use of blockchain technology continues to grow, blockchain systems must be able to scale to meet the increasing usage and demand. One approach to scaling blockchain systems is to increase the size of blocks, the rate of transactions, and use blockchain technology as an immutable ledger for various data applications. This dramatically increases the size of the blockchain and the amount of processing consumed to approve transactions. Therefore, the resources required to store the entire blockchain, approve transactions, and respond to queries about transactions may be too expensive (in terms of storage and processing requirements) for end users and service providers. Therefore, there is a need for an entity that can provide proof that a transaction exists on the blockchain without having to store the entire blockchain.

[0012] Therefore, there is a need for a more resource-efficient entity that can provide proof that a transaction exists on the blockchain.

[0013] According to one aspect disclosed herein, there is provided a computer-implemented method for providing proof that a blockchain transaction exists on a blockchain, the method being performed by a Merkle Proving Entity configured to store a set of transaction identifiers for each blockchain transaction but not publish new blockchain blocks to the blockchain network, the method comprising: obtaining a target transaction identifier for a target blockchain transaction, the target transaction identifier forming part of the stored set of transaction identifiers; obtaining a target Merkle proof for the target blockchain transaction, the corresponding target Merkle root being included in a block header of the blockchain; and outputting the target Merkle proof for use by a requesting entity as proof that the target blockchain transaction exists on the blockchain.

[0014] A Merkle proof entity, hereinafter also referred to as a Merkle Proof Server (MPS), is less resource-intensive than a blockchain node because it can provide Merkle proofs to requesting parties without having to construct a new blockchain block and / or publish it to the blockchain network. Publishing a new block to the blockchain network means distributing an unseen block with transactions that have not yet been published in the block on the blockchain. Moreover, in some instances, an MPS does not need to store the entire blockchain, thereby significantly reducing storage requirements compared to a blockchain node. Data storage, data search, and data retrieval are optimized by storing only relevant information, which in this case may be as little as stored transaction identifiers.

[0015] An MPS may provide Merkle proofs for every published transaction by storing only that transaction's respective transaction identifier (i.e., not the transaction data itself). In some cases, an MPS may store only the transaction identifiers of a particular set of blockchain transactions, such as those associated with a particular application or service, e.g., Tokenized or Metanet transactions. The MPS can then be used to verify the existence of Tokenized or Metanet transactions.

[0016] MPS is required to store the transaction IDs (TxIDs) of all published transactions (or at least a set of published transactions). MPS supports queries by transaction identifier (TxID) or by entire transaction.

[0017] An MPS does not perform the operations of constructing and / or publishing blocks on a blockchain. In other words, a Merkle attestation entity is not a blockchain node. In some examples, a Merkle attestation entity does not store any blockchain transactions. In other examples, a Merkle attestation entity stores only one blockchain transaction per block. In still other examples, a Merkle attestation entity stores more than one, but not all, blockchain transactions per block.

[0018] According to another aspect disclosed herein, there is provided a computer-implemented method for obtaining proof that blockchain transactions exist on a blockchain, wherein a Merkle proof entity stores a set of transaction identifiers for each blockchain transaction, wherein the Merkle proof entity is configured to store the set of transaction identifiers for each blockchain transaction but not publish new blockchain blocks to the blockchain network, the method being performed by a requesting party and comprising: sending a target blockchain transaction and / or a target transaction identifier for the target transaction to the Merkle proof entity; and obtaining a target Merkle proof for the target blockchain transaction from the Merkle proof entity, the Merkle proof being based on one or more of the stored set of transaction identifiers.

[0019] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be embodied, reference will be made, by way of example only, to the accompanying figures. [Brief explanation of the drawings]

[0020] [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] FIG. 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] FIG. 1 is a schematic diagram of an exemplary Merkle tree. [Figure 5] FIG. 1 is a schematic diagram of an exemplary Merkle tree. [Figure 6A] FIG. 1 is a diagram illustrating a schematic of an exemplary system according to some embodiments of the present invention. [Figure 6B] FIG. 1 is a diagram illustrating a schematic of an exemplary system according to some embodiments of the present invention. [Figure 7] FIG. 2 is a diagram illustrating schematically data stored by a Merkle certification entity according to some embodiments of the present invention. [Figure 8] FIG. 1 illustrates an exemplary method according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0021] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes 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 highly connected to other blockchain nodes 104.

[0022] Each blockchain node 104 comprises a peer's computing equipment, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing unit comprising 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 comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as high-value disk drives.

[0023] A blockchain 150 comprises 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 network or blockchain network 101. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as property, such as a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and redeem or spend). Each input points to the output of a preceding transaction 152, thereby linking those transactions.

[0024] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the 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 rather than to a preceding transaction.

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

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

[0027] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j may then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, 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 the remaining amount). In some cases, a transaction may also have multiple inputs to pool together amounts from multiple outputs of one or more preceding transactions and redistribute one or more outputs of the current transaction.

[0028] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or organization, wishes to define a new transaction 152j (either manually or through an automated process utilized by the party), the defining party transmits the new transaction from their computer terminal 102 to a recipient. The defining party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 executing the new transaction 152j can transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances not to the recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that a cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction assigns, which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is chained. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be fixed simply by the blockchain node protocol alone, or it may be by a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0029] In an output-based model, the definition of whether a given output (e.g., UXTO) is allocated (e.g., spent) is whether it has already been validly redeemed by the input of another prior 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 the transaction attempts to allocate or redeem has not yet been redeemed by another transaction. Again, if not valid, the transaction 152j is not disseminated (unless flagged as invalid and disseminated for a warning) or recorded in the blockchain 150. This protects against double spending, such as when a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining account balances. Again, because there is a defined order of transactions, an account balance has a single defined state at any given time.

[0030] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, aided by "proof of work," in a process commonly referred to as mining. At blockchain nodes 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. Typically, this involves looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool 154 of outstanding transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain number of leading zeros. Note that this is just one specific type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. This search can therefore only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0031] A first blockchain node 104 attempting to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that it results in a satisfying hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 is then recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. This large amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution indicates the first node's 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously approved transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0032] 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 of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. Protocols also exist for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. That is, whichever tip of the fork has grown longer will become the final blockchain 150. Note that this should not affect users or agents of the network, as the same transactions appear in both forks.

[0033] In the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional acceptable amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof of work indicates the node's intent to construct the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generational) 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 typically called a "transaction fee" and is discussed below.

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

[0035] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 according to the blockchain node protocol. It will be understood that any activity attributable to this specification for a blockchain node 104 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.

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

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

[0038] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage, in the form of a non-transitory computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing unit. It will be understood that any activity attributable to this specification for a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

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

[0041] Note: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example, interfacing via an API or one plugging into another. More generally, 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 with respect to a client application 105, it will be understood that this is not limiting.

[0042] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows 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 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually investigate other parties' transactions in the blockchain 150, since the blockchain 150 is a public entity that lends credibility to some transactions by virtue of its public presence). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to approve transactions 152 according to a blockchain node protocol and forward them for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol accompanies a given node protocol and together 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.

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

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

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

[0046] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it accepts it and discards (i.e., treats as invalid) the instance it originally accepted (i.e., the instance not published in block 151).

[0047] 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 the account-based case, each transaction defines the amount to be transferred by referencing an absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of every account is stored and periodically 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 its "position"). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be signed for the transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in the data field.

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

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

[0050] Suppose Alice 103a wants to create transaction 152j to transfer a certain amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." Tx1 takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor do they mean that Tx1 is the immediate next transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0051] The predecessor transaction Tx0 may already be approved and included in block 151 of the blockchain 150 when Alice creates the new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to 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 the sequence as defined by transaction pointers specified in the transactions (e.g., which transaction points to which other transaction). They may be equally replaced by “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, subsequent transactions (descendant transactions or "children") that point to a preceding transaction (ancestor transaction or "parent") are 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. It may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or node behavior.

[0052] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the condition 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 redeemed. Typically, 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 the unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

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

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

[0055] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which comprises running the lock script and the unlock script together to see if the unlock script meets the conditions defined in the lock script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' are functions contained in the lock script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts could be executed one after the other using a common stack. Either way, when executed together, the scripts will create a lock script containing Alice's public key P, as contained in the lock script in the output of Tx0. Ais used to authenticate that the unlock script in Tx1's input contains Alice's signature signing 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 comprises the entirety of Tx1 (thus there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

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

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

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

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

[0060] In practice, Alice would typically also need to include a fee for any Bitcoin node 104 that succeeds in including Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and therefore not be disseminated or included in the blockchain 150, even though it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require a unique, 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 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by 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 its own one of UTXOs 203 of transaction 152.

[0061] Alice and Bob's digital assets consist of the 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 across the blockchain 150. There is no single number stored anywhere on the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function of the client application 150 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, further transaction. The wallet function can do this by querying a copy of the blockchain 150, such as that stored on one of the Bitcoin nodes 104.

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

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

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

[0065] Client Software 3A shows an example implementation of a client application 105 for implementing embodiments of the techniques disclosed herein. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to perform transaction-related functions behind the scenes of the client 105, such as orchestrating transactions 152, receiving and / or sending transactions and / or other data via side channels 310, and / or sending transactions to one or more nodes 104 for dissemination through the blockchain network 106, according to techniques such as those discussed above and in more detail shortly.

[0066] The UI layer 402 is configured to output information to each user 103 via a user output means of each user's computing device 102, and to render a user interface via a user input / output (I / O) means of the device 102, including receiving input from each user 103 via a user input means of the device 102. For example, the user output means may comprise 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 comprise, for example, one or more touchscreen input arrays (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 speech or voice recognition algorithms for receiving speech or voice input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0067] Note: While various functions herein are sometimes described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split among more than one application. 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 by way of example only, and more generally, the described functionality may be implemented in any form of software.

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

[0069] 3B shows UI 500 from Alice's perspective. UI 500 may comprise one or more UI elements 501, 502, 503 that are rendered as separate UI elements via user output means.

[0070] For example, the UI elements may comprise one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, etc. User input means are adapted to allow a 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-screen or by speaking the name of the desired option (note that the term "manual" as used herein is intended only to contrast with automatic and is not necessarily limited to using hands).

[0071] Alternatively or additionally, the UI element may comprise one or more data entry fields 502. These data entry fields may be rendered via user output means, e.g., on a screen, and data may be entered into the fields via user input means, e.g., a keyboard or touch screen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0072] Alternatively or additionally, the UI element may comprise one or more information elements 503 for outputting information to the user, which may for example be rendered on a screen or in sound.

[0073] It will be understood that the specific 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 Figure 3 is only a schematic mockup and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0074] Merkle Tree A Merkle tree is a hierarchical data structure that allows for secure verification of a collection of data. In a Merkle tree, each node in the tree is given an index pair (i,j), denoted as N(i,j). The indices i,j are simply numeric labels associated with a particular position in the tree.

[0075] An important feature of a Merkle tree is that the construction of each of its nodes is governed by the formula:

[0076]

number

[0077] where H is a cryptographic hash function.

[0078] A binary Merkle tree constructed according to these formulas is shown in Figure 4. As shown, the i=j case is found to correspond to a leaf node, which simply represents the corresponding i-th packet of data D i The cases where i≠j correspond to internal or parent nodes, which are generated by recursively hashing and concatenating child nodes until a single parent (the Merkle root) is found.

[0079] For example, node N(0,3) receives four data packets D0,...,D3. N(0,3)=H(N(0,1)||N(2,3)) =[H(N(0,0)||N(1,1))||H(N(2,2)||N(3,3))] =[H(H(D0)||H(D1))||H(H(D2)||H(D3))] It is constructed as.

[0080] The depth M of a tree is defined as the lowest level of a node in the tree, and the depth m of a node is the level at which the node resides. For example, m root = 0 and m leaf =M, and in Figure 4 M=3.

[0081] In Merkle trees in Bitcoin and some other blockchains, the hash function is double SHA256, which is the application of the standard hash function SHA-256 twice: H(x) = SHA256(SHA256(x)).

[0082] Merkle proof The main feature of a Merkle tree is that it can store several data packets D i is a list or set D∈{D0,...,D N-1 The mechanism for verification is known as a Merkle proof, which proves that a given data packet D i and obtaining a set of hashes known as a Merkle path for the Merkle root R. A Merkle proof for a data packet is simply the minimal list of hashes needed to reconstruct the root R by iterative hashing and concatenation, and is often called an "authentication proof."

[0083] The proof of existence is given by N-1 and their order are known to the prover. However, this requires a much larger storage overhead than a Merkle proof, and also requires that the entire data set be available to the prover. A comparison of using a Merkle proof versus using the entire list is shown in the table below, where we used a binary Merkle tree and assumed that the number of data blocks, N, is strictly equal to a power of two.

[0084] The table below shows the relationship between the number of leaf nodes in a Merkle tree and the number of hashes required for a Merkle proof (or Merkle proof).

[0085] [Table 1]

[0086] In this simplified scenario, where the number of data packets equals the number of leaf nodes, we find that the number of hash values ​​required to compute a Merkle proof scales logarithmically. Clearly, it is much more efficient and practical to compute a Merkle proof that involves log2N hashes than to store N data hashes and compute an unambiguous proof.

[0087] method Given a Merkle proof R, a data block D0 is represented by R as an ordered list D∈{D0,...,D N-1}, we can perform a Merkle proof as follows: i. Obtain the Merkle root R from a trusted source. ii. Obtain a Merkle proof Γ from a source, where Γ is a set of hashes Γ={N(1,1),N(2,3),N(4,7)} is. iii. Compute the Merkle proof using D1 and Γ as follows: a. Hash the data block to get: N(0,0)=H(D0) Concatenate with bN(1,1) and hash to get: N=(0,1)=H(N(0,0)||N(1,1)) Concatenate and hash with cN(2,3) to get: N=(0,3)=H(N(0,1)||N(2,3)) Concatenate with dN(4,7) and hash to get the root. N=(0,7)=H(N(0,3)||N(4,7)) R'=N(0,7) e. Compare the calculated root R' with the root R obtained in (i). 1. If R'=R, then the presence of D0 in the tree and therefore in the dataset D is confirmed. 2. If R' ≠ R, the proof fails and it is not confirmed that D0 is an element of D.

[0088] This is an efficient mechanism for providing proof that some data exists as part of the dataset represented by the Merkle tree and its root. For example, if the data D0 corresponds to a blockchain transaction and the root R is publicly available as part of the block header, then it can be quickly proven that the transaction was included in that block.

[0089] The process of verifying the existence of D0 as part of an exemplary Merkle tree is shown in Figure 5. This shows that performing a Merkle proof for a given block D0 and root R is essentially a traversal of the Merkle tree "upwards" by using only the minimum number of hash values ​​necessary.

[0090] The minimum information required to construct a Merkle proof When constructing a single-leaf Merkle proof, the minimum information required is 1. Leaf index: The position of the leaf in the leaf layer of the Merkle tree. 2. An ordered list of hash values: the hash values ​​needed to compute the Merkle root. is.

[0091] To illustrate how leaf indexes work, consider the Merkle tree in Figure 5. Bob knows the root R, but not all of the leaves of the tree. The Merkle branch for D0 consists of an index, 0, and three hash values ​​(circled). The index indicates whether the provided hash value should be concatenated to the left or right of the computed hash value.

[0092] Merkle tree is N=2 MSuppose we have leaves. Let index i in layer 0, i0=1, b0=i0mod 2,

[0093]

number

[0094] , i.e.

[0095]

number

[0096] Let's say.

[0097] p0 is the index of the paired leaf node of the leaf node with index i0. They are called a pair because they are concatenated and hashed to compute their parent hash node in the Merkle tree (see above). The node with index p0 is also called the "provided hash" or "required data" because it must be provided when computing the Merkle root of the i0 leaf node.

[0098] Therefore, at layer m,

[0099]

number

[0100] It can be defined that

[0101] The index of the hash provided is

[0102]

number

[0103] is.

[0104] The above formula assumes that the index starts at 0.

[0105] In the context of the present invention, the leaf node with index i0 is the transaction identifier of the target transaction.

[0106] Proof of Existence - Transaction 6 illustrates an exemplary system 600 for implementing embodiments of the present invention. The system includes a Merkle certification entity (or Merkle certification server (MPS)) 601. Note that "Merkle certification entity" is used merely as a convenient label for an entity configured to perform the acts described herein. Similarly, the term "Merkle certification server" does not necessarily imply that the acts described are performed by a server (i.e., one or more server units), although that is one possible implementation.

[0107] The MPS 601 is configured to provide proof that a transaction exists on the blockchain 150. The MPS 601 is configured to store a set of transaction identifiers (TxIDs). Each TxID uniquely identifies a respective transaction. The TxID is a hash (e.g., a double hash) of the transaction. The MPS 601 may store the TxID of each transaction for every single transaction published on the blockchain 150. Alternatively, the MPS 601 may store the TxIDs of only some, but not all, of the published transactions. For example, the MPS 601 may store the TxIDs of all transactions that have something in common, e.g., all transactions from a particular block, all transactions published after a certain time (in UNIX time or block height), all transactions from one or more blocks published by a particular blockchain node 104, etc.

[0108] The MPS 601 is not a blockchain node 104. That is, the MPS 601 is not a mining node or "miner." The MPS 601 may be operated by or connected to a blockchain node, but the MPS 601 does not itself perform operations such as performing proof-of-work, constructing blocks, publishing blocks, or enforcing consensus rules. In some examples, the MPS 601 does not approve transactions. However, it is not excluded that the MPS 601 may approve transactions without performing the operation of publishing a block.

[0109] Moreover, although it is not precluded, MPS 601 need not store the entire blockchain 150. That is, MPS 601 need not store all of the published transactions. In some examples, MPS 601 does not store any transactions. Alternatively, MPS 601 may store a selected small number of published transactions, e.g., one or more coinbase transactions.

[0110] The MPS 601 is configured to obtain a target transaction identifier, i.e., the transaction identifier of the target transaction. The target transaction is the transaction for which proof of existence is desired. For example, the system 600 may include one or more requesting parties 602. The requesting entity 602 may transmit the target TxID to the MPS 601 as part of a request for a Merkle proof for the target transaction. In other examples, a third party may transmit the target TxID to the MPS 601 on behalf of the requesting party 602. In some examples, simply transmitting the target TxID to the MPS 601 is treated as a request for a Merkle proof.

[0111] Rather than receiving the target TxID, MPS 601 may instead receive the target transaction itself. That is, the requesting party 602 or a third party may send the target transaction to MPS 601. MPS 601 may then hash (e.g., double-hash) the target transaction to obtain the target TxID. It is not excluded that MPS 601 may receive both the target TxID and the target transaction. In this example, MPS 601 may verify that the (double) hash of the target transaction matches the target TxID and alert the requesting party 602 if they do not match.

[0112] The MPS 601 is also configured to obtain a "target Merkle proof" for the target transaction, i.e., a Merkle proof for proving that the target transaction exists on the blockchain. The target Merkle proof is based on one or more of the stored sets of TxIDs, since the corresponding Merkle tree leaves are actually TxIDs. Merkle proofs are described above. The target Merkle proof comprises at least an ordered set of hash values. The number of hash values ​​in the ordered set of hash values ​​is based on the number of leaves in the Merkle tree, i.e., the number of transactions in the block 151 that contains the target transaction. The Merkle proof may also include a leaf index that indicates whether the first hash value in the ordered set of hash values ​​should be concatenated to the left or right of the target TxID.

[0113] MPS 601 may store a respective Merkle proof for each transaction (i.e., for each TxID). In this example, obtaining the target Merkle proof comprises retrieving the target Merkle proof from storage. For example, MPS 601 may pre-compute a Merkle proof for each transaction. When the target TxID is obtained, MPS 601 looks up the corresponding Merkle proof (each Merkle proof may be associated with a respective TxID in storage).

[0114] Rather than, or in addition to, storing a respective Merkle proof for each transaction or TxID, the MPS may pre-compute and store one or more Merkle trees, each comprising a subset of the stored set of TxIDs, a set of internal hash values ​​(or internal nodes), and a Merkle root. In this example, obtaining the target Merkle proof comprises extracting the Merkle proof (i.e., the required hash value) from a Merkle tree that includes the target TxID.

[0115] As another example, MPS 601 may compute a target Merkle proof in response to obtaining a target TxID. That is, MPS 601 may compute a target Merkle proof using one or more of the stored set of TxIDs (e.g., by computing a full Merkle tree and extracting the required hash value). Note that this method requires MPS 601 to have in storage all of the TxIDs from block 151 that comprise the target transaction.

[0116] A target Merkle proof may comprise one or more internal hashes, or internal nodes, of the corresponding Merkle tree. In that case, it is useful to provide the requesting party with the indexes of those internal hashes so that the requesting party knows whether to concatenate a preceding hash (e.g., the target TxID) to the left or right of the internal hash. Thus, when extracting a target Merkle proof, MPS 601 uses the index of the leaf hash, i.e., the TxID of the target transaction, to calculate the index of the internal hash in the target Merkle proof. The MPS may need to calculate these indices to extract a Merkle proof from a stored tree; i.e., the MPS stores the tree, and the leaf index allows the MPS to determine which internal node to choose from the tree to extract the correct Merkle proof. Note that in at least some examples, MPS 601 need only calculate the index of the target TxID. This single index may be sufficient to determine the required internal hash.

[0117] The MPS 601 is also configured to output the target Merkle proof. For example, the target Merkle proof may be sent directly to the requesting party 602. Or, the target Merkle proof may be published, for example, on a web page. The target Merkle proof may be used as proof that the target transaction exists on the blockchain.

[0118] 8 shows an example method 800 that may be performed by MPS 601. In step 801, the MPS stores a set of TxIDs. In some examples, the TxIDs are ordered based on the order in which the corresponding transactions appear in block 151. In step 802, the MPS 601 obtains (i.e., receives) a target TxID. In step 803, the MPS 601 obtains a Merkle proof for the target TxID (i.e., for the target transaction). The MPS 601 may obtain the Merkle proof, for example, from memory or local storage, or by computing the Merkle proof. In step 804, the MPS outputs the Merkle proof.

[0119] In some examples, the MPS 601 also outputs the Merkle root from the block header of the block 151 containing the target transaction. The Merkle root may be output as part of the block header containing the Merkle root, or by itself, or in combination with one or more other data fields in the block header, such as the previous block hash. The Merkle root may be output directly to the requesting party 602 or otherwise made public.

[0120] MPS 601 may store TxIDs in subsets based on the block in which the corresponding transaction is published. That is, the TxIDs of transactions from block n may be stored in one subset, the TxIDs of transactions from block n-1 may be stored in a different subset, and so on. The TxIDs in each subset may be stored in an ordered list, where the order of the TxIDs matches the order of the corresponding transactions in a given block.

[0121] Each block 151 in the blockchain 150 includes a respective block header. The MPS 601 may store one or more block headers. For example, the MPS 601 may store a block header for each published block 151. The block headers may be stored in an ordered list. The order of the block headers may match the order of the corresponding blocks 151 in the blockchain 150. In some examples, the TxID from a given block 151 may be stored in association with the block header for that block 151.

[0122] For security reasons, all fields of the block header should be stored to be able to reproduce the block header value and validate the proof-of-work. However, instead of storing the complete block header, it is not excluded that in some instances, MPS 601 may store only one or more, but not all, of the data fields of the block header. For example, MPS 601 may store only the Merkle root contained in the block header. Alternatively, MPS 601 may store the Merkle root and the previous hash contained in the block header (the previous hash stored in block header n is equal to the n-1th block header).

[0123] The MPS 601 may obtain some or all of the stored TxIDs from the blockchain network 106, for example, from the blockchain nodes. All of the TxIDs may be obtained from a single blockchain node 104. Alternatively, the TxIDs may be obtained from multiple nodes, e.g., some from one blockchain node, some from different blockchain nodes, etc. The same applies to block headers. That is, some or all of the stored block headers (or just the stored Merkle root and / or previous block hash) may be obtained from a single blockchain node 104 or from multiple nodes 104. In some examples, the MPS 601 may obtain the TxIDs of all transactions from a given block (and optionally the block headers of that block) from the same blockchain node 104.

[0124] In some examples, the MPS 601 may verify some or all of the obtained TxIDs and / or block headers by obtaining the same TxIDs and / or block headers from multiple nodes 104.

[0125] Additionally or alternatively, as shown in FIG. 6, some or all of the block headers may be obtained from one or more simplified payment verification (SPV) clients 604. An SPV client is a client application that stores one, some, or all of a blockchain's block headers and is configured to perform SPV methods. For more information, see, e.g., https: / / wiki.bitcoinsv.io / index.php / Simplified_Payment_Verification. For example, MPS 601 may operate SPV clients or may have connections to SPV clients operated by different entities (not necessarily different MPSs).

[0126] That is, to spend a UTXO, a sender using an SPV wallet passes the following information to the receiver: 1. Transaction Tx0 containing a UTXO as output 2. Merkle Proof of Tx0 3. A block header containing a Merkle root derived from the Merkle proof (or its identifier, e.g., the block height). 4. Transaction Tx1 that consumes UTXO

[0127] To validate the information, the receiver calculates the Merkle root from Tx0's Merkle proof. The receiver then compares it with the Merkle root specified in the block header. If they are the same, the receiver accepts that Tx0 is in the blockchain.

[0128] As mentioned above, MPS 601 may store one or more transactions, i.e., raw transaction data. For example, MPS 601 may store one transaction per block. MPS 601 may store a coinbase transaction for each block (recall that there is only one coinbase transaction per block). However, it is not excluded that MPS 601 may store transactions other than coinbase transactions, or that MPS 601 may store each coinbase transaction for some blocks and a different transaction for other blocks.

[0129] The stored transaction for a given block is called the "first transaction." This does not necessarily mean the transaction that appears first in the block, although it is the case for coinbase transactions. In these examples, MPS 601 may obtain a Merkle proof for the first transaction that is published in the same block as the target transaction. MPS 601 may then output the Merkle proof for the first transaction, along with the first transaction itself, to, for example, requesting party 602. This can be used by requesting party 602 to verify that the length of the target Merkle proof is correct. For example, if the length of the Merkle proof for the first transaction is 10 (e.g., 10 hash values), then the length of the target Merkle proof should also be 10.

[0130] The MPS 601 takes the form of a computing device (e.g., similar to that shown in FIG. 1 ) comprising one or more user terminals, such as a desktop computer, a laptop computer, a tablet, a smartphone, a wearable smart device such as a smartwatch, or an on-board computer of a vehicle such as a car. Additionally or alternatively, the computing device may comprise a server. As used herein, a server refers to a logical entity that may comprise one or more physical server units located at one or more geographic sites. Where required, distributed or “cloud” computing techniques are known per se in the art. One or more user terminals and / or one or more server units of the server may be connected to each other via a packet-switched network, which may comprise, for example, a wide-area internetwork such as the Internet, a mobile cellular network such as a 3GPP network, a wired local area network (LAN) such as an Ethernet network, or a wireless LAN such as a WiFi, Thread, or 6LoWPAN network. The computing device comprises a controller and an interface. The controller is operably coupled to the interface 204. The controller is configured to perform actions attributed to the MPS. The interface is configured to send and receive data, such as TxIDs, block headers, Merkle proofs, etc.

[0131] Each of the controller and interface may be implemented in the form of software code embodied on a computer-readable storage and executed on a processing unit comprising one or more processors, such as a CPU, a work accelerator coprocessor, such as a GPU, and / or other application-specific processors, and implemented on one or more computer terminals or units at one or more geographical sites. The storage on which the code is stored may comprise one or more memory devices utilizing one or more memory media (e.g., electronic or magnetic media), also implemented on one or more computer terminals or units at one or more geographical sites. In an embodiment, the controller and / or interface may be implemented on a server. Alternatively, each instance of one or both of these components may be implemented in part, or even entirely, on one, some, or all of one or more user terminals. In a further example, the functionality of the above-mentioned components may be divided among any combination of user terminals and servers. Again, it should be noted that, where required, distributed computing techniques are themselves known in the art. It is not excluded that one or more of these components may be implemented in dedicated hardware.

[0132] Now, the requesting party 602 will be described. The requesting party 602 is configured to send a request for a Merkle proof to the MPS 601. The requesting party 602 may send the target TxID and / or the target transaction to the MPS 601. In response, the requesting party is configured to receive or otherwise obtain the target Merkle proof. The requesting party 602 may use the target Merkle proof to prove that the target transaction exists on the blockchain. For example, the requesting party 602 may send the target Merkle proof to the receiving party 603, e.g., along with the target transaction. The requesting party 602 may also send the Merkle root of a Merkle tree based on the target transaction to the receiving party 603 (e.g., as part of the block header). The Merkle root may be obtained from the MPS 601.

[0133] In some examples, the requesting party 602 may use a target Merkle proof to prove the existence of one or more parent transactions. In this case, if the target transaction is a child transaction, the target Merkle proof proves that each of the parent transactions was published on the blockchain 150 (a child transaction could not have been published on the blockchain 150 without each of its parent transactions being published on the blockchain 150). In general, a Merkle proof for the most recent published transaction in a chain of transactions proves the existence of all other transactions in that chain.

[0134] The requesting party 602 may be (or may operate) an SPV client. That is, the SPV client (e.g., operated by a consumer) may use the target Merkle proof to perform an SPV method, i.e., by providing the target Merkle proof to another party (e.g., recipient) 603. In this case, the target transaction may comprise a UTXO locked to the consumer, which is referenced by a consume transaction that comprises a UTXO locked to the recipient.

[0135] The requesting party 602 may be (or may operate) a wallet application. The wallet application may store the target transaction. In an online mode or state (i.e., connected to MPS 601), the wallet application may obtain a target Merkle proof for the target transaction. The wallet application may then operate in an offline mode or state (i.e., not connected to MPS 601), and the wallet application may provide the target transaction and the target Merkle proof to the receiving party 603 as proof that the target transaction exists on the blockchain.

[0136] The requesting party 602 may take the form of Alice 103a or Bob 103b.

[0137] The requesting party 602 may be a secondary MPS. The secondary MPS or “integrity MPS” is configured to store a set of blockchain transactions (including the target transaction), send the target TxID to MPS 601 (also called the primary MPS or “general MPS”), obtain the target Merkle proof, and output the target Merkle proof to a secondary requesting party, such as receiving party 603, an end user (e.g., Alice 103a or Bob 103b), etc.

[0138] 6B illustrates an example system 600B illustrating interactions between an integrity MPS 602 and a general MPS 601. As shown, system 600B includes one or more blockchain nodes 104, an integrity MPS 602, a general MPS 601, a requesting party (e.g., a third party user, different from the integrity MPS) 603, and an SPV client 604. System 600B may include multiple requesting parties 603 and / or SPV clients 604.

[0139] Starting with the general MPS 601, its primary role is to provide a Merkle proof for a given transaction identifier (TxID). The general MPS 601 may output the Merkle proof to the requesting party 603 or to the integrity MPS 602. For example, the requesting party 603 or the integrity MPS 602 may send the TxID to the general MPS 601, and in response, the general MPS 601 provides a Merkle proof. The general MPS 601 may obtain the data needed to generate a Merkle proof from one or more sources. For example, the Merkle proof itself may be obtained from the blockchain node 104. Additionally or alternatively, the general MPS 601 may obtain the TxID and corresponding block header from the blockchain node 104 or from the SPV client 604. The general MPS 601 can calculate a Merkle proof using the TxID and corresponding block header.

[0140] As for the integrity MPS 602, its primary role is to provide Merkle proofs to the requesting party 603. The integrity MPS 602 may receive transaction components (or transaction data fields or data items) from the requesting party 603 and, in response, provide a Merkle proof for the transaction including the components. The requesting party 603 may, in response, send the transaction and Merkle proof to another party, for example, an SPV client 604. The integrity MPS 602 may obtain transactions from the blockchain node 104 and / or the SPV client 604. The integrity MPS 601 may also obtain block headers from the blockchain node 104 and / or the SPV client 604 for use as part of the Merkle proof, although the block headers may be calculated by the integrity MPS 602 if sufficient data is available.

[0141] In general, integrity MPS 602 may obtain multiple Merkle proofs, e.g., one for each stored transaction, from general MPS 601. For example, when integrity MPS receives and stores a new transaction, integrity MPS 602 may send a request to general MPS 601 for a Merkle proof for the new transaction.

[0142] Exemplary implementations of several embodiments of the present invention will now be described.

[0143] General MPS The general MPS 601 acts as a dedicated server for providing Merkle proofs to receiving parties, e.g., users. That is, the general MPS 601 is a server that provides Merkle proofs for a given transaction or transaction ID when the transaction is published on the blockchain. The general MPS 601 does not store the complete transaction data. It can be seen as a complement to the SPV client in the blockchain network with storage of Merkle trees. More precisely, the general MPS has the storage requirements listed below: 1. An ordered list of block headers representing the chain with the largest proof of work (optional requirement) 2. An ordered list of transaction IDs for each block header (core requirement) 3. A pre-computed Merkle tree for each block header, whose Merkle root matches the one specified in the block header (optional requirement). 4. The raw data of coinbase transactions in each block or any raw data of transactions in blocks for each block header (optional requirement)

[0144] The first requirement is to ensure data integrity for the general MPS 601. The Merkle root in the block header can be used as an integrity check on the list of transaction IDs. That is, the block header can be used to verify that the TxIDs from a given block provide the Merkle root in the block header when forming the leaves of the Merkle tree. For example, the first requirement can be omitted if the TxIDs are trusted, or if the general MPS 601 has secure access to a trusted SPV client or to any entity trusted to store the block headers of the chain with the largest proof-of-work.

[0145] The second requirement is core because it allows the Merkle tree to be reconstructed given the Merkle leaves in the order they appear in the Merkle tree. Note that the coinbase transaction ID is always the first leaf or first hash in the list. The order of the leaves is determined by the blockchain node that built the winning block. In Bitcoin SV, this order should reflect the topological order and first-seen rule.

[0146] The third requirement provides options for computation and storage tradeoffs. Figure 7 illustrates storage requirements, with solid boxes being required (in some instances) and dashed boxes being optional. Note that while block headers contain additional fields to those shown, generally only the root hash is required for a Merkle proof. Previous hashes can be used to index the root hash. An important point is that a general MPS 601 does not need to store the internal nodes of the Merkle tree. Note that all of the fields in a block header are required to prove a link to a proof-of-work in the block header. The "Prev Hash" field is featured because it indicates the chain relationship between block headers. The "Root Hash" field is featured because it indicates the link to the Merkle tree. However, a link to a proof-of-work can only be approved when all block header components are provided.

[0147] The fourth requirement is to provide proofs of the depth of a Merkle tree. This is an additional service that can be offered by a general MPS 601 to its users. When presented with the raw data of a transaction, any verifier can convince themselves that the first hash in the Merkle proof is indeed a leaf, since it is computationally infeasible to construct a meaningful transaction for a given hash value that is not a leaf. Moreover, the length of a Merkle proof implies the depth of the Merkle tree, so all Merkle proofs from the same tree have the same length. This service is particularly useful when users do not have the raw data of the transaction of interest.

[0148] Given a transaction ID, e.g., TxID1, general MPS 601 looks through the ordered list of transaction IDs. If general MPS 601 finds TxID1, it constructs or extracts and outputs a Merkle proof for TxID1. Otherwise, general MPS 601 outputs, e.g., "transaction not found." Given the raw data of a transaction, general MPS 601 can hash the data to obtain the corresponding transaction ID and proceed as above.

[0149] When a new block is published, the general MPS 601 gets: 1. New block header, 2. An ordered list of transaction IDs for the new block, and 3. Raw Coinbase transactions.

[0150] General MPS 601 may optionally verify the following: 1. The new block header has a valid proof of work, 2. The Merkle root calculated from the transaction ID is equal to the Merkle root in the block header, and 3. The hash of the coinbase transaction is equal to the first element in the leaf.

[0151] Note - There is no requirement for the server to obtain the raw transaction or to perform signature verification on the transaction.

[0152] The following explains why providing the depth of the Merkle tree is a valuable service. An SPV client takes as input a transaction ID and a Merkle proof, and outputs true if the Merkle root matches the Merkle root in one of the block headers, and false otherwise. However, this verification does not check whether the length of the Merkle proof matches the length of the Merkle tree, due to a lack of necessary information. In some cases, an adversary may submit a shortened Merkle proof in an attempt to prove the existence of a non-existent transaction ID. This shortened Merkle proof can be obtained by completely removing the leaf or subsequent hashes.

[0153] As a Merkle proof provider, the general MPS 601 is in the best position to provide the information needed to verify the length of a Merkle proof. Rather than explicitly providing the depth of the Merkle tree, the general MPS 601 provides the raw data of the coinbase transaction and its Merkle proof. Forging the raw transaction data and Merkle proof is computationally infeasible. Therefore, it serves as a proof of the depth of the Merkle tree. Knowing the tree depth can mitigate the critical vulnerability mentioned above. Note that if the SPV is provided with the raw data of the transaction of interest and its Merkle proof, the SPV is secure against this vulnerability. When the SPV does not have the raw data of the transaction of interest, it can use the raw data of the coinbase transaction and its Merkle proof to establish the depth of the Merkle tree or the correct length of the Merkle proof for this Merkle tree.

[0154] In theory, this vulnerability could also be used to trick the general MPS 601 into accepting a Merkle tree whose leaf or any subsequent level is completely removed. However, the general MPS 601 may connect to multiple blockchain nodes 104 to ensure the consistency and correctness of the information received. Moreover, the general MPS 601 may also choose to download the raw data of coinbase transactions to verify the depth of the Merkle tree for new blocks.

[0155] Occasionally, the general MPS 601 must deal with conflicting blocks, reorganizations, and orphan blocks, which occur when more than one block is found at the same block height at the same time. Fortunately, this situation does not occur, except for the most recent header, and is rare. The blockchain 150 typically converges to one of the competing chains after two blocks. Therefore, when the general MPS 601 receives more than one block 151 at the same height, it maintains all of them until the blockchain network converges to the chain with the greatest proof-of-work.

[0156] Storage savings Currently, there are roughly 500 million transactions in total on the BSV global ledger (a similar order of magnitude for BTC). The entire TxID requires roughly 15GB of storage space. The BSV blockchain itself is currently 224GB. A typical MPS601 needs to store 6.7% of the entire blockchain. Furthermore, storage depends on the number of transactions, not their size. If a block is 638009 high and the block header is 80 bytes, the block header requires 49MB of storage, with an additional 4MB added each year.

[0157] If a typical MPS 601 were to store pre-computed portions of the Merkle tree to accelerate Merkle proof generation, the first layer after the root node would consist of two nodes, requiring 2 x 32 bytes per tree. Thus, 64 bytes concatenated with the 80 bytes of the block header saves the MPS one hash calculation when generating the Merkle branch for any transaction. That is, the MPS uses 144 bytes instead of 80 bytes per header. The second layer of the Merkle tree consists of four nodes, or 272 bytes per header, and so on. The tenth layer requires 65,552 bytes per header, increasing the total storage requirement to 39 GB. This should include 15 GB of TXIDs, and assumes each block has 1,024 transactions.

[0158] TxID-only MPS constraints The general MPS 601 as described has some limitations: Transactions that are not publicly exposed, e.g., TxID payment Given a TxID, the general MPS 601 cannot verify that the output point referenced in the input exists because the output point is a concatenation of the transaction ID and the index. The general MPS 601 can determine if the transaction ID exists, but does not have information about how many outputs the transaction has and whether the outputs are consumable. One way to overcome this is to use the TxID payment The first method is to provide the raw data of the transactions referenced in to general MPS 601 as part of the input. An alternative method is for general MPS 601 to store the raw data of unconsumed transactions (here, unconsumed transactions refer to transactions that have at least one unconsumed consumable output).

[0159] Note that if the general MPS 601 stores only the transaction ID and the corresponding index, the general MPS 601 cannot verify or prove that the index has not been tampered with. The general MPS 601 requires the complete raw data to verify or prove the integrity of the index.

[0160] Moreover, it cannot enable users to look for specific data elements inside a transaction, such as lock scripts or flags, and therefore cannot support users using Bloom filters, for example, because Bloom filters typically filter transactions based on the lock scripts and public keys included in the transaction.

[0161] This necessitates an MPS that can provide information at a more detailed level. We call this an integrity MPS. An integrity MPS stores the raw data of some transactions. Note that the general MPS 601 can be used to prove the integrity of published transactions if the full transactions are provided by the user. An integrity MPS can be used to prove the integrity of some data extracted from published transactions by storing the full transactions of interest. It does not require the user to present the full transactions.

[0162] Integrity MPS An integrity MPS stores raw transactions and their corresponding Merkle proofs for a set of transactions of interest. For queries about transactions in this set, the server can provide the raw transaction and its Merkle proof as its integrity proof. It also makes it possible to look for partial transactions or data elements within the transaction content. Transactions of interest may be determined based on a data application such as Weather SV, Tokenized, Metanet, or any other data protocol, or even based on data strings such as lock scripts, public keys, output points, etc. Thus, there may be an integrity MPS for just the Weather SV application that is configured to store transactions that carry only Weather SV.

[0163] The set of interesting raw transactions is passed to the integrity MPS and persists to a server if it is publicly available. The integrity MPS can be thought of as a gateway or has access to a gateway for specialized transactions. This is the most efficient way to maintain the integrity MPS as the blockchain system scales to terabyte blocks. Other cases, such as fully decentralized peer-to-peer data applications, must rely on mechanisms to download complete blocks of transactions and prune or filter out those that are not of interest, as in Bitcoin Improvement Proposal 37 (BIP37) using Bloom filters.

[0164] Working An integrity MPS that maintains the raw transactions of interest and their Merkle proofs in a Merkle tree performs the following steps in some embodiments: Step 1: Get the raw transactions of interest. Step 2: Hash the raw transaction to get the transaction ID. Step 3: Query the general MPS 601 for its Merkle proof. Step 4: If the transaction is not published in a block, wait 10 minutes and try again.

[0165] The reliance on the general MPS 601 in step 3 can be replaced by a download and pruning mechanism, but this is less efficient. The private transactions in step 4 can be omitted after a predefined time limit to avoid congestion. This limit can vary from application to application.

[0166] A transaction can be proven to be published on the blockchain 150 by providing its Merkle proof. Alternatively, it can be proven through one of its consumed outputs. i The output of transaction tx j When consumed in i is called the parent transaction, and tx j is called a child transaction. A transaction having multiple outputs implies that it may have multiple children. A transaction having multiple inputs implies that it may have multiple parents. If the raw data of a transaction is available, the Merkle proof of this transaction is sufficient to prove that all of its parents are public; there is no need to store the Merkle proofs of the parents.

[0167] In practice, we can generalize the above observation by stating that if we have a chain of transactions, then a Merkle proof of the last transaction in the chain and the raw data of all transactions can prove the existence of all transactions in the chain.

[0168] This makes it possible to remove a transaction's Merkle proof and replace it with the Merkle proof of one of its children, which can be useful in the following cases: 1. Block size - The child transaction is published in a much smaller block than the parent transaction, in which case the overall size of the child transaction and its Merkle proof is smaller than the size of the Merkle proof for the parent transaction, or 2. Multiple Inputs - A child transaction has multiple inputs from different transactions, in which case the total size of the child transaction and its Merkle proof is smaller than the total size of all Merkle proofs for its parent transaction.

[0169] For example, in certain applications, every transaction may have a dedicated Merkle proof output. Sometimes these outputs are collected and consumed in one child transaction. The child transaction and its Merkle proof can prove the integrity and existence of all its parent transactions. Therefore, there is no need to store any of the parent transactions' Merkle proofs.

[0170] The observations can be summarized in the following table, which lists the evidence that can be derived from the data provided.

[0171] [Table 2]

[0172] This table shows that an output is proven to exist if: 1. A raw transaction is provided and a transaction exists, or 2. When that output or a higher indexed output is used in payment for an existing transaction.

[0173] conclusion Other variations or uses of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is limited only by the appended claims, and not by the described embodiments.

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

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

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

[0177] Also more generally, 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, publishing, disseminating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with respect to blockchain node 104.

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

[0179] STATEMENT 1. A computer-implemented method for providing proof that a blockchain transaction exists on a blockchain, the method being performed by a Merkle Proof Entity configured to store a set of transaction identifiers for each blockchain transaction but not publish new blockchain blocks to the blockchain network, the method comprising: obtaining a target transaction identifier for a target blockchain transaction, the target transaction identifier forming part of a stored set of transaction identifiers; obtaining a target Merkle proof for a target blockchain transaction, the corresponding target Merkle root being included in a block header of the blockchain; and outputting a target Merkle proof for use by a requesting party as proof that the target blockchain transaction exists on the blockchain.

[0180] A Merkle attestation entity does not perform the operations of constructing and / or publishing blocks on a blockchain. In other words, a Merkle attestation entity is not a blockchain node. In some examples, a Merkle attestation entity does not store any blockchain transactions. In other examples, a Merkle attestation entity stores only one blockchain transaction per block. In still other examples, a Merkle attestation entity stores some or all of the blockchain transactions per block.

[0181] Statement 2: The method of statement 1, wherein the Merkle proof entity does not store the entire blockchain.

[0182] Statement 3. The method of statement 1 or statement 2, wherein obtaining the target Merkle proof comprises calculating an index of the target transaction identifier in a leaf layer of the corresponding target Merkle tree.

[0183] Statement 4. The method of statement 3, comprising outputting the index to a requesting party.

[0184] Statement 5. The method of any preceding statement, wherein said step of obtaining a target transaction identifier comprises obtaining a target transaction identifier from a requesting party.

[0185] Statement 6. The method of any preceding statement, wherein the step of obtaining a target transaction identifier comprises the steps of obtaining a target blockchain transaction and constructing a target transaction identifier based on the target blockchain transaction.

[0186] The target blockchain transaction may be received from a requesting party.

[0187] Statement 7. The method of any preceding statement, wherein the step of obtaining a target Merkle proof comprises calculating a target Merkle proof using one or more of the stored set of transaction identifiers.

[0188] Statement 8. The method of any preceding statement, wherein the Merkle proof entity stores a respective Merkle proof for one or more of a stored set of transaction identifiers including the target transaction identifier, and wherein said step of obtaining the target Merkle proof comprises extracting the target Merkle proof from a storage location.

[0189] Statement 9. The method of any preceding statement, wherein said step of outputting a target Merkle proof comprises the step of transmitting the target Merkle proof to a requesting party.

[0190] Statement 10. The method of any preceding statement, wherein the step of outputting the target Merkle proof may comprise the step of publishing the target Merkle proof.

[0191] Statement 11. The method of any preceding statement, wherein the Merkle attestation entity stores one or more Merkle roots, each Merkle root based on a respective subset of the stored set of transaction identifiers.

[0192] Statement 12. The method of statement 11, comprising outputting to a requesting party a Merkle route based on a target transaction identifier.

[0193] Statement 13: The method of statement 11 or statement 12, wherein the Merkle certification entity stores a Merkle tree for each of the one or more Merkle roots.

[0194] Statement 14. The method of statement 13, wherein the step of obtaining the target Merkle proof comprises extracting the target Merkle proof from a stored Merkle tree that comprises the target transaction identifier.

[0195] Statement 15. The method of any preceding statement, wherein the stored set of transaction identifiers comprises multiple subsets of transaction identifiers, each subset of transaction identifiers comprising all transaction identifiers from a respective block of the blockchain.

[0196] Each subset of transaction identifiers may be stored in an ordered list corresponding to the order of the blockchain transactions stored in the respective block.

[0197] Statement 16. The method of statement 15, wherein each subset of transaction identifiers is stored in association with a respective block header of a respective block of the blockchain.

[0198] Each block header may be stored in an ordered list that corresponds to the order in which the blocks are published on the blockchain.

[0199] Statement 17. The method of any preceding statement, comprising storing a respective transaction identifier for each blockchain transaction published on the blockchain.

[0200] Statement 18. The method of any preceding statement, wherein at least some of the stored set of transaction identifiers are obtained from one or more blockchain nodes.

[0201] For example, all of the stored transaction identifiers may be obtained from a blockchain node.

[0202] Statement 19. The method of Statement 16 or any statement dependent thereon, wherein at least some of the block headers are obtained from one or more blockchain nodes and / or at least some of the block headers are obtained from one or more simplified payment verification (SPV) client applications.

[0203] Statement 20. The method of statement 16 or any statement dependent thereon, wherein the Merkle Proving Entity operates or has access to an SPV client application that stores one or more of the block headers.

[0204] Statement 21. The method of statement 15 or any statement dependent thereon, wherein the Merkle proof entity stores, for each subset of transaction identifiers, the first blockchain transaction from a respective block.

[0205] statement 22 obtaining a first Merkle proof for a first blockchain transaction, the first Merkle proof being based on one or more of the stored set of transaction identifiers; and outputting the first blockchain transaction and the first Merkle proof for use by the requesting party to verify that the length of the target Merkle proof matches the length of the corresponding target Merkle tree.

[0206] Statement 23. The method of statement 22, wherein the first blockchain transaction is a generation transaction.

[0207] A creation transaction, also known as a coinbase transaction or initial transaction, is the logically first published transaction in a block. It is created by the blockchain node that published that block.

[0208] Statement 24. The method of any preceding statement, wherein the requesting party operates a simplified payment verification (SPV) client application.

[0209] The requesting party may operate an offline wallet application.

[0210] STATEMENT 25. The method of any of statements 1 to 23, wherein the requesting party stores a set of blockchain transactions comprising the target blockchain transaction and comprises a secondary Merkle proof entity configured to output the target Merkle proof to a second requesting party.

[0211] For example, the second requesting party may be an end user.

[0212] Statement 26: A computer-implemented method for obtaining proof that blockchain transactions exist on a blockchain, wherein a Merkle proof entity stores a set of transaction identifiers for each blockchain transaction, the Merkle proof entity is configured to store the set of transaction identifiers for each blockchain transaction but not publish new blockchain blocks to the blockchain network, the method being performed by a requesting party; sending a target blockchain transaction and / or a target transaction identifier of the target transaction to a Merkle proof entity; and obtaining a target Merkle proof for the target blockchain transaction from a Merkle proof entity, the Merkle proof being based on one or more of the stored set of transaction identifiers.

[0213] Statement 27. The method of statement 26, comprising transmitting the target Merkle proof to a second requesting party as proof that the target blockchain transaction exists on the blockchain.

[0214] Statement 28. The method of statement 26 or statement 27, wherein the target blockchain transaction is the most recent transaction in a chain of blockchain transactions, the requesting party has access to each transaction in the chain of blockchain transactions, and the target Merkle proof is proof that each transaction in the chain of blockchain transactions exists on the blockchain.

[0215] Statement 29: A memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code adapted to execute on the processing device, the code being configured, when executed on the processing device, to perform the method of any of statements 1 to 25.

[0216] STATEMENT 30. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1 to 25 when executed on one or more processors.

[0217] statement 31 a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code adapted to execute on the processing device, the code being configured, when executed on the processing device, to perform the method of any of statements 26 to 28.

[0218] STATEMENT 32. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 26-28 when executed on one or more processors.

[0219] According to another aspect disclosed herein, a method may be provided comprising the actions of a Merkle certification entity and a requesting party.

[0220] According to another aspect disclosed herein, a system may be provided that includes a Merkle certification entity and a requesting party's computing device. [Explanation of symbols]

[0221] 100 systems 101 Blockchain networks, packet-switched networks, and the Internet 102 Computer equipment, computer terminals 103 User, Parties 104 blockchain nodes 105 Client Applications 106 Peer-to-Peer (P2P) Networks, Networks 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 sets, pool 155 Block Pointer 201 Header 202 Input field, input, 203 Output Fields, Outputs, Transaction Outputs, UTXO 500 UI 501 UI elements 502 UI elements 503 UI elements 601 General Merkle Path Server 602 Integrity Merkle Path Server 603 Requesting Party 604 SPV Client

Claims

1. 1. A computer-implemented method for providing proof that a blockchain transaction exists on a blockchain, comprising: the method is performed by a Merkle Proofing entity configured to store a set of transaction identifiers for each blockchain transaction but not publish new blockchain blocks to a blockchain network; The method comprises: obtaining a target transaction identifier for a target blockchain transaction, the target transaction identifier forming part of the stored set of transaction identifiers; obtaining a target Merkle proof for the target blockchain transaction, the corresponding target Merkle root being included in a block header of the blockchain; outputting the target Merkle proof for use by a requesting party as proof that the target blockchain transaction exists on the blockchain; A method comprising:

2. The method of claim 1 , wherein the Merkle proof entity does not store the entire blockchain.

3. 3. The method of claim 1 or claim 2, wherein obtaining the target Merkle proof comprises computing an index of the target transaction identifier in a leaf layer of a corresponding target Merkle tree.

4. The method of claim 3, comprising outputting the index to the requesting party.

5. 5. The method of claim 1, wherein obtaining the target transaction identifier comprises obtaining the target transaction identifier from the requesting party.

6. the step of obtaining the target transaction identifier comprises: obtaining the target blockchain transaction; constructing the target transaction identifier based on the target blockchain transaction; 6. The method of claim 1, comprising:

7. 7. The method of claim 1, wherein obtaining the target Merkle proof comprises computing the target Merkle proof using one or more of the stored set of transaction identifiers.

8. the Merkle proof entity stores a respective Merkle proof for one or more of the stored sets of transaction identifiers, including the target transaction identifier; 8. The method of claim 1, wherein obtaining the target Merkle proof comprises extracting the target Merkle proof from a storage location.

9. 9. The method of claim 1, wherein outputting the target Merkle proof comprises transmitting the target Merkle proof to the requesting party.

10. 10. The method of claim 1, wherein outputting the target Merkle proof comprises publishing the target Merkle proof.

11. the Merkle certification entity stores one or more Merkle roots; 11. The method of claim 1, wherein each Merkle root is based on a respective subset of the stored set of transaction identifiers.

12. 12. The method of claim 11, comprising outputting the Merkle root to the requesting party based on the target transaction identifier.

13. 13. A method according to claim 11 or claim 12, wherein the Merkle certification entity stores a Merkle tree for each of the one or more Merkle roots.

14. 14. The method of claim 13, wherein obtaining the target Merkle proof comprises extracting the target Merkle proof from a stored Merkle tree that comprises the target transaction identifier.

15. the stored set of transaction identifiers comprises a plurality of subsets of transaction identifiers; 15. The method of claim 1, wherein each subset of transaction identifiers comprises all transaction identifiers from a respective block of the blockchain.

16. 16. The method of claim 15, wherein each subset of transaction identifiers is stored in association with a respective block header of the respective block of the blockchain.

17. 17. The method of any one of claims 1 to 16, comprising storing a respective transaction identifier for each blockchain transaction published on the blockchain.

18. 18. The method of any one of claims 1 to 17, wherein at least some of the stored set of transaction identifiers are obtained from one or more blockchain nodes.

19. at least some of the block headers are obtained from one or more blockchain nodes; and / or 17. The method of claim 16, wherein at least some of the block headers are obtained from one or more simplified payment verification (SPV) client applications.

20. 17. The method of claim 16, wherein the Merkle proofing entity operates or has access to an SPV client application that stores one or more of the block headers.

21. 16. The method of claim 15, wherein the Merkle proof entity stores, for each subset of transaction identifiers, a first blockchain transaction from the respective block.

22. obtaining a first Merkle proof for the first blockchain transaction, the first Merkle proof being based on one or more of the stored set of transaction identifiers; outputting the first blockchain transaction and the first Merkle proof for use by the requesting party to verify that the length of the target Merkle proof matches the length of a corresponding target Merkle tree; 22. The method of claim 21, comprising:

23. 23. The method of claim 22, wherein the first blockchain transaction is a creation transaction.

24. 24. The method of any one of claims 1 to 23, wherein the requesting party operates a simplified payment verification (SPV) client application.

25. 24. The method of any one of claims 1 to 23, wherein the requesting party comprises a secondary Merkle proof entity configured to store a set of blockchain transactions that comprise the target blockchain transaction and to output the target Merkle proof to a second requesting party.

26. a memory comprising one or more memory units; a processing device comprising one or more processing units; 26. A computing device comprising: a memory for storing code configured to execute on the processing unit; and the code configured, when executed on the processing unit, to perform the method of any one of claims 1 to 25.

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

Images