Method and system for enabling verification of data

Abstract

A computer implemented method of enabling verification of presence of a data item on a blockchain is disclosed. First data comprising a Merkle proof (h1, h2, h3, h4, h5, h6) of second data representing at least one input and / or output (t) of a blockchain transaction is generated and stored. Third data is published on a blockchain, wherein the third data comprises at least one data item (tp) used in generating the Merkle proof.

Description

[0001] METHOD AND SYSTEM FOR ENABLING VERIFICATION OF DATA

[0002] Technical Field

[0003] The present disclosure relates to a method and system for enabling verification of the presence of a data item on a blockchain, and relates particularly, but not exclusively, to a method and system for enabling verification of the presence of an input and / or output of a blockchain transaction on the blockchain.

[0004] Background

[0005] A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a “blockchain network”) and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called “coinbase transactions”, points back to a preceding transaction in a sequence which may span one or more blocks up until one or more coinbase transactions. Coinbase transactions are discussed below. Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as “mining”, which involves each of a plurality of the nodes competing to perform “proof- of- work”, i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at a node, and the publication of blocks can be achieved through the publication of mere block headers.

[0006] The transactions in the blockchain are used to perform one or more of the following: to convey a digital asset (i.e. a number of digital tokens), to order a set of journal entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to time-order index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. Blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data. Nodes of the blockchain network (which are often referred to as “miners”) perform a distributed transaction registration and verification process, which will be described in detail below. In summary, during this process a node validates transactions and inserts them into a block template for which they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes of the network, thus enabling each node to record the new block on the blockchain. In order to have a transaction recorded in the blockchain, a user (e.g. a blockchain client application) sends the transaction to one of the nodes of the network to be propagated. Nodes which receive the transaction may race to find a proof-of-work solution incorporating the validated transaction into a new block. Each node is configured to enforce the same node protocol, which will include one or more conditions for a transaction to be valid. Invalid transactions will not be propagated nor incorporated into blocks. Assuming the transaction is validated and thereby accepted onto the blockchain, then the transaction (including any user data) will thus remain registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0007] The node who successfully solved the proof-of-work puzzle to create the latest block is typically rewarded with a new transaction called the “coinbase transaction” which distributes an amount of the digital asset, i.e. a number of tokens. The detection and rejection of invalid transactions is enforced by the actions of competing nodes who act as agents of the network and are incentivised to report and block malfeasance. The widespread publication of information allows users to continuously audit the performance of nodes. The publication of the mere block headers allows participants to ensure the ongoing integrity of the blockchain.

[0008] In an “output-based” model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a IITXO (“unspent transaction output”). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

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

[0010] An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the IITXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

[0011] One area of current research is the use of the blockchain for the implementation of “smart contracts”. These are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike a traditional contract which would be written in natural language, a smart contract is a machine-executable program, which comprises rules that can process inputs in order to produce results, which can then cause actions to be performed dependent upon those results. Another area of blockchain-related interest is the use of ‘tokens’ (or ‘coloured coins’) to represent and transfer real-world entities via the blockchain. A potentially sensitive or secret item can be represented by the token, which has no discernible meaning or value. The token thus serves as an identifier that allows the real- world item to be referenced from the blockchain.

[0012] As block size increases, the resource required to store the full blockchain data and respond to queries on transactions becomes very costly for end users and service providers. To address this issue, Merkle Path Servers (MPS) were introduced. MPS are servers dedicated exclusively to the storage and distribution of transaction information (e.g., Merkle proofs). MPS may monitor some specific types of transactions (e.g., overlay network transactions), and are required to quickly access and retrieve information about these transactions.

[0013] Storing entire transactions can be costly. Instead, storing only required inputs and outputs provides more efficient disk space management. Indeed, not all the input and outputs of transactions are of interest to an MPS. For instance, if the MPS monitors an overlay network on the blockchain, then it may prefer to filter out inputs and outputs that are not directly relevant to the overlay network (e.g., funding inputs). This reduces the amount of information on each transaction that is stored, but at the same time may create storage redundancy. Indeed, these input and outputs share multiple information (e.g., the Merkle proof).

[0014] Accordingly, there is a desire to implement a more efficient storage solution that allows for MPSs to store information on individual inputs and outputs.

[0015] Such an improved solution has now been devised.

[0016] Summary of the Invention

[0017] According to an aspect of the disclosure, there is provided a computer implemented method of enabling verification of presence of a data item on a blockchain, the method comprising: generating first data comprising a Merkle proof of second data representing at least one part of a blockchain transaction; storing said first data; and publishing third data on a blockchain, wherein said third data comprises at least one data item used in generating said Merkle proof.

[0018] By generating first data comprising a Merkle proof, , and publishing third data on a blockchain, wherein the third data comprises at least one data item used in generating the Merkle proof, this provides the advantage of enabling more efficient data storage, since only the Merkle proofs of parts of interest of blockchain transactions, for example inputs and / or outputs of interest, need to be generated and stored.

[0019] The method may further comprise dividing the first data into a plurality of portions. This provides the advantage of further improving efficiency of data storage, while also improving data retrieval, since a plurality of inputs and / or outputs of blockchain transactions will have one or more of said portions in common, such that each portion only needs to be stored once.

[0020] The portions may be non-overlapping portions of said Merkle proof.

[0021] This provides the advantage of enabling the portions common to more than one input and / or output to be stored only once, thereby reducing the number of data items to be stored and improving efficiency of data storage.

[0022] The method may further comprise using said third data to index said portions for storage.

[0023] This provides the advantage of improving the efficiency of data storage and subsequent data retrieval, for example by using the third data to store the portions in a distributed hash table.

[0024] The second data may represent at least one input and / or at least one output of the blockchain transaction.

[0025] This provides the advantage of enabling the second data to be restricted to inputs and / or outputs of interest, thereby enabling more efficient data storage.

[0026] The second data may comprise data representing at least one of: identification of said blockchain transaction, a position of an input and / or output in said blockchain transaction, an indication of whether said input and / or said output is an input or an output of said blockchain transaction, a position of said blockchain transaction in a block, a locking script of an input and / or output of said blockchain transaction, an unlocking script of an input of said blockchain transaction and / or an amount of a digital asset.

[0027] The third data may represent at least one function used to determine said Merkle proof. The third data may comprise fourth data representing at least one Merkle tree node defined by a predetermined level of a Merkle tree corresponding to said Merkle proof.

[0028] This provides the advantage of enabling more efficient partial reconstruction of the Merkle proof.

[0029] A function having a homomorphic property may be applied to said fourth data.

[0030] Elliptic curve point multiplication may be applied to the fourth data.

[0031] This provides the advantage of enabling more efficient data storage and verification.

[0032] The fourth data may comprise a sum of elliptic curve point data, wherein each said elliptic curve point represents a respective Merkle tree node at said predetermined level of said Merkle tree.

[0033] This provides the advantage of enabling more rapid verification of data.

[0034] The method may further comprise communicating at least part of said first data to a user in response to query by said user relating to said second data.

[0035] According to another aspect of the disclosure, there is provided a device comprising a processor and memory, the memory including executable instructions that, as a result of execution by the processor, cause the device to perform the computer-implemented method as defined above.

[0036] According to a further aspect of the disclosure, there is provided a non-transitory computer readable storage medium comprising computer program code instructions, being executable by a computer, to carry out the method as defined above. According to a further aspect of the disclosure, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method as defined above.

[0037] An embodiment of the disclosure will now be described, by way of example only, and not in any limitative sense, with reference to the accompanying drawings, in which:-

[0038] Brief Description of the Figures

[0039] Figure 1 is a schematic diagram of a Merkle tree relating to an embodiment;

[0040] Figure 2a illustrates a system in accordance with an embodiment;

[0041] Figure 2b illustrates a node configured to implement the Bitcoin software in order to validate a blockchain transaction; and

[0042] Figure 2c illustrates a blockchain network.

[0043] A storage solution is proposed that allows for Merkle proof servers (MPSs) to store information on individual inputs and outputs of a blockchain transaction. Moreover, since many inputs and outputs share most of the same Merkle tree, a further optimisation is achieved by sharding the Merkle proofs in consecutive segments that are reused when possible. These segments are then appropriately indexed to allow for complete Merkle proof retrieval. How additional on- chain information allows for users of the MPS to retrieve only a limited number of shards of the Merkle proof and verify the root of the sub-tree they computed using this information is described below.

[0044] While any type of MPS can benefit from the proposed solution, the MPSs that benefit the most from it are MPSs that monitor transactions characterized by a large number of inputs or outputs and interested only in a limited amount of them. Examples of use cases that satisfy this requirement are described at the end of this document.

[0045] Referring to Figure 1 , a Merkle tree of an output of a blockchain transaction comprises first data in the form of a Merkle proof [hi, h2, ha, h4, hs, he] of second data in the form of a transaction ID t, and third data in the form of data items used in generating the Merkle proof. A data storage method consists of 3 steps: filtering, sharding, and indexing. In the filtering stage, the MPS isolates relevant transactions from newly created blocks and extracts the individual inputs and outputs from the transaction. In the sharding stage, the MPS first computes Merkle proofs and then shards them into multiple pieces. During the indexing phase, values are indexed and stored in a database.

[0046] During the filtering stage, the MPS identifies and extracts individual inputs and outputs from block transactions for long term storage. These transactions of interest to the MPS are called monitored transactions. During the filtering stage there are two steps:

[0047] 1. Identification of the monitored transactions in the block. The criterion used by the MPS to identify the transactions varies based on the primary function of the MPS.

[0048] 2. Extraction of the relevant inputs and outputs from the monitored transactions. The values that are of no interest for the MPS are discarded.

[0049] During the sharding stage, the Merkle proofs of the transactions are computed and sharded. Let h±, ..., hnbe the sequence of hashes in a Merkle proof; a shard S-+kof the Merkle proof is a subset of consecutive hashes hi, ..., hi+k. The MPS divides the Merkle proofs of the monitored transactions into non-intersecting shards S- ,St+1, ...,S{tl+1. The shards can be of fixed or variable length.

[0050] During the indexing stage, the information computed in the previous stage is added to the relevant databases. Appropriate indexing should facilitate data retrieval. Shards can be identified by hashes. Let x0be the ID of a transaction with Merkle proof hlt..., hn, and let x, = is the function used in each step of the Merkle proof (e.g., fi(xi-, hi') = hOi-il l / ii) for a choice of a hash function h). Then the Merkle proof can be verified (i.e. the Merkle tree can be reconstructed) from shards and the value xi-1.

[0051] The MPS can rely on multiple databases to store information. For simplicity, it is assumed the MPS uses the following three databases. The first database TDBcontains information on the inputs and outputs the MPS stores. The second database SDBcontains information on the shards of Merkle proofs. The last database BDBcontains block information. The database BDBis significantly smaller than the other two, and should contain all the relevant information for the MPS.

[0052] Entries in the database TDBare uniquely identified by the following three values: the ID of the transaction that contains the input / output, the position of the input / output in the transaction, and a flag to determine whether the entry represents an input or an output. Beside these values, optional attributes can be the position in the block, the locking script, and the unlocking script (for inputs).

[0053] Entries in the database SDBcorrespond to shards. The shard s is uniquely identified by the value xi-1. All the elements of the Merkle proof included in the shard should also be tracked to ensure Merkle proof retrieval. Optionally, information on the initial and final level of the shard (i.e., the values i and j), and a link to the following shard in the Merkle proof can be included.

[0054] How storing additional block information on-chain can be used by the MPS to reduce the amount of data stored in the database and shared with users is discussed below.

[0055] Blocks contain only information on the Merkle root of the Merkle tree. However, truncated Merkle proof and knowledge of internal nodes of the tree can also be used to verify transactions.

[0056] The MPS or an independent service can publish on the blockchain the labels of all the nodes in a certain level of the Merkle tree. Then the MPS provides users with enough shards of the Merkle path to reach that level in the Merkle tree. Users can verify the hash they computed relying on the on-chain information. It should be noted that that this does not require the on- chain information nor the MPS to be trusted, since this information provides enough data to compute the Merkle root of a block.

[0057] The arrangement described above presents a trade-off between the amount of information the MPS provides, and the number of hashes published on the blockchain: providing too few hashes on the blockchain does not significatively reduce communication costs, while storing too many data on the blockchain incurs higher transaction fees.

[0058] Referring again to Figure 1 , by way of example, let Alice be a user of the MPS. It should be assumed that Alice is interested in an output of a transaction with transaction ID t. This transaction is in a block with 7 levels (with the root being at level 0, and the leaves at level 6) and Merkle root R. Let the Merkle proof of the transaction with transaction ID t be h , ..., h6, with hrdenoting the label of a leaf. Finally, let / q, ..., kadenote all the labels of the nodes at level 2 in the Merkle tree. It should be noted that a < 4 and that knowing k , ..., kais enough to compute R.

[0059] The MPS divides this Merkle proof into 3 shards Si,S , and S® . The MPS publishes on-chain the values / , ..., ka. Alice queries the output she is interested in, and she receives the shards S^, and S3 in response. She uses this information to compute part of the Merkle proof and obtain a value tp. The value tpis the label of a node at level 2. Alice checks the value tpwith the hashes shown on-chain.

[0060] Fourth data in the form of elliptic curve points can be used to compress information on labels of nodes of the Merkle tree so that a single point represents multiple nodes, an entire level, or even the complete tree. In this section, it is assumed that each elliptic curve point corresponds to a level of the Merkle tree. However, this solution can be adapted to different scenarios. Compressing Merkle tree information using elliptic curve points reduces the amount of data saved on the blockchain but comes at the expense of security. For this reason, this approach is only suitable when acting in a trusted environment with the possibility of human mistakes. This is achieved as follows:

[0061] 1. To each node N of the Merkle tree, labelled by the hash hN, the point PN= hNG is associated, where G is an elliptic curve point, for example the elliptic curve point used in the Bitcoin blockchain.

[0062] 2. Let L be a level of the Merkle tree. The point PL 'scomputed, where the sum is done across all the nodes of the tree at level L.

[0063] 3. The values PLare published on the blockchain. It should be noted that each node N at level L of the tree can be identified by two values, PNand QN= PL- PN. These points allow for a fast verification of the transactions (assuming that all sources are trusted and trustworthy). Users receive the point QNand enough information to compute the value hN. Once they have done that, they can compute PN, and trust the information if PN+ QN= PL. Since it is easy for third parties to manipulate these data, this process is not suitable for non-trusted environments. It should be pointed out that providing more shards does not significantly increase the security compared to sharing the minimum amount of information (i.e. , a single elliptic curve point).

[0064] Referring again to the Merkle tree shown in Figure 1 , the transaction with transaction ID t is in a block with 7 levels and Merkle root R and has Merkle proof h , ..., h6. The Merkle tree is associated with elliptic curve points Po, ..., P6, where Ptis associated with level i.

[0065] The MPS divides the Merkle proof into 3 shards S^S , and S , and the MPS publishes on- chain the values Po, ...,P6(it should be noted that for this example P2would be enough). Alice queries the output she is interested in. She receives the shards S , and S3 and an elliptic curve point Q. She uses the shards to compute the value tp, and uses this value to generate tpG. She checks that Q + tpG = P2. The MPS could decide to share only one shard instead of two (more precisely, S ). Alice would then need knowledge of the point P4instead of P2.

[0066] This section compares the storage and communication requirements of 3 different solutions. The first solution assumes that no information is stored on-chain. The second solution assumes that at least one level of the Merkle tree (different from the root) is stored in a transaction on a blockchain. The third solution assumes that one or more elliptic curve points are stored on the blockchain. It is assumed that a block with n leaves is referred to, and that the queries are answered only with the information needed to verify the Merkle proof, and that the elliptic curve used is sepk256k1.

[0067] • No additional information stored on the blockchain. The amount of data stored on- chain is 0, each query is answered sharing 32 |Tog2n] bytes of data.

[0068] • Labels of the level i are published on-chain. An upper bound for the data stored on- chain is 32 • 2‘ bytes, while a lower bound is 16 • 2‘ bytes. This requires communication of 32(log2n - i) bytes of data for each query. • Elliptic curve points are published on-chain. Each elliptic curve point requires 33 bytes of data. The minimum amount of information required on-chain is 33 bytes (one elliptic curve point, representing either a level or the entire tree). More generally, the MPS uses 33 / i bytes of data on-chain (corresponding to h elliptic curve points). The amount of data communicated to users is 33 bytes (an elliptic curve point) plus 32 Zc bytes, where k can be as low as 0.

[0069] Let Alice be a user of the MPS, her interaction with the MPS can be summarized as follows.

[0070] 1. Alice queries the MPS for a specific input or output. Based on the attributes of the database TDB, she may be able to query them based on multiple different fields (e.g., the locking script).

[0071] 2. The MPS returns to Alice information on the transaction containing the queried value. This may include one or more shards of the Merkle proof.

[0072] 3. If shards are provided, Alice uses them to compute the Merkle proof.

[0073] 4. If only part of the Merkle proof was provided, Alice can rely on the on-chain service providing supporting information to finish the verification.

[0074] The arrangement described above provides the advantages of an improved storage solution for MPSs, in which non-relevant inputs and outputs can be identified and removed, and MPSs can communicate less information to users and rely on on-chain information to complete the Merkle proof.

[0075] Examples

[0076] 1) A service creates transactions that contains weather information on a large geographical area (e.g., each output contains weather data for a smaller sub-region). A MPS filters local weather information and remove the outputs that are irrelevant to its covered locations.

[0077] 2) A service creates transactions containing information on the outcome of multiple sport events (e.g., each output contains different information on different events). A MPS is linked to a blockchain betting service. The MPS filter out the outpoints that are of no interest to the type of bets the betting service offers. An example system and associated blockchain infrastructure which can be used to implement a method in accordance with an embodiment is now described, with reference to Figures 2a, 2b and 2c.

[0078] A system is described, with reference to Figure 2a, which enables a transfer of an amount of cryptocurrency between a first user and second user of the system to be recorded.

[0079] The system comprises first computing device 102 and second computing device 104. First computing device 102 and second computing device 104 may be any computing resource. Each of first computing device 102 and second computing device 104 are configured to interact with payment processing resource 106 via respective first and second application programming interface (API) 108.

[0080] The payment processing resource 106 is further configured to interact with the blockchain 112. The blockchain 112 may comprise at least one public proof-of-work blockchain in accordance with the Bitcoin Satoshi Vision (BSV) protocol in that it is an append-only ledger of blocks (BSV1 , BSV2, BSV3) which are made up of transactions.

[0081] The blockchain 112 comprises a plurality of nodes 126 configured by the software which is now described in relation to Figure 2b. Each node is configured in accordance with this software as part of the blockchain as described below in relation to Figure 2c.

[0082] Figure 2b illustrates an example of the node software 450 that is run on each blockchain node 126 of the network 132, in the example of a UTXO- or output-based model. It should be noted that another entity may run node software 450 without being classed as a node 126 on the network 132, i.e. without performing the actions required of a node 126. The node software 450 may contain, but is not limited to, a protocol engine 451 , a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 126 may run node software that contains, but is not limited to, all three of: a consensus module 455C (for example, proof-of-work), a propagation module 455P and a storage module 455S (for example, a database). The protocol engine 401 is typically configured to recognize the different fields of a transaction 152 and process them in accordance with the node protocol. When a transaction 152j (Tx ) is received having an input pointing to an output (e.g. IITXO) of another, preceding transaction 152i (Tx^^, then the protocol engine 451 identifies the unlocking script in Txj and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Txt based on the pointer in the input of Txj. Txi may be published on the blockchain 150, in which case the protocol engine may retrieve Txtfrom a copy of a block 151 of the blockchain 150 stored at the node 126. Alternatively, TxLmay yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Txtfrom the ordered set 154 of unpublished transactions maintained by the node 126. Either way, the script engine 451 identifies the locking script in the referenced output of Txtand passes this to the script engine 452.

[0083] The script engine 452 thus has the locking script of TxLand the unlocking script from the corresponding input of Txj. For example, transactions labelled Tx0and Tx1are illustrated in Figures 2b, 2c, but the same could apply for any pair of transactions. The script engine 452 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 453 in accordance with the stack-based scripting language being used (e.g. Script).

[0084] By running the scripts together, the script engine 452 determines whether or not the unlocking script meets the one or more criteria defined in the locking script - i.e. does it “unlock” the output in which the locking script is included? The script engine 452 returns a result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result “true”. Otherwise it returns the result “false”.

[0085] In an output-based model, the result “true” from the script engine 452 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 451 that must be met as well; such as that the total amount of digital asset specified in the output(s) of Txj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Txthas not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction Txj. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on condition that Txj is indeed validated, the decision engine 454 may select to control both of the consensus module 455C and the propagation module 455P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 455C adding Txj to the node’s respective ordered set of transactions 154 for incorporating in a block 151 , and the propagation module 455P forwarding Txj to another blockchain node 126 in the network 130. Optionally, in embodiments the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. E.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee.

[0086] It should also be noted that the terms “true” and “false” herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, “true” can refer to any state indicative of a successful or affirmative outcome, and “false” can refer to any state indicative of an unsuccessful or non-affirmative outcome. For instance in an account-based model, a result of “true” could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true).

[0087] Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims.

[0088] For instance, some embodiments above have been described in terms of a bitcoin network 130, bitcoin blockchain 150 and bitcoin nodes 126. However, it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 126 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 126 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 126 as described above.

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

[0090] In non-preferred embodiments of the invention, the blockchain network 132 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a “node” may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes. Even more generally, any reference to the term “bitcoin node” 126 above may be replaced with the term “network entity” or “network element”, wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 126.

[0091] Even more generally, any reference to the term “bitcoin node” 126 above may be replaced with the term “network entity” or “network element”, wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 126.

[0092] Figure 2c shows an example system for implementing a blockchain 150. The system may comprise a packet-switched network 130, typically a wide-area internetwork such as the Internet. The packet-switched network 130 comprises a plurality of blockchain nodes 126 that may be arranged to form a peer-to-peer (P2P) network 132 within the packet-switched network 130. Whilst not illustrated, the blockchain nodes 126 may be arranged as a near-complete graph. Each blockchain node 126 is therefore highly connected to other blockchain nodes 126.

[0093] Each blockchain node 126 comprises computer equipment of a peer, with different ones of the nodes 126 belonging to different peers. Each blockchain node 126 comprises processing apparatus 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 equipment 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 or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive.

[0094] The blockchain 150 comprises a chain of blocks of data 151 , wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 126 in the distributed or blockchain network 130. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout. In one common 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 a quantity of a digital asset as property, an example of which is a user 103 (specifically Alice or Bob in the described example, corresponding to client devices 103a and 103b respectively) to whom the output is cryptographically locked (requiring a signature or other solution of that user in order to be unlocked and thereby redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

[0095] Each block 151 also comprises a block pointer 155 pointing back to the previously created block 151 in the chain so as to define a sequential order to the blocks 151. Each transaction 152 (other than a coinbase transaction) comprises a pointer back to a previous transaction so as to define an order to sequences of transactions (N.B. sequences of transactions 152 are allowed to branch). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153 which was the first block in the chain. One or more original transactions 152 early on in the chain 150 pointed to the genesis block 153 rather than a preceding transaction.

[0096] Each of the blockchain nodes 126 is configured to forward transactions 152 to other blockchain nodes 126, and thereby cause transactions 152 to be propagated throughout the network 132. Each blockchain node 126 is configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. Each blockchain node 126 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered set 154 is often referred to as a “mempool”. This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 126 has accepted as valid and for which the node 126 is obliged not to accept any other transactions attempting to spend the same output.

[0097] In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or “spent” in the present transaction 152j. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 132, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence “preceding” herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

[0098] The input of the present transaction 152j also comprises the input authorisation, for example the signature of the user 103a to whom the output of the preceding transaction 152i is locked. In turn, the output of the present transaction 152j can be cryptographically locked to a new user or entity 103b. The present transaction 152j can thus transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the present transaction 152j. In some cases a transaction 152 may have multiple outputs to split the input amount between multiple users or entities (one of whom could be the original user or entity 103a in order to give change). In some cases a transaction can also have multiple inputs to gather together the amounts from multiple outputs of one or more preceding transactions, and redistribute to one or more outputs of the current transaction.

[0099] According to an output-based transaction protocol such as, for example, bitcoin, when an entity, such as a user or machine, 103 wishes to enact a new transaction 152j, then the entity sends the new transaction from its computer terminal to a recipient. Bitcoin is mentioned only as an example and may be interchanged with any specific blockchain or blockchain application which implements an output-based transaction protocol. The entity or the recipient will eventually send this transaction to one or more of the blockchain nodes 126 of the network 132 (which nowadays are typically servers or data centres, but could in principle be other user terminals). It is also not excluded that the entity 103 enacting the new transaction 152j could send the transaction to one or more of the blockchain nodes 126 and, in some examples, not to the recipient. A blockchain node 126 that receives a transaction checks whether the transaction is valid according to a blockchain node protocol which is applied at each of the blockchain nodes 126. The blockchain node protocol typically requires the blockchain node 126 to check that a cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in an ordered sequence of transactions 152. In such an output-based transaction protocol, this may comprise checking that the cryptographic signature or other authorisation of the entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i which the new transaction assigns, wherein this condition typically comprises at least checking that the cryptographic signature or other authorisation in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked to. The condition may be at least partially defined by a script included in the output of the preceding transaction 152i. Alternatively it could simply be fixed by the blockchain node protocol alone, or it could be due to a combination of these. Either way, if the new transaction 152j is valid, the blockchain node 126 forwards it to one or more other blockchain nodes 126 in the blockchain network 132. These other blockchain nodes 126 apply the same test according to the same blockchain node protocol, and so forward the new transaction 152j on to one or more further nodes 126, and so forth. In this way the new transaction is propagated throughout the network of blockchain nodes 126.

[0100] In an output-based model, the definition of whether a given output (e.g. IITXO) is assigned is whether it has yet been validly redeemed by the input of another, onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i which it attempts to assign or redeem has not already been assigned / redeemed by another transaction. Again if not valid, the transaction 152j will not be propagated (unless flagged as invalid and propagated for alerting) or recorded in the blockchain 150. This guards against double-spending whereby the transactor tries to assign the output of the same transaction more than once. An account-based model on the other hand guards against double-spending by maintaining an account balance. Because again there is a defined order of transactions, the account balance has a single defined state at any one time.

[0101] In addition to validating transactions, blockchain nodes 126 also race to be the first to create blocks of transactions in a process commonly referred to as mining, which is supported by “proof- of- work”. At a blockchain node 126, new transactions are added to an ordered set 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a “nonce” value such that when the nonce is concatenated with a representation of the ordered set of transactions 154 and hashed, then the output of the hash meets a predetermined condition. E.g. the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output with respect to its input. Therefore this search can only be performed by brute force, thus consuming a substantive amount of processing resource at each blockchain node 126 that is trying to solve the puzzle.

[0102] The first blockchain node 126 to solve the puzzle announces this to the network 132, providing the solution as proof which can then be easily checked by the other blockchain nodes 126 in the network (once given the solution to a hash it is straightforward to check that it causes the output of the hash to meet the condition). The first blockchain node 126 propagates a block to a threshold consensus of other nodes that accept the block and thus enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 126. A block pointer 155 is also assigned to the new block 151 n pointing back to the previously created block 151 n-1 in the chain. A significant amount of effort, for example in the form of hash, required to create a proof-of-work solution signals the intent of the first node 126 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as double-spending. Once created, the block 151 cannot be modified since it is recognized and maintained at each of the blockchain nodes 126 in the blockchain network 132. The block pointer 155 also imposes a sequential order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each blockchain node 126 in a network 132, this therefore provides an immutable public ledger of the transactions.

[0103] Note that different blockchain nodes 126 racing to solve the puzzle at any given time may be doing so based on different snapshots of the ordered set of yet to be published transactions 154 at any given time, depending on when they started searching for a solution or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 are included in the next new block 151 n and in which order, and the current set 154 of unpublished transactions is updated. The blockchain nodes 126 then continue to race to create a block from the newly defined outstanding ordered set of unpublished transactions 154, and so forth. A protocol also exists for resolving any “fork” that may arise, which is where two blockchain nodes126 solve their puzzle within a very short time of one another such that a conflicting view of the blockchain gets propagated between nodes 126. In short, whichever prong of the fork grows the longest becomes the definitive blockchain 150. Note this should not affect the users or agents of the network as the same transactions will appear in both forks.

[0104] According to the bitcoin blockchain (and most other blockchains) a node that successfully constructs a new block 126 is granted the ability to assign an accepted amount of the digital asset in a new special kind of transaction which distributes a defined quantity of the digital asset (as opposed to an inter-agent, or inter-user transaction which transfers an amount of the digital asset from one agent or user to another). This special type of transaction is usually referred to as a “coinbase transaction”, but may also be termed an “initiation transaction”. It typically forms the first transaction of the new block 151 n. The proof-of-work signals the intent of the node that constructs the new block to follow the protocol rules allowing this special transaction to be redeemed later. The blockchain protocol rules may require a maturity period, for example 100 blocks, before this special transaction may be redeemed. Often a regular (non-generation) transaction 152 will also specify an additional transaction fee in one of its outputs, to further reward the blockchain node 126 that created the block 151 n in which that transaction was published. This fee is normally referred to as the “transaction fee”, and is discussed below.

[0105] Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 126 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 126 could take the form of a user terminal or a group of user terminals networked together.

[0106] The memory of each blockchain node 126 stores software configured to run on the processing apparatus of the blockchain node 126 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 126 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.

[0107] Also connected to the network 130 is the computer equipment of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network but do not participate in validating, constructing or propagating transactions and blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 126).

[0108] Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 132. Users of the blockchain network (often referred to as “clients”) may be said to be part of a system that includes the blockchain network; however, these users are not blockchain nodes 126 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 132 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 132. Two parties 103 and their respective equipment are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. First computing device 102 and second computing device 104 may be configured to implement any of the functionality of respective computer equipment 102a or 102b. It will be understood that many more such parties 103 and their respective computer equipment may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with “first party” and “second “party” respectively.

[0109] The computer equipment of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non- transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment. The computer equipment 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 computer equipment of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

[0110] The client application 105 may be initially provided to the computer equipment of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable optical drive, etc. Client application 105 corresponds respectively to 105a and 105b on the devices 102a and 102b illustrated in Figure 2c

[0111] The client application 105 comprises at least a “wallet” function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 126 to then be propagated throughout the network of blockchain nodes 126 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0112] It should be noted that whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

[0113] The instance of the client application or software 105 on each computer equipment is operatively coupled to at least one of the blockchain nodes 126 of the network 132. This enables the wallet function of the client 105 to send transactions 152 to the network 132. The client 105 is also able to contact blockchain nodes 126 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties’ transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 126 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 132. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 126 in the network 132.

[0114] When a given party 103, say Alice, wishes to send a new transaction 152j to be included in the blockchain 150, then she formulates the new transaction in accordance with the relevant transaction protocol (using the wallet function in her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 126 to which she is connected. E.g. this could be the blockchain node 126 that is best connected to Alice’s computer. When any given blockchain node 126 receives a new transaction 152j, it handles it in accordance with the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j meets a certain condition for being “valid”, examples of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable on a per-transaction basis by scripts included in the transactions 152. Alternatively the condition could simply be a built-in feature of the node protocol, or be defined by a combination of the script and the node protocol.

[0115] On condition that the newly received transaction 152j passes the test for being deemed valid (i.e. on condition that it is “validated”), any blockchain node 126 that receives the transaction 152j will add the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 126. Further, any blockchain node 126 that receives the transaction 152j will propagate the validated transaction 152 onward to one or more other blockchain nodes 126 in the network 132. Since each blockchain node 126 applies the same protocol, then assuming the transaction 152j is valid, this means it will soon be propagated throughout the whole network 132.

[0116] Once admitted to the ordered set of transactions 154 maintained at a given blockchain node 126, that blockchain node 126 will start competing to solve the proof-of-work puzzle on the latest version of their respective ordered set of transactions 154 including the new transaction 152 (recall that other blockchain nodes 126 may be trying to solve the puzzle based on a different ordered set of transactions! 54, but whoever gets there first will define the ordered set of transactions that are included in the latest block 151. Eventually a blockchain node 126 will solve the puzzle for a part of the ordered set 154 which includes Alice’s transaction 152j). Once the proof-of-work has been done for the ordered set 154 including the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 comprises a pointer back to an earlier transaction, so the order of the transactions is also immutably recorded.

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

[0118] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an “account-based” protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the IITXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the “position”). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field. Transactions recorded in the blockchain 112 model a transfer of value which is either spent or unspent and protected by a locking script. A transaction spends value through its inputs and pays value forward via its outputs. The value input to a transaction must equal or exceed the value output by a previous transaction, with any surplus input collected as a transaction fee. A transaction is invalid if: the solutions presented to locking scripts, i.e. unlocking scripts, are incorrect; if it outputs more value than is taken as input; if it spends output that has already been spent or it attempts to spend value which does not exist at all.

[0119] Both locking scripts and unlocking scripts are expressed in machine-readable scripting language allowing for a large variety of scripted spending conditions, including scripts which can embed arbitrary data (in the form of a provably unspendable output) as a data carrier output.

[0120] The payment processing resource 106 in Figure 2a is configured to interact with the blockchain 112. The payment processing resource is configured to retrieve blockchain transactions and to provide unlocking scripts to spend previously unspent outputs (UTXOs) from blockchain transactions. The unspent transactions may be stored in a distributed hash table (DHT). The payment processing resource 106 is configured to generate blockchain transactions using previously unspent outputs and may be configured to provide its own funds as input to those transactions. The payment processing resource 106 is configured to check that the outputs being spent by the transaction are not already spent outputs, i.e. that they are unspent outputs and are not double spends, by checking the DHT or a temporary / secondary mempool for the presence of the outputs. The payment processing resource 106 is then further configured to send the blockchain transactions to the blockchain 112 and to receive a notification from the blockchain 112 when the transaction has been received. The payment processing resource 106 may be configured to add provably unspendable outputs to the blockchain transactions it generates and use them to append data carriers comprising a hash of data provided by the payment processing resource 106.

[0121] The payment processing resource 106 may be configured to store information relating to accounts used by users of the payment processing resource 106. The payment processing resource 106 may utilise a database management system (DBMS) 140 to create, delete and manage information relating to these accounts. The DBMS 140 may be located locally or remotely relative to the payment processing resource 106 and the payment processing resource 106 may access the DBMS 140 using any suitable telecommunications media. The payment processing resource 106 in Figure 2a may be configured to interact with a key storage module 122 and a payment data store 124. The key storage module 122 is configured to store cryptographic keys corresponding to the accounts of parties who use the payment processing resource 106 to enable transactions to take place. The key storage module 122 may utilise any suitable storage and will utilise a database management system (DBMS) to initialise, store and retrieve data from records inside a database of the parties who store cryptographic keys in the key storage module 122. The payment data store 124 is configured to store data related to any payments which are implemented using the payment processing resource 106.

[0122] Figure 2c additionally shows a peer device 103a belonging to Alice and another end device 103b used by or belonging to Bob. Peer device 103a may represent first computing device 102 and peer device 103b may represent second computing device 104. Peer devices may also be described as client devices. Alice and Bob are simply representative of persons or entities interacting and wishing to store their transactions including financial transactions into a blockchain 112. Bob may be a merchant and Alice may be a client of Bob making a transaction payment 152 (for example) to Bob and vice versa.

[0123] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. Although the disclosure has been described with reference to specific example implementations, it will be recognized that the disclosure is not limited to the implementations described but can be practiced with modification and alteration within the scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

CLAIMS1. A computer implemented method of enabling verification of presence of a data item on a blockchain, the method comprising: generating first data comprising a Merkle proof of second data representing at least one part of a blockchain transaction; storing said first data; and publishing third data on a blockchain, wherein said third data comprises at least one data item used in generating said Merkle proof.

2. A method according to claim 1 , further comprising dividing said first data into a plurality of portions.

3. A method according to claim, 2 wherein the portions are non-overlapping portions of said Merkle proof.

4. A method according to claim 2 or 3, further comprising using said third data to index said portions for storage.

5. A method according to any one of the preceding claims, wherein the second data represents at least one input and / or at least one output of the blockchain transaction.

6. A method according to any one of the preceding claims, wherein the second data comprises data representing at least one of: identification of said blockchain transaction, a position of an input and / or output in said blockchain transaction, an indication of whether said input and / or said output is an input or an output of said blockchain transaction, a position of said blockchain transaction in a block, a locking script of an input and / or output of said blockchain transaction, an unlocking script of an input of said blockchain transaction and / or an amount of a digital asset.

7. A method according to any one of the preceding claims, wherein the third data represents at least one function used to determine said Merkle proof.

8. A method according to any one of the preceding claims, wherein the third data comprises fourth data representing at least one Merkle tree node defined by a predetermined level of a Merkle tree corresponding to said Merkle proof.

9. A method according to claim 8, wherein a function having a homomorphic property is applied to said fourth data.

10. A method according to claim 8 or 9, wherein elliptic curve point multiplication is applied to the fourth data.

11. A method according to claim 10, wherein the fourth data comprises a sum of elliptic curve point data, wherein each said elliptic curve point represents a respective Merkle tree node at said predetermined level of said Merkle tree.

12. A method according to any one of the preceding claims, further comprising communicating at least part of said first data to a user in response to a query by said user relating to said second data.

13. A device comprising a processor and memory, the memory including executable instructions that, as a result of execution by the processor, cause the device to perform the computer-implemented method according to any one of the preceding claims.

14. A non-transitory computer readable storage medium comprising computer program code instructions, being executable by a computer, to carry out a method as defined in any one of claim 1 to 12.

15. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method as defined in any one of claims 1 to

Images