Method and system for appending a rendezvous blockchain transaction to a user chain of commitments

Abstract

A method is provided in which asset payments are recorded using blockchain transactions and verified based on an immutable log associated with the transaction.

Description

[Technical field]

[0001] The present disclosure generally relates to methods and systems for implementing a platform for one or more distributed ledger, i.e., blockchain related services for one or more clients. In particular, the present disclosure relates to providing access to blockchain related functions and applications for one or more clients, such as, but not limited to, enabling the transfer of digital or tokenized assets. [Background technology]

[0002] In this specification, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, public and private blockchains, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Although Bitcoin may be referenced herein for convenience and illustrative purposes, it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols related to any type of digital asset or representation of a digital asset are within the scope of this disclosure. The terms "client," "entity," "node," "user," "sender," "recipient," "payer," and "payee" may refer to computing or processor-based resources in this specification. The term "Bitcoin" is used herein to include any version or variation derived from or based on the Bitcoin protocol. The term "digital asset" may refer to any transferable asset, such as cryptocurrency, a token representing at least a portion of property, a smart contract, a license, i.e., a software license, or a DRM contract for media content. It will be understood that the term "digital asset" is used throughout this specification to refer to a commodity that may be associated with value that may be transferred or provided from one entity to another as payment in a transaction.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block that are chained together to create a permanent, immutable record of all transactions written to the blockchain since the blockchain's inception. Transactions contain small programs, known as scripts, embedded in the transaction's inputs and outputs that specify how and by whom the transaction's outputs can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid; invalid transactions are rejected from the network. A software client installed on the node performs this validation work by running its lock and unlock scripts on unspent transactions (UTXOs). If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction--if the transaction is valid, the node relays the transaction to the rest of the network--, ii) added to a new block constructed by a miner, and iii) mined, i.e., added to the public ledger of past transactions.

[0005] It will be appreciated that the nature of the work performed by miners depends on the type of consensus mechanism used to maintain the blockchain. Proof of Work (PoW) is associated with the original Bitcoin protocol, but it will be appreciated that other consensus mechanisms such as Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Capacity (PoC), Proof of Elapsed Time (PoET), Proof of Authority (PoA), etc. may be used. Different consensus mechanisms differ in how mining is distributed among the nodes, and the likelihood of successfully mining a block depends, for example, on the hashing power of the miner (PoW), the amount of cryptocurrency held by the miner (PoS), the amount of cryptocurrency entrusted to delegate miners (DPoS), the ability of the miner to remember a given solution to a cryptographic puzzle (PoC), the waiting time randomly assigned to the miner (PoET), etc. Typically, miners are provided with an incentive or reward for mining a block. For example, the Bitcoin blockchain rewards miners with newly issued cryptocurrency (Bitcoins) and fees associated with transactions in a block (transaction fees). With respect to the Bitcoin blockchain, the amount of cryptocurrency issued decreases over time, and the incentive eventually consists solely of transaction fees. Thus, it will be appreciated that the processing of transaction fees is part of the underlying mechanism for committing data to a public blockchain, such as the Bitcoin blockchain.

[0006] As mentioned above, each transaction in a given block encodes the transfer of control of digital assets between participants of the blockchain system. Digital assets do not necessarily correspond to cryptocurrencies. For example, digital assets may relate to digital representations of documents, images, physical objects, etc. Payment of cryptocurrencies and / or transaction fees to miners may simply act as an incentive to maintain the validity of the blockchain by performing the necessary work. The cryptocurrency associated with the blockchain serves as security for miners, and the blockchain itself may be a ledger of transactions primarily related to non-cryptocurrency digital assets. In some cases, transfers of cryptocurrencies between participants may be handled by entities distinct from and / or unrelated to the entities that use the blockchain to maintain the ledger of transactions.

[0007] Once stored on the blockchain as a UTXO, a user can transfer control of the associated resource to another address associated with another transaction input. This transfer is typically, but not necessarily, done using a digital wallet. The digital wallet may be a device, a physical medium, a program, an application (app) on a computing device such as a desktop, laptop, or mobile terminal, or a remotely hosted service associated with a domain on a network such as the Internet. Digital wallets can be used to store public and private keys, track ownership of resources, tokens, assets, etc. associated with a user, receive or spend digital assets, and transfer tokens, which may be associated with digital assets such as cryptocurrencies, licenses, property, or other types of resources.

[0008] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are exploring the use of both the cryptographic security system on which Bitcoin is based, and the data that can be stored on the blockchain, to implement new systems. Blockchain technology would be highly advantageous if the blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions could take advantage of the benefits of the blockchain (e.g., permanent tamper-proof record of events, distributed processing, etc.) while broadening their applications.

[0009] One area of ​​current research is the use of blockchain for the implementation of "smart contracts", which are computer programs designed to automate the execution of the terms of machine-readable contracts or agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce outcomes and can cause actions to be taken depending on those outcomes.

[0010] In particular, one area of ​​research concerns the transfer of assets and how that transfer can be recorded on the blockchain to ensure that the transfer benefits from the immutability of the blockchain. Additionally, providing efficient and secure protocols for the transfer of assets, as well as means for logging such transfers to ensure that they are securely recorded and logged with the support of the underlying blockchain infrastructure, is of particular interest. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] UK Patent Application No. 2102314.8 [Patent Document 2] UK Patent Application No. 2102217.3 [Patent Document 3] UK Patent Application No. 2204293.1 Summary of the Invention [Means for solving the problem]

[0012] Throughout this specification, the word "comprise" or variations such as "includes," "comprises," or "comprising" are understood to imply the inclusion of a stated element, integer, step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, step, or group of elements, integers, or steps.

[0013] The present disclosure relates to methods and systems that can enable recording of payment events, which may be, for example, payments of currency in exchange for goods.

[0014] In some embodiments, a computer-implemented method is provided for recording an asset transfer event involving at least a first user and a second user. The asset may be understood as a representation of a physical asset using a blockchain token. The asset may be a precious metal represented using a blockchain token. The asset may be a tokenized asset. The tokenized asset may be an amount of currency. The asset may be a product or service. The asset transfer event may be a payment of currency for a product, good, or service. Some embodiments may allow a payment of currency to be recorded. The payment of currency may be of any currency or currency type, may be for goods or services, or may be an exchange with a different currency or currency type. Some embodiments may be implemented by a computing resource. The computing resource may be implemented by hardware or software. The computing resource may include multiple processing resources that may be distributed either locally or over a large geographic area. The method may include receiving instruction data, the instruction data relating to a requested asset transfer event, the instruction data including a first set of metadata relating to a sender of the asset transfer and a second set of metadata relating to at least one recipient of the asset transfer. The metadata may identify, for example, at least one of a currency of the payment, an account, an individual designated to receive or make the transfer, terms and conditions of the payment, and public key or digital signature evidence authorizing the payment. The sender and recipient may each be associated with an account related to an asset registry.

[0015] The method may further include associating senders of assets with a first chain of commitments and receivers of assets with a second chain of commitments, where each chain of commitments associates an event stream with multiple blockchain transactions. The event stream may be "off-chain", i.e., not on the blockchain. The association between multiple blockchain transactions and the event stream may mean that an entry is added to the event stream each time a commitment is added to a chain of commitments. The entry added to the event stream may include a portion of the metadata from the commitment. The metadata may be included in the data payload of the commitment, and at least a portion of the metadata may be stored in the entry of the event stream.

[0016] An event stream may include a blockchain-backed append-only log, where data recorded in a blockchain transaction may be added to a time-ordered log. That is, an event stream may log data recorded on the blockchain in chronological order, i.e., as they appear on the blockchain. This means that the order of transactions in a block on the blockchain is generally reflected by the corresponding index of the corresponding event logged in the event stream. However, this is not necessarily the case. Two concurrent events mean that the order of events is not reflected in the order of transactions in the block. There may be cases where an event on the event stream with an index, say, N+1, is recorded in block B, while an event with index N (i.e., recorded before the other event on the event stream) is recorded in block B+1. An event stream may be implemented using any suitable data structure. An event stream may include a series of entries stored in a sequence, where each entry in the sequence is referenced in the sequence by a monotonically increasing number. That is, the first entry in the event stream is entry 1, the second entry is entry 2, and so on. The use of the underlying blockchain means that all modifications to the event stream are detectable, guaranteeing that individual entries in the event stream have not been modified since they were written, that entries have not been inserted between previously consecutive entries, that entries have not been removed, and that entries have not been reordered.

[0017] Although it may be possible for a malicious actor to add events to the event stream without being detected by the system, the user who initialized the event stream may sign any events that the user adds to the event stream, and therefore the fact that a malicious actor is attempting to add an event is detectable.

[0018] Associating either or both of the first and second chains of commitments with the respective sender or receiver may include initializing the chains of commitments and associating the chains of commitments with the respective sender or receiver. The method may further include associating another entity with the respective chains of commitments. The other entity may be a registry manager associated with the asset registry or a signatory of another entity.

[0019] An asset registry is a registry of assets owned by an individual or organization. Examples of assets include any resource owned or controlled by a respective individual or organization. Examples of assets include cash or anything else of monetary value. An example of an asset registry might be, for example, a bank that records cash deposits against an account that can be used to fund transactions in a particular currency. Another example might be a gold account, which is a register of gold deposits owned by an individual. An asset registry is associated with issuers of assets related to accounts managed by the asset registry. An exemplary issuer could be the Royal Mint.

[0020] The method may further include comparing the first set of metadata and the second set of metadata to determine whether a transfer of the asset can occur from the sender to at least one recipient according to a transfer protocol, the transfer protocol defining at least one criterion that enables the asset transfer event to occur.

[0021] The transfer protocol may define at least one criterion that must be met to allow an asset transfer event to take place. The at least one criterion may require that the sender and receiver are associated with accounts related to the same asset registry. For example, the at least one criterion may require that the accounts are of the same bank. The at least one criterion may require that the accounts are associated with the same type of asset. For example, such a criterion may require that both accounts are denominated in Pound Sterling (GBP).

[0022] Based on a comparison between the respective sets of metadata according to the transfer protocol, the method may further include determining one or more correspondences between the respective sets of metadata.

[0023] A commitment is a blockchain transaction that associates itself with other transactions, which may not necessarily be from the same block on the blockchain.

[0024] As described herein, a chain of commitments includes multiple transactions in that each transaction contains a reference to a previous transaction and a reference to a next transaction (or contains data based on those references).

[0025] The method may further include generating a rendezvous blockchain transaction including at least one input and at least one output for each of the sender and the recipient, the at least one output including output data related to a first set of metadata and a second set of metadata, the data related to the metadata being further based on data related to a future transaction. The at least one input may include one input for each of the sender and the recipient in addition to inputs related to other entities related to the asset transfer event. Each input may correspond to an output in that it has a matching input index and output index in the rendezvous blockchain transaction. This forms an input-output pair.

[0026] The rendezvous blockchain transaction may be added to the first and second chains of commitments, respectively, i.e., the rendezvous blockchain transaction forms a commitment in the chain of commitments.

[0027] The method may further include adding an entry to each event stream associated with the first and second chains of commitments when each rendezvous transaction is generated to form a next commitment in the chain of commitments, the entry including data associated with the first and second sets of metadata.

[0028] The method may further include associating the rendezvous blockchain transaction with a respective entry in the respective off-chain event stream. Associating the rendezvous blockchain transaction with the respective entry may include storing in a storage means a transaction identifier associated with the rendezvous transaction having a respective entry in the respective off-chain event stream.

[0029] The method may further include appending the rendezvous blockchain transaction to the first chain of commitments and the second chain of commitments, respectively.

[0030] The first and second sets of metadata may collectively form a payment instruction dataset for the asset transfer event.

[0031] The above method ties the blockchain to the event stream and allows asset transfer events to be recorded using a chain of commitments that uses future transaction data to generate blockchain transactions forming a chain of transactions where each transaction commits to the next. This provides a secure, less complex, user-friendly, efficient, and robust approach to recording asset transfer events. This allows users, such as senders or receivers, to be able to quickly and easily access and interact with their history of asset transfer events.

[0032] Aspects and embodiments of the present disclosure are hereinafter described, by way of example only, with reference to the accompanying drawings. [Brief description of the drawings]

[0033] [Figure 1a] FIG. 1 illustrates a system according to an embodiment. [Figure 1b]FIG. 1 illustrates a node configured to implement Bitcoin software to enable blockchain transactions. [Figure 1c] FIG. 1 illustrates a blockchain network. [Diagram 2] 4 is a flow diagram detailing an account set-up according to an embodiment. [Figure 3a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 3b] 1 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment; [Figure 3c] FIG. 2 illustrates a rendezvous transaction according to an embodiment. [Figure 3d] FIG. 1 illustrates the relationship between chains of dust transactions and event streams. [Figure 3e] FIG. 2 illustrates multiple event streams corresponding to participants in a transaction. [Figure 4a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 4b] FIG. 2 illustrates a rendezvous transaction according to an embodiment. [Figure 4c] FIG. 2 illustrates multiple event streams corresponding to participants in a transaction. [Figure 5a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 5b] FIG. 2 illustrates a rendezvous transaction according to an embodiment. [Figure 5c] FIG. 2 illustrates multiple event streams corresponding to participants in a transaction. [Figure 6a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 6b] 1 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment; [Figure 7]FIG. 1 illustrates a rendezvous blockchain transaction generated by an embodiment. [Figure 8] FIG. 2 illustrates an event stream for participants in a transaction according to an embodiment. [Figure 8a] FIG. 2 illustrates a chain of commitments. [Figure 9] FIG. 1 illustrates method steps for recording asset transfer events using a chain of commitments. [Figure 10] FIG. 2 illustrates a rendezvous transaction that synchronizes multiple chains of commitments. [Figure 11] FIG. 2 illustrates a Merkle tree representing a state digest. [Figure 12] FIG. 2 illustrates a Merkle tree representing a data digest. [Figure 13] FIG. 13 illustrates an alternative rendezvous transaction for synchronizing multiple chains of commitments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] The following provides a detailed discussion of aspects and embodiments of the present disclosure in order to provide the reader with a most complete understanding of the present disclosure.

[0035] Viewed from a first aspect, a computer-implemented method of recording an asset transfer event involving at least a first user and a second user is provided. The method may enable a monetary payment to be recorded. The monetary payment may be in any currency and may be for goods or services. The method may be performed by a computing resource. The computing resource may be implemented by hardware or software. The computing resource may include a plurality of processing resources that may be distributed either locally or in a large geographic area. The method may include receiving instruction data, the instruction data being related to a requested asset transfer event, the instruction data including a first set of metadata related to a sender of the payment and a second set of metadata related to at least one recipient of the payment. The metadata may identify at least one of a currency of the payment, an account associated with an asset registry, an individual designated to receive or make the payment, terms and conditions of the payment, and public key or digital signature evidence authorizing the payment. Each of the sender and recipient may be associated with an account associated with the asset registry, respectively.

[0036] A sender of an asset may be associated with a first chain of commitments and a receiver of an asset may be associated with a second chain of commitments, with each chain of commitments associating an event stream with multiple blockchain transactions. A chain of commitments may provide a related set of blockchain transactions associated with an event stream. The set of blockchain transactions are linked by information that may be included in the output data payload.

[0037] The method may include comparing the first set of metadata with the second set of metadata to determine whether a transfer of the asset can occur from the sender to at least one recipient according to a transfer protocol, the transfer protocol defining at least one criterion that enables the asset transfer event to occur.

[0038] The method may include determining one or more correspondences between the respective sets of metadata based on a comparison between the respective sets of metadata according to the transfer protocol.

[0039] The method may further include adding entries to respective event streams associated with the first and second chains of commitments, the entries including data associated with the first and second sets of metadata.

[0040] The method may further include generating a rendezvous blockchain transaction including at least one input and at least one output, the at least one output including output data related to the first and second sets of metadata, the data related to the metadata being further based on data related to future transactions and which may also be based on prior transactions. The at least one input and output may be a corresponding plurality of inputs and outputs.

[0041] The method may further include associating the rendezvous blockchain transaction with a respective entry of the respective event stream. Associating the rendezvous blockchain transaction with a respective entry may include storing a reference to the rendezvous blockchain transaction in the corresponding event stream entry.

[0042] A rendezvous blockchain transaction may be sent to a blockchain. The rendezvous transaction may be sent along with a set of other blockchain transactions.

[0043] A rendezvous blockchain transaction may include an input and output pair corresponding to each of the senders and receivers. An input and output pair may be understood to mean a corresponding input and output in terms of their indexes. That is, for example, if an input has index 0, then the output of the input and output pair also has index 0. There may also be input and output pairs corresponding to other entities, such as, for example, asset registries.

[0044] The at least one output may include a data payload including output metadata generated based on the first and second sets of metadata and the future transaction. The output metadata may include a data digest and a state digest. The at least one output may be unusable. The first and second sets of metadata may be hashed or double hashed prior to inclusion in the data payload. The future transaction data may be an identifier for the future transaction. That is, the data payload may include information committing to the future transaction that may link the current transaction to the future transaction and further link previous transactions to the future transaction.

[0045] The data digest may be generated based on a hash of the first and second sets of metadata. A further hash may be applied to the hash of the first and second sets of metadata, which provides resistance to stretching attacks.

[0046] The data digest may be generated based on a combination of the first set of metadata and the second set of metadata and a salt, i.e., a salting operation may be used on a hash of the first and second sets of metadata. The first and second sets of metadata may be combined to form a single set of data, such as a payment instruction dataset.

[0047] Salting a hash means using a "salt", which is an arbitrary piece of data, as part of the input to the hash function (along with the data being hashed). The salt may be concatenated with the other inputs to the hash function. Optionally, the salt is random. A different salt may be chosen for each data item being hashed.

[0048] Combining the first and second sets of metadata may include taking a double hash of the combination of the first and second sets of metadata and concatenating the double hash of the combination of the first and second sets of metadata with a double hash of the salt.

[0049] The state digest may be generated based on the data digest and future transactions, and may also be generated based on previous transactions.

[0050] The state digest may be the root of a Merkle tree.

[0051] The step of determining one or more correspondences between the respective sets of metadata includes: i) the currency of payment identified in each set of metadata; ii) the amount of currency being paid from the account corresponding to the sender and the amount of currency being requested from the account corresponding to the recipient, and iii) Identifiers of asset registries associated with the sender and recipient accounts The method may include determining a correspondence between at least one of:

[0052] The computing resource determines that the transfer cannot occur in accordance with the transfer protocol and generates a further set of metadata to resolve the inconsistency with the transfer protocol, which may include generating metadata that enables conversion between the first currency and the second currency.

[0053] Generating a further set of metadata may include generating metadata for one asset registry to record the transfer of a given asset to another asset registry.

[0054] Particular embodiments are hereinafter described, by way of example only, with reference to the accompanying drawings, in which like reference numerals refer to like features and in which:

[0055] System Overview Hereinafter, with reference to FIG. 1a, a system 100 is described that allows a transfer of assets between a first user and a second user of the system 100 to be recorded.

[0056] The system 100 includes a first computing device 102 and a second computing device 104. The first computing device 102 and the second computing device 104 may be any computing resource. Each of the first computing device 102 and the second computing device 104 is configured to interact with a payment processing resource 106 via respective first and second application programming interfaces (APIs) 108.

[0057] The payment processing resource 106 is configured to initialize and / or interact with event streams provided for at least each of a first user named Alice (110a), a second user named Bob (110b), and the payment processing resource (110c) using the event stream resource 110. The initialization of and interaction with the event streams by the payment processing resource 106 will be understood from UK Patent Application No. 2102314.8, filed on 18 February 2021 in the name of nChain Holdings Limited.

[0058] The payment processing resource 106 is further configured to interact with a blockchain 112. The blockchain 112 may include at least one public proof-of-work blockchain that follows the Bitcoin Satoshi Vision (BSV) protocol in that it is an append-only ledger of blocks (BSV1, BSV2, BSV3) composed of transactions.

[0059] The blockchain 112 includes a number of nodes 126 configured by software as described below in connection with Figure 1b, with each node configured by this software as part of the blockchain as described below in connection with Figure 1c.

[0060] FIG. 1b illustrates an example of node software 450 that runs on each blockchain node 126 of the network 132 in an example UTXO or output-based model. Note that another entity may run the node software 450 without being classified as a node 126 on the network 132, i.e., without performing the required actions of a node 126. The node software 450 may include, 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 function modules 455. Each node 126 may run node software that includes, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process those fields according to a node protocol. Another prior transaction 152i (Tx m-1 ) j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlock script for Tx j Based on the input pointer of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine may generate Tx i Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 126. iIn any case, the protocol engine 451 may extract Tx i The script engine 452 then locates the lock script for the referenced output of the

[0061] Therefore, the script engine 452 executes the Tx i Lock script and Tx j and an unlock script from the corresponding inputs of . For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same could apply to any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes pushing data onto and popping data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0062] By executing the scripts together, the script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script--i.e., whether the unlock script "unlocks" the output in which the lock script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, the script engine 452 returns "false."

[0063] In an output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. j the total amount of Digital Assets specified in the entry will not exceed the total amount indicated by that entry, and Tx iThere are also one or more further protocol-level conditions evaluated by protocol engine 451 that must also be satisfied, such as that the pointed-to output of has not already been consumed by another valid transaction. Protocol engine 451 evaluates the result from script engine 452 together with one or more protocol-level conditions, and accepts transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j Only if Tx is indeed enabled, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j , which may be used by the consensus module 455C to select nodes to perform their respective blockchain-related functions with respect to Tx j The propagation module 455P is added to the Tx j to another blockchain node 126 of the network 106. Optionally, in embodiments, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish the transaction only on the condition that the transaction is valid and has sufficient transaction fees remaining.

[0064] It should be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only one binary digit (bit), but it is certainly one possible implementation. More broadly, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level activation of a signature and an additional positive output of a smart contract (where the overall outcome is considered to signal true if both individual outcomes are true).

[0065] Other variations or uses of the disclosed technology will be apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0066] For example, some embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 126. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may apply broadly to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More broadly, all references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 126 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 126, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 126 described above.

[0067] In a preferred embodiment of the present invention, the blockchain network 132 is the Bitcoin network, where the 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 perform only one or some, but not all, of these functions. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 132).

[0068] 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 example, on these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but is not configured to store and / or propagate those blocks 151 to other nodes.

[0069] Even more broadly, any reference above to the term “Bitcoin node” 126 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, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above in connection with blockchain node 126.

[0070] Even more broadly, any reference above to the term “Bitcoin node” 126 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, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above in connection with blockchain node 126.

[0071] 1c illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 130, typically a wide-area internetwork such as the Internet. The packet-switched network 130 includes a number of blockchain nodes 126 that may be arranged to form a peer-to-peer (P2P) network 132 within the packet-switched network 130. Although not illustrated, the blockchain nodes 126 may be arranged as a near-complete graph. Thus, each blockchain node 126 is tightly connected to the other blockchain nodes 126.

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

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

[0074] Each block 151 also contains a block pointer 155 that points back to previously created blocks 151 in the chain, defining a chronological order up to block 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to a previous transaction, defining an order in the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 traces back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0075] Each of the blockchain nodes 126 is configured to forward the transactions 152 to other blockchain nodes 126, thereby propagating the transactions 152 throughout the network 132. Each blockchain node 126 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 126 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 154 is often referred to as a "mempool." This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. This term refers to an ordered set of transactions that the node 126 accepts as valid and that the node 126 is obligated to not accept any other transactions that attempt to consume the same output.

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

[0077] The input of the current transaction 152j also includes the authorization of the input, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to split the input amount among multiple users or entities (one of which may be the original user or entity 103a to give change). In some cases, a transaction may also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0078] According to an output-based transaction protocol such as Bitcoin, when an entity 103, such as a user or a machine, wants to define a new transaction 152j, the entity sends the new transaction from its computer terminal to a recipient. The entity or recipient ultimately sends this transaction to one or more of the blockchain nodes 126 of the network 132 (currently generally servers or data centers, but in principle could be other user terminals). It is also not excluded that the entity 103 defining the new transaction 152j may send the transaction to one or more of the blockchain nodes 126 and in some cases not to a recipient. The blockchain nodes 126 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 126. The blockchain node protocol generally requires the blockchain nodes 126 to check that the cryptographic signature of the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that a cryptographic signature or other authorization of the entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction allocates, which generally includes at least checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, the condition may be solely dictated by the blockchain node protocol, or may result from a combination of these.In any case, 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 tests according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more further nodes 126, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 126.

[0079] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated is whether that output has already been validly fulfilled by the input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to allocate or fulfill has not already been allocated / fulfilled by another transaction. Again, if not valid, the transaction 152j is not propagated (unless it is flagged as invalid for a warning and propagated) and is not recorded in the blockchain 150. This prevents double spending, where a transactor attempts to allocate the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance always has a single defined state.

[0080] In addition to validating transactions, blockchain nodes 126 also compete to be the first node to create a block of transactions in a process supported by "proof of work", usually called mining. At the blockchain nodes 126, the new transaction is added to an ordered set 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered set 154 of transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined 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 others are not excluded. A property of a hash function is that it has an unpredictable output for its input. Therefore, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each blockchain node 126 attempting to solve the puzzle.

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

[0082] Note that different blockchain nodes 126 competing to solve the puzzle at any given time may be doing so based on different snapshots of the ordered set 154 of transactions not yet published at any given time, depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current set 154 of unpublished transactions is updated. Then, the blockchain nodes 126 continue to compete to create blocks from the newly defined outstanding ordered set 154 of unpublished transactions, and so on. There is also a protocol to resolve any "forks" that may occur, where a fork is the point at which two blockchain nodes 126 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 126. In short, the claw of whichever fork is the longest becomes the final blockchain 150. Note that this should have no impact on users or agents of the network, since the same transactions appear in both forks.

[0083] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 126 is granted the ability to allocate a permitted amount of digital assets in a new special type of transaction that distributes a defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction." This special type of transaction generally forms the first transaction of a new block 151n. The proof of work signals the intention of the node constructing the new block to follow the rules of the protocol that allow this special transaction to be subsequently fulfilled. The rules of the blockchain protocol may require a maturity period, e.g., 100 blocks, before this special transaction may be fulfilled. Often, a normal (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 126 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is discussed below.

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

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

[0086] Further connected to the network 130 are computer devices of a number of participants 103 each in the role of consuming users. These users may interact with the blockchain network but do not participate in the validation, construction, or propagation of transactions and blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 126).

[0087] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 132. Although users of the blockchain network (often called "clients") may be said to be part of a system that includes the blockchain network, these users are not blockchain nodes 126 because they do not fulfill the required role of a blockchain node. Instead, each participant 103 may interact with the blockchain network 132, thereby utilizing the blockchain 150, by connecting (i.e., communicating) with the blockchain node 132. For illustrative purposes, two participants 103 and their respective devices are shown: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. The first computing device 102 and the second computing device 104 may be configured to implement any of the functions of the respective computer devices 102a or 102b. It will be understood that many more such parties 103 and their respective computing devices may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely for purposes of illustration, a first party 103a is referred to herein as Alice and a second party 103b is referred to as Bob, but it will be understood that this is not limiting and all references herein to Alice or Bob may be replaced by "first party" and "second party," respectively.

[0088] The computing equipment of each participant 103 includes a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment of each participant 103 further includes a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium or multiple non-transitory computer readable media. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing equipment of each participant 103 stores software including a respective instance of at least one client application 105 arranged to be executed on the processing device. It will be understood that all actions attributed to a given participant 103 herein may be performed with software executed on the processing device of the respective computing equipment. The computing equipment of each participant 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment of a given participant 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0089] The client application 105 is initially provided to the computing equipment of any given participant 103 on a suitable computer readable storage medium or media, and may for example be downloaded from a server or provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive. The client applications 105 correspond to 105a and 105b on devices 102a and 102b shown in Figure 1c, respectively.

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

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

[0092] An instance of a client application or software 105 on each computing device is operatively coupled to at least one of the blockchain nodes 126 of the network 132. This allows the wallet functionality of the client 105 to send transactions 152 to the network 132. The client 105 can also contact the blockchain nodes 126 to query the blockchain 150 regarding any transactions in which the respective party 103 is a recipient (or in embodiments, to certainly inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality of each computing device is configured to assemble and send transactions 152 according to a transaction protocol. As described above, each blockchain node 126 executes software configured to validate transactions 152 according to a blockchain node protocol and to forward transactions 152 to propagate the transactions 152 throughout the blockchain network 132. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 126 in the network 132.

[0093] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, the party 103 assembles the new transaction according to the relevant transaction protocol (using the wallet functionality of the party's client application 105). The party 103 then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 126 to which it is connected. For example, 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 processes the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid", examples of which will be considered in more detail shortly. In some transaction protocols, the conditions for validity may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions could simply be a built-in feature of the node protocol or defined by a combination of the script and the node protocol.

[0094] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., the newly received transaction 152j is "validated"), every blockchain node 126 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 126. Additionally, every blockchain node 126 that receives the transaction 152j propagates the validated transaction 152 towards one or more other blockchain nodes 126 of the network 132. Since each blockchain node 126 applies the same protocol, this means that the transaction 152j is immediately propagated throughout the network 132, assuming that the transaction 152j is valid.

[0095] Once placed in the ordered set 154 of transactions maintained at a given blockchain node 126, that blockchain node 126 begins a race to solve a proof-of-work puzzle for the latest version of their respective ordered sets 154 of transactions that includes the new transaction 152. (Recall that other blockchain nodes 126 may be trying to solve puzzles based on different ordered sets 154 of transactions, but whoever succeeds first defines the ordered set of transactions included in the latest block 151. Eventually, the blockchain node 126 solves the puzzle for the part of the ordered set 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the ordered set 154 that includes the new transaction 152j, the ordered set 154 becomes immutably part of one of the blocks 151 of the blockchain 150. Each transaction 152 includes a pointer back to its previous transactions, so the order of the transactions is also immutably recorded.

[0096] Different blockchain nodes 126 may initially receive different instances of a given transaction and therefore may have conflicting views of which instance is "valid" before one instance is published in a new block 151, at which point all blockchain nodes 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, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that was not published in block 151).

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

[0098] Transactions recorded on the blockchain 112 are either spent or not spent, and model the transfer of value protected by a locking script. A transaction consumes value through its inputs and sends value to another through its outputs. The value input into a transaction must be equal to or greater than the value output by the previous transaction, and any extra input is collected as a transaction fee. If the solution proposed by the locking script, i.e. the unlocking script, is incorrect, if the transaction outputs more value than it takes as input, if the transaction consumes outputs that have already been consumed, or if the transaction attempts to consume value that does not exist at all, then the transaction is invalid.

[0099] Both the lock and unlock scripts are expressed in a machine-readable scripting language that allows for a wide variety of scripted conditions of use, including scripts that can embed arbitrary data (in the form of provably unspendable output) as data carrier output.

[0100] The payment processing resource 106 of FIG. 1a is configured to interact with the blockchain 112. The payment processing resource is configured to retrieve blockchain transactions and provide an unlock script to consume unspent outputs (UTXOs) from the 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 with unspent outputs and provide its own funds as input to those transactions. The payment processing resource 106 is configured to check that the outputs consumed by the transaction are not already spent outputs, i.e., the outputs consumed by the transaction are unspent outputs and are not double-spends, by checking the DHT or the temporary / secondary mempool for the presence of outputs. The payment processing resource 106 is then further configured to send the blockchain transaction to the blockchain 112 and receive a notification from the blockchain 112 when the transaction is received. Upon receiving a notification that the transaction has been received by the blockchain 112, the payment processing resource 106 is configured to generate an identifier for the transaction. The identifier may be alphanumeric. The payment processing resource 106 is configured to add provably unspendable outputs to the blockchain transactions it generates and to use those outputs to append a data carrier that includes a hash of data provided by the payment processing resource 106.

[0101] Once the identifier is generated by the payment processing resource 106, the payment processing resource 106 is configured to request that the data be recorded in an event stream (as described further below).

[0102] The payment processing resource 106 is configured to store information related to accounts used by users of the payment processing resource 106. The payment processing resource 106 may create, delete, and manage information related to these accounts using a database management system (DBMS) 140. The DBMS 140 may be located locally or remotely to the payment processing resource 106, and the payment processing resource 106 may access the DBMS 140 using any suitable electrical communication medium.

[0103] The payment processing resource 106 of Figure 1a is 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 participants who use the payment processing resource 106 to enable transactions to be conducted. The key storage module 122 may utilize any suitable storage and may utilize a database management system (DBMS) to initialize, store and retrieve data from records in the database of participants who store cryptographic keys in the key storage module 122. The payment data store 124 is configured to store data related to all payments made using the payment processing resource 106.

[0104] A user of either the first computing device 102 or the second computing device 126 may establish an account with the payment processing resource 106. Establishing such an account is described below with reference to FIG.

[0105] Alice initiates the setup process in step S200 by providing input requesting access to the payment processing resource 106. The first computing device 102 accesses the API 108 in step S202 and provides authentication data to the API 108 to allow interactions with the payment processing resource 106 to occur. The authentication data may include any data that can uniquely identify a user of the first computing device 102. Examples are a password, a combination of name and date of birth, or any other data item that can uniquely identify a user. Upon accepting the authentication data, the payment processing resource 106 sends a request in step S204 to the payment processing resource 106 for information needed to set up an account.

[0106] The information required by the payment processing resource 106 to set up an account is an asset registry that acts as a bookkeeping authority for managing the account, i.e., the identity of the bank providing the bank account, e.g., HSBC, information identifying the user, e.g., the user's public encryption key, data corresponding to a signed version of the issuer's terms and conditions, an identification of the currency the user wants to use, e.g., GBP (pound sterling), the issuer's public encryption key, and a minimum balance value that sets the minimum value of the account. Each asset registry is associated with at least one issuer of a corresponding asset that is associated with all accounts managed by the asset registry. For example, a bank is associated with the issuer of GBP and EUR. A bank may also be associated with issuers of other assets, such as gold and other precious metals. An example of an issuer of gold may be the Royal Mint of the United Kingdom. The information is stored by the payment processing resource 106 in records in the DBMS 140.

[0107] Alice then provides the required information, which is sent to the payment processing resource 106 via the API 108 in step S206. On receiving the details, the payment processing resource 106 creates a record in the asset registry database in step S208 and populates the record with the provided details in step S210.

[0108] The payment processing resource 106 then initializes an event stream 110a in accordance with UK Patent Application No. 2102314.8 corresponding to Alice's account in step S212 if the event stream has not already been initialized. Alternatively or additionally, the payment processing resource 106 may have already stored an event stream 110a for Alice.

[0109] The payment processing resource 106 then sends a confirmation message to the first computing device 102 in step S214 to confirm that an account has been established for Alice. Steps S200 through S214 are also used by Bob to establish an account on the payment processing resource 106 (associated with a bank such as HSBC). An event stream 110b corresponding to Bob's account is also initialized.

[0110] An event stream is a blockchain-based append-only log. A user of the payment processing resource 106, such as Alice or Bob, can create, append to, and close event streams corresponding to their account, as described below.

[0111] Alternatively, Alice or Bob may provide account details associated with an asset registry they are already using, avoiding steps S200 to S214, provided they have provided all of the required information.

[0112] Preparing payment data for recording We now describe several example scenarios in which asset transfers are enabled by the payment processing resource 106. These examples are intended to be illustrative and non-limiting in that features of each example may be combined with features of the other examples.

[0113] 3a and 3b, an exemplary scenario will now be described in which Alice sends 5 GBP to Bob using the payment processing resource 106. In this example, the asset being transferred is cash and the asset registry is a bank.

[0114] In step S300, Alice contacts Bob to inform him that Alice would like to send him 5 GBP for his upcoming birthday. In step S302, Bob sends Alice a message using any suitable medium to thank her for her generosity.

[0115] Alice then uses the first computing device 102 to indicate to the payment processing resource 106 her desire to pay 5 GBP. The first computing device 102 accesses the API 108 to initiate the payment process using the account created by Alice according to steps S200 to S214. This is step S306. The call from the device 102 to the API 108 indicates the amount Alice wishes to pay to Bob. The call from the device 102 further indicates the account from which Alice wishes to pay, the currency in which Alice wishes to pay, and to whom Alice wishes to pay, i.e., Bob. The amount Alice wishes to pay Bob, Bob's identity, and the identity of the account from which Alice wishes to pay (i.e., GBP) form a set of payment metadata that is sent to the payment processing resource 106 in step S308.

[0116] When the payment processing resource 106 receives the payment metadata from Alice, it retrieves metadata from Bob's account based on the metadata provided by Alice in step S308. This is step S310. The payment processing resource 106 retrieves the currency with which Bob's account is associated, i.e., Pound Sterling (GBP), and the bank from Bob's account.

[0117] The payment processing resource 106 then generates a payment instruction data set in step S312 using the payment metadata received from Alice and the information retrieved from Bob's account.

[0118] In this example, the provider of Bob's bank account is "hsbc.com", the currency is specified as GBP, the amount of the payment (i.e. the amount being received by Bob) is 5GBP, and the account identity is <bob:hsbc>where the user is identified as Bob by the "kyc" value and the actor is identified as the beneficiary of the payment, i.e. the individual receiving the payment. This forms part of the payment instructions dataset, which may optionally be accompanied by a signature<Bob_sig> It may also contain a version of the terms and conditions signed by Bob using

[0119] Another part of the payment instructions dataset is formed by Alice's details: the account provider is "hsbc.com", the currency is specified as GBP, the amount of the payment being sent to Bob is 5GBP (i.e. a debit of 5GBP from Alice to be paid to Bob, and is therefore represented in the payment instructions dataset as -5), and the account identity is <alice:hsbc>and the user is identified as Alice by the "kyc" value. The payment instructions dataset may also include terms and conditions signed by Alice that may be included in a document that may be accessed from a Uniform Resource Locator (URL). The payment instructions dataset also identifies the actor as the originator of the payment, i.e., the individual making the payment.

[0120] A message is then sent to the first computing device 102 with a request for Alice's signature on the payment instruction data set in step S314. Alice then provides her cryptographic signature in step S316 to authorize the payment of 5 GBP to Bob. Alice's signature is then applied to the payment instruction data set by the payment processing model 132. That is, Alice signs the payment instruction data set with her cryptographic signature. In short, Alice's account has been debited and Bob's account has been credited. Therefore, Alice's signature is required. Bob's signature may only be required if Bob provided a t&c link (i.e., a URL to a terms and conditions document that Bob signed) and a hash of the document containing the terms and conditions. This means that if Alice is buying something from Bob in exchange for the transferred funds, it can be provably shown that Bob provided the terms and conditions in return for payment.

[0121] Only one signature is required in this example as the bank is the same and the amounts match - two signatures may be required if Bob provided a t&c link as described above.

[0122] The payment processing resource 106 then applies the payment protocol criteria to the payment instruction data set in step S318. The payment processing resource 106 accesses the payment protocol module 120 in step S320.

[0123] The payment protocol module 120 first checks that the payment instruction dataset adheres to the zero-sum rule in that the amounts match, i.e., the amount being debited from Alice's account is equal to the amount being paid to Bob's account. This is step S322. The zero-sum rule is adhered to because 5 GBP is debited from Alice's account and 5 GBP is paid to Bob's account, i.e., the amounts are the same and the banks are the same. That is, -5 GBP is added to Alice's account and +5 GBP is added to Bob's account, so the amounts add up to 0. Since the banks are the same, this step is satisfied and the dataset adheres to the zero-sum rule.

[0124] Then, the payment protocol module 120 checks that the amount being transferred from Alice to Bob does not bring Alice's balance below some minimum value. This is step S324. That is, is Alice overspending? If Alice is overspending, i.e., if her balance (minus 5 GBP) would be below the minimum value, the payment protocol module 120 issues an error message to Alice informing her that she cannot spend the money she wants to spend, i.e., that she does not have the funds to pay Bob the 5 GBP. Moreover, the minimum value can be negative if a credit line is used. The payment protocol module 120 returns to step S320 until it is told to start again, i.e., when Alice deposits more funds into her bank account or when Alice's minimum balance is changed.

[0125] The payment protocol module 120 then checks whether the data related to the payment matches between the two parties to the transaction by checking the fields in the data that correspond to the asset identities. This is step S326. The data in this example matches because the zero-sum rule is satisfied and the bank is the same, i.e. "hsbc.com", and the currency is the same; that is, the bank and asset identities balance. As will be seen in further examples below, when the bank and asset identities do not balance, further metadata needs to be generated to provide the required balance.

[0126] Another way to show this might be to utilize a template for showing the bank and asset identities (XXX_BBBB:AAAA), where XXX is the account manager, BBBB is the bank identity, and AAAA is the asset identity. Using this template, it can be shown that 5GBP is being paid from Alice_HSBC:GBP to Bob_HSBC:GBP, showing that the bank and asset identities match.

[0127] The payment processing module 120 proceeds to step S328 where the cryptographic signatures of Alice and Bob are verified. The payment processing module 120 verifies the cryptographic signatures of Alice and Bob by generating a hash of each signature and comparing the hash to those stored in the records generated in steps S200 through S214. This also verifies the identities of Alice and Bob. Alternatively or additionally, standard PKI techniques based on private / public cryptographic key pairs may also be used to verify each signature. These techniques may also be used to verify the identity of the client.

[0128] Satisfaction of steps S322, S324, S326, and S328 means that the criteria defined by the payment protocol have been met, and therefore the payment processing resource 106 enables a payment of 5 GBP from Alice to Bob to be made in accordance with the payment instruction dataset.

[0129] The payment processing resource 106 then retrieves, in step S330, the blockchain transactions for each of Alice and Bob from the blockchain 112. This is explained with reference to the exemplary schematic diagram of FIG. 3c.

[0130] Alice's blockchain transaction 402 includes a dust output (Tx0, Alice), and Bob's blockchain transaction 404 includes a dust output (Tx0, Bob).

[0131] Creating a rendezvous transaction The payment processing resource 106 then generates a new rendezvous blockchain transaction 406 that includes the dust inputs of each of Alice and Bob using the respective dust outputs from the blockchain transaction retrieved in step S330. The dust outputs may be retrieved from the dust chain corresponding to the event stream related to Alice and Bob. This is also shown in FIG. 3c. The chain of transactions 402 and 404 to 406 may be described as a chain of dust transactions. The dust inputs / outputs are inputs / outputs of amounts of cryptocurrency that are indicated to be "dust" by the cryptocurrency field. "Dust" in the context of blockchain transactions of this disclosure is understood to be a usable transaction for a digital asset or cryptocurrency that has a low or very small value output, i.e., the value may be much less than the fee for mining the output in the blockchain.

[0132] Alternatively, the payment processing resource 106 may generate a new dust transaction using a combination of dust that does not form part of the existing event stream and a hierarchical deterministic (HD) key chain, as described in UK Patent Application No. 2102217.3. In other words, a dust transaction is generated using the dust as input and including inputs corresponding to each of Alice and Bob, where the dust has not already been used in the event stream. A party in possession of the HD key chain may generate the first transaction of the new event stream using one of the subkeys and the dust. In essence, a new event stream may be initiated based on dust that may be taken from existing transactions on the blockchain 112 and used as a basis for the initiation of a new event stream. That is, the dust may be used to generate a transaction (to initiate a new event stream) and then returned to the platform before being used to initiate another event stream.

[0133] The relationship between chains of dust transactions and event streams will be further clarified below with reference to Figure 3d.

[0134] FIG. 3d relates to a first aspect of the disclosure and illustrates the basic data structure and paradigm of an ordered append-only data storage system. This can also be described as a data logging system. The particular system illustrated in FIG. 3d is an event stream system for logging events. As an example, an event stream is used throughout for illustrative purposes, but those skilled in the art will understand that the proposed systems and aspects described herein may be used with data items broadly and with ordered append-only data item logging or storage systems. Consistent with FIG. 4 and FIG. 6, the data items refer to hashes of the actual data. Advantageously, using a hash instead of the data itself provides proof of the existence of the data without requiring the data (which may be large, even too large for a transaction) to be stored in the transaction. This also protects the privacy of the data, since the data is indistinguishable from the hash, even if the hash is published on the chain. The data described here is payment instruction data associated with a payment that has been recorded by the payment processing resource 106.

[0135] Each event 502 in the append-only log is mapped to a blockchain transaction 504, and the sequence of blockchain transactions is ordered and linked 506 using a "chain of dust". Data related to each event is stored in a payload (described below) as part of each transaction. The data payload (i.e., a hash of the payment instruction metadata) is held in an unusable OP_RETURN output of the transaction -- an example of such a transaction is the Rendezvous transaction 406 mentioned above. This is a Script opcode that can be used to write arbitrary data to the blockchain and also to mark the output of a transaction as invalid. As another example, OP_RETURN is a Script language opcode to store data such as metadata within the transaction, thereby creating an unusable output of a transaction, which can immutably record the metadata on the blockchain.

[0136] A chain of dust is here an unbroken chain of cryptocurrency inputs and outputs used to impose a spending dependency of each blockchain transaction in a sequence on its immediate predecessor.

[0137] The use of dust outputs in transactions is advantageous and important for an ordered append-only data storage system such as an event stream to maintain an immutable continuous record of all transactions as they occur. This is because, by posting transactions to the blockchain, all blockchain transactions are time-stamped and remain in a particular order as they are confirmed on or added to the blockchain, but this does not guarantee the preservation of the chronological order of those transactions. This is because transactions may be mined into blocks at different times and / or transactions may be in different orders even within the same block. Advantageously, the use of dust outputs used by the first input of the next transaction in the sequence ensures that the order of transactions is tracked chronologically, creating a tamper-proof record of both the events themselves and the chronological order of the events. This is because, once mined into a block, the dust payment from the previous transaction to the next transaction in the sequence ensures that the sequence of embedded data carrier elements, called payloads and discussed below, cannot be reordered, consistent with Bitcoin protocol rules, and no insertions or deletions can occur that could change the sequence without it being immediately apparent that the event stream has been compromised. In some embodiments, the double-spend prevention mechanism inherent in the Bitcoin protocol ensures that the movement of cryptocurrency (e.g., dust) between the inputs and outputs of different transactions remains in chronological order. The chaining of dust transactions exploits topological ordering to provide preservation of order of transactions (and thus associated events and data) between and within blocks. This therefore improves the integrity of ordered append-only data item storage.

[0138] In this way, the blockchain transactions 504 form a directed graph of transactions. Note that the direction of the graph can be thought of as unidirectional, from the previous transaction in the sequence to the next transaction, as indicated by edge 506. Although the arrow of edge 506 in FIG. 3d indicates that the transaction points to the next transaction, the spending relationships in Bitcoin transactions are actually from one transaction to the preceding transaction. The graph is created by the spending relationships between transactions. These spending relationships can be thought of as a kind of reference. Further details on how events should be appended to the event stream can be found in UK Patent Application No. 2102314.8 and in particular, but not exclusively, where it refers to "Ordered, Append-only data Storage", "Event Stream and the Chain of Dust", and "Backward Referencing in the Chain of Dust".

[0139] A rendezvous blockchain transaction, such as transaction 406 shown in FIG. 3c, is a blockchain transaction to synchronize multiple event streams, each associated with a given entity / user as described above. This is accomplished by using multiple dust outputs as corresponding inputs. In this example, this allows chains of dust (i.e., dust input / output pairs) corresponding to each of Alice, Bob, and HSBC to pass through a single transaction. The dust chain input / output pairs must have corresponding input / output indexes within the transaction. In this case, the dust chain input / output pairs are used to allow payments to be recorded in all event streams associated with the transaction, as described below.

[0140] The dust input that uses Alice's dust output is denoted as Tx1, Alice, and the dust input that uses Bob's dust output is denoted as Tx1, Bob. In step S332, a new rendezvous blockchain transaction 406 is created.

[0141] Funds to a rendezvous blockchain transaction 406 are added by and paid back to the payment processing resource 106. This may be minus any miner's fees after the rendezvous blockchain transaction 406 is validated if the rendezvous blockchain transaction 406 is sent to the blockchain 112 for validation.

[0142] The rendezvous blockchain transaction 406 includes further dust outputs using Tx1, Alice and Tx1, Bob, respectively. When it is a rendezvous transaction, the indices of the input / output pairs corresponding to Alice and Bob, respectively, are identical in that, for example, the input index of Tx1, Alice may be assigned as number 1, and the output index of the corresponding dust output is assigned as output index number 1.

[0143] The payment processing resource 106 also adds a provably unspendable output to the blockchain transaction 406 for each of Alice and Bob in the form of data carriers 412a and 412b.

[0144] Each data carrier may hold a different dataDigest and / or a different streamDigest, which may be salted.

[0145] The data payload held in the respective data carrier (i.e., a hash of the payment instruction metadata) is held in an unusable OP_RETURN output of the transaction, which means that the data payload may subsequently be stored in the blockchain as an unusable output. This means that the data payload held in the respective data carrier (i.e., a hash of the payment instruction metadata) is held in an unusable OP_RETURN output of the transaction, which means that the data payload may subsequently be stored in the blockchain as an unusable output.

[0146] The data in the data carrier 412 includes a hash of the payment instruction dataset generated by the payment processing resource in steps S300 to S328. This is generated in step S334. The provably unspendable output enables the rendezvous transaction 406 to carry the hash of the payment instruction dataset in the transaction, allowing the hash to be stored on the blockchain. This means that the payment instruction dataset, and thus the record of the payment, is stored on the blockchain. This means that the record of the payment benefits from the immutability of the blockchain.

[0147] The blockchain transaction 406 may then be checked to see if the user correspondence with the transaction is correct and corresponds to the users, i.e., Alice and Bob. This is step S336.

[0148] The payment processing resource 106, in step S338, issues a notification to the event stream resource 110 confirming that the blockchain transaction 406 can be used as the basis for adding data to the event stream, i.e., the event stream relating to Alice and Bob.

[0149] An event stream is an append-only log backed by a blockchain. In this example, Alice and Bob each have their own event stream, but if they do not, an event stream may be initialized. That is, Alice has an event stream (E-Alice) and Bob has an event stream (E-Bob). An entry in an event stream may be denoted as ESn, where n may be a non-zero positive integer or a non-negative integer.

[0150] As shown in FIG. 3d, an event stream can be viewed as a series of entries, and any entry in the stream may be referenced by a monotonically increasing sequential number, i.e., the first entry might be referred to as ES1, the second entry might be referred to as ES2, etc.

[0151] The payment processing resource 106 adds to the respective event streams only if Alice and Bob are authorized to access or add to the event streams. Authorization may be checked, for example, by comparing the signature with a signature stored in the payment processing resource 106. By adding the payment data to the event stream, the payment can benefit from being recorded and recorded in an immutable log that is associated with the blockchain 112. In short, the event stream is used to track the order of transactions from accounts associated with Alice and Bob. That is, the entries in the event stream are an immutable log that is associated with the blockchain 112. The event stream described above ensures the following: Individual entries in the event stream have not been modified since they were written. No entry has been inserted between previously consecutive entries The entry has not been deleted The entries have not been reordered Unauthorized parties may not add events to the stream.

[0152] The payment processing resource 106 synchronizes the payment with the event streams E-Alice and E-Bob using the rendezvous transaction 406 by appending to each of those event streams an entry containing a hash of the payment instruction metadata contained in the data carrier of the blockchain transaction 406. This is step S340. This is shown diagrammatically in Figure 3e.

[0153] The payment processing resource 106 then generates an identifier for the entry added to each of the event streams. This is step S342. The identifier may be alphanumeric, or may be a number generated based on a hash of the payment instruction metadata. For example, if the hash of the payment instruction metadata is generated by a SHA256 cipher, the identifier may be generated by applying a further SHA256 cipher to the hash of the payment instruction metadata. That is, the identifier may be a hash of the hash of the payment instruction metadata.

[0154] The payment processing resource 106 then stores the identifier along with a copy of the payment instruction metadata in the payment data store 124. This allows for verification of the payment between Alice and Bob, upon request.

[0155] A further exemplary scenario will now be described in which Alice also pays Bob a sum of 5 GBP, but where Bob's account is provided by Revolut rather than HSBC. This will be described with reference to Figures 4a and 4b. This example is identical to the example described with reference to Figures 3a to 3e up to step S326. Therefore, for brevity, the description will start from the stage described with reference to step S326.

[0156] In other words, for step S326 to yield a positive result and for the transaction to proceed, the bank must be reconciled, i.e. metadata must be created that reconciles both the bank and the asset identification information.

[0157] That is, when the payment protocol module 120 checks (at step S326) whether the data related to the payment matches between the two parties in the transaction by checking the fields in the data corresponding to the parties, it finds that the currencies are the same and the amounts are complementary, i.e. Alice is debited -5GBP and Bob is credited 5GBP, but the account providers are different, i.e. Alice's account provider is "hsbc.com" and Bob's account provider is "Revolut".

[0158] Another way to indicate this may utilize a template to indicate the bank and asset identity (XXX_BBBB:AAAA), where XXX is the account operator, BBBB is the bank identity, and AAAA is the asset identity. In this case, an attempt to transfer 5GBP from Alice_HSBC:GBP to Bob_REVOLUT:GBP could not be completed.

[0159] At that time, the payment protocol module 120 stops checking the payment instruction dataset against the payment protocol criteria, and the payment processing resource 106 generates additional metadata that is added to the payment instruction dataset.

[0160] Generate more metadata about two different banks The payment processing resource 106 accesses the key storage module 122 with a request for the encryption keys corresponding to "Revolut.com" and "HSBC". This is step S400.

[0161] The key storage module 122 stores a number of encryption keys, each of which is stored in a record corresponding to a bank, such as "Revolut.com" or "HSBC", enabling the payment processing resource 106 to generate unique payment instruction data for payments to and from accounts managed by these banks. This is particularly advantageous when payments are being made between accounts at different banks, as it means that payments can be securely enabled by the payment processing resource 106 even if the banks the parties select for their accounts are different.

[0162] When the key storage module 122 is accessed, it receives an input identifying the bank that corresponds to the requested key. The key storage module 122 returns the key that corresponds to the bank. In this example, the keys that correspond to the banks "Revolut.com" and "HSBC" are returned. This is step S402.

[0163] The payment processing resource 106 then modifies the payment instruction dataset to include further metadata detailing two further payments. The metadata details that the first payment is from Alice to HSBC for 5 GBP, and is signed by the HSBC key retrieved from the key storage module 122, as it is a payment from Alice's HSBC account, but not a payment that Alice has already signed, i.e., a payment to Bob. The metadata further details that the second payment is from HSBC to Revolut (for 5 GBP, i.e., the HSBC account is debited by 5 GBP), and is signed by the Revolut.com key retrieved from the key storage module 122. And the metadata further details that a further payment is from Revolut to Bob's Revolut account (i.e., Bob's balance is increased by 5 GBP, but Revolut must now debit it from the HSBC account), which is signed by Bob's key. This means that any discrepancies between the data identified in step S326 are resolved by the payment processing resources 106. This is step S404. That is, upon determining that there is a discrepancy, the discrepancy is resolved by the payment processing resources 106 to ensure that the banks match and the amounts match.

[0164] Using the template above, amending the payment instruction dataset to include further metadata would mean that 5GBP is paid from Alice_HSBC:GBP to HSBC_HSBC:GBP, then 5GBP is paid from HSBC_HSBC:GBP to HSBC_REVOLUT:GBP, and then a payment is made from HSBC_REVOLUT:GBP to Bob_REVOLUT:GBP, which means that the bank identification and asset identification match and the transaction can be completed.

[0165] Because step S326 initially returned a negative result because the banks did not match, the payment protocol module 120 must begin again to evaluate the payment instruction dataset in light of the payment protocol. The payment instruction dataset has already returned a positive determination regarding satisfaction of the zero-sum rule and Alice's spending limit, as described in connection with steps S322 and S324. With the payment instruction dataset now modified to include the identity of the assets and payments introduced by the payment processing resource 106 to resolve the lack of match between the banks and ensure that the banks are in balance, the payment processing module 120 moves to step S406 where the cryptographic signatures of Alice and Bob are verified.

[0166] The payment processing module 120 verifies the cryptographic signatures of Alice and Bob by generating a hash of each signature and comparing the hash with the one stored in the record generated in steps S200 to S214. This also verifies the identity of Alice and Bob. Alternatively or additionally, standard PKI techniques based on private / public cryptographic key pairs may also be used to verify each signature. These techniques may also be used to verify the identity of the client. The payment processing module 120 also verifies the signatures of the two banks, namely HSBC and Revolut, using similar techniques.

[0167] Upon completion of step S406, the payment processing resources 106 enable a payment of 5 GBP from Alice to Bob to be made in accordance with the payment instruction dataset, i.e., the payment processing resources 106 resolves the lack of a match in the payment instruction dataset by applying two further payments to resolve the lack of a match and make the payment instruction dataset suitable for making a payment using the payment instruction dataset.

[0168] Rendezvous transaction between two banks The payment processing resource 106 then retrieves the blockchain transactions for each of Alice and Bob from the blockchain 112 in step S408. This is explained with reference to the exemplary schematic diagram of FIG. 4b.

[0169] Alice's blockchain transaction 602 includes a dust output (Tx0, Alice) and Bob's blockchain transaction 604 includes a dust output (Tx0, Bob). The payment processing resource 106 also retrieves the blockchain transactions of the banks involved in the payment, namely HSBC and Revolut. HSBC's retrieved blockchain transaction 608 includes a dust output (Tx0, HSBC). Revolut's retrieved blockchain transaction 610 includes a dust output (Tx0, Revolut).

[0170] The payment processing resource 106 then generates a new rendezvous blockchain transaction 606 that includes dust inputs for each of Alice and Bob using their respective dust outputs from the blockchain transaction retrieved in step S408. The dust outputs may be retrieved from dust chains corresponding to the event streams associated with Alice and Bob. This is also shown in FIG. 4b. The rendezvous blockchain transaction 606 further includes dust inputs for HSBC and Revolut retrieved from blockchain transactions 408 and 410, respectively.

[0171] Alternatively, similar to the first example, the payment processing resource 106 may generate new dust transactions using dust that does not form part of the existing event stream and a hierarchical deterministic (HD) key chain.

[0172] The relationship between the chain of dust transactions and the event stream has already been made clear with reference to Figure 3d.

[0173] Rendezvous blockchain transaction 606 is a blockchain transaction for synchronizing multiple event streams corresponding to Alice, Bob, Revolut, and HSBC.

[0174] The dust input using Alice's dust output is denoted as (Tx1, Alice), and the dust input using Bob's dust output is denoted as (Tx1, Bob). In step S410, a new rendezvous blockchain transaction 606 is generated. The new rendezvous transaction also includes dust inputs corresponding to HSBC, denoted as (Tx1, HSBC), and dust inputs corresponding to Revolut, denoted as (Tx1, Revolut).

[0175] Funds to the rendezvous blockchain transaction 606 are added by and paid back to the payment processing resource 106. This may be minus any miner's fees after the rendezvous blockchain transaction 606 is validated if the rendezvous blockchain transaction 606 is sent to the blockchain 112 for validation.

[0176] The rendezvous blockchain transaction 606 includes further dust outputs using Tx1, Alice and Tx1, Bob, respectively. The rendezvous blockchain transaction 606 also includes dust outputs corresponding to the dust inputs retrieved from the blockchain for HSBC and Revolut.com.

[0177] The payment processing resource 106 also adds a provably unusable output to the blockchain transaction 606, which is used as a data carrier 612. Each of the data carriers may be identical and based on the same data and based on the same payment instruction data set. The data carriers may hold several different data based on the streamState of the particular data stream to which the carrier is attached, the streamState based on the previous streamState and / or the index (or sequence number) and / or the individual salt used for notarisation of the data carrier. Alternatively or additionally, further provably unusable outputs may be added corresponding to all the parties that provide input to the blockchain transaction 606 to add data carriers for each of them. That is, each data carrier may contain data related to each party in that each data carrier may be different depending on each party. For example, a difference may be that a data carrier for Alice may contain data related only to Alice, i.e. Alice's name and Alice's account number, and a data carrier for Bob may contain data related only to Bob, i.e. Bob's name and Bob's account number.

[0178] As with the first example, the data payload held in the data carrier (i.e. the hash of the payment instruction metadata) is held in a non-spendable OP_RETURN output of the transaction, meaning that the data payload can then be stored on the blockchain as a non-spendable output.

[0179] The data in each of the data carriers 612 includes a hash of the payment instruction dataset generated by the payment processing resource 106. This is generated in step S412. The provably unspendable output enables the rendezvous transaction 606 to carry the hash of the payment instruction dataset in the transaction, allowing the hash to be stored on the blockchain. This means that the payment instruction dataset, and thus the record of the payment, is stored on the blockchain. This means that the record of the payment benefits from the immutability of the blockchain.

[0180] The blockchain transaction 606 may then be checked to see if the transaction and the user correspondence with the accounts offered by HSBC and Revolut are correct and correspond to the users, i.e., Alice and Bob. This is step S412.

[0181] The payment processing resource 106 issues (at step S416) a notification to the event stream resource 110 confirming that the blockchain transaction 606 can be used as the basis for adding data to the event stream, i.e., the event streams relating to Alice, Bob, Revolut, and HSBC.

[0182] In this example, Alice, Bob, and HSBC each have their own event streams, but if they do not have them, event streams may be initialized: Alice has an event stream (E-Alice), Bob has an event stream (E-Bob), HSBC has an event stream (E-HSBC), and Revolut also has (E-Revolut).

[0183] The payment processing resource 106 synchronizes the payment with the event streams E-Alice, E-Bob, E-Revolut, and E-HSBC using the rendezvous transaction 606 by appending an entry to each of those event streams that includes a hash of the payment instruction metadata included in the data carrier of the blockchain transaction 606. This is step S418. This is shown diagrammatically in FIG. 4c. The event streams E-Alice, E-Bob, E-Revolut, and E-HSBC may be of different lengths, and the hash of the payment instruction data may be appended to different positions (also known as indexes) in the respective event streams, since each event stream may contain a different number of events. For example, a particularly active party such as a bank may have a significantly longer event stream than an individual, and the payment instruction data may be appended to the bank's event stream at a much larger index than for the individual. It is also possible that the bank may choose to start a new event stream after the number of entries appended to the event stream exceeds a predetermined amount.

[0184] As with other examples, each of the data carriers may have a different dataDigest and / or a different streamDigest. The streamDigest may also be salted. Revolut and HSBC may choose to generate a salted streamDigest using a different hashing method than the hashing method used by Alice and Bob.

[0185] The payment processing resource 106 then generates an identifier for the entry added to each of the event streams. This is step S420. The identifier may be alphanumeric, or may be a number generated based on a hash of the payment instruction metadata. For example, if the hash of the payment instruction metadata is generated by a SHA256 cipher, the identifier may be generated by applying a further SHA256 cipher to the hash of the payment instruction metadata. That is, the identifier may be a hash of the hash of the payment instruction metadata.

[0186] The payment processing resource 106 then stores the identifier along with a copy of the payment instruction metadata in the payment data store 124. This allows for verification of the payment between Alice and Bob, upon request.

[0187] Below we describe a further exemplary scenario in which Alice also pays Bob 5 GBP, but Bob's account is managed by HSBC, but is a Euro account rather than a GBP account.

[0188] This will be explained with reference to Figures 5a and 5b. This example is again identical to the example explained with reference to Figures 3a to 3e up to step S326. Therefore, for the sake of brevity, the explanation will start from the stage explained with reference to step S326.

[0189] That is, when the payment protocol module 120 checks (at step S326) whether the data related to the payment matches between the two parties in the transaction by checking the fields in the data corresponding to the parties, it is found that the currencies of Alice's and Bob's accounts are different. In other words, Alice has an account with HSBC in GBP and Bob has an account with HSBC in Euros, i.e. same bank but different currencies, i.e. different asset identifiers.

[0190] At that point, the payment protocol module 120 stops checking the payment instruction dataset against the payment protocol criteria because the currencies are different, and the payment processing resource 106 generates additional metadata that is added to the payment instruction dataset.

[0191] Generate more metadata when accounts have different currencies The payment processing resource 106 accesses the key storage module 122 with a request for an encryption key corresponding to an account held by HSBC for GBP and an account held by HSBC for EUR. This is step S500.

[0192] When the key storage module 122 is accessed, it receives input identifying the bank and respective asset identifiers, i.e., GBP and EUR, that correspond to the requested key. The key storage module 122 returns the keys that correspond to the bank's GBP and EUR accounts. In this example, the keys that correspond to the GBP and EUR accounts managed by HSBC are returned. This is step S502.

[0193] That is, in this case, the assets do not have the same identity (because GBP and EUR are not the same currency), but Alice and Bob do have the same bank. This is why step S326 results in a negative result in this example: the asset identities and banks do not match exactly because the currencies are different.

[0194] In other words, just as asset types must be balanced, currencies must be balanced for step S326 to yield a positive result.

[0195] Therefore, payment processing module 120 needs to generate further metadata that resolves this discrepancy. Having obtained the keys corresponding to the GBP and EUR accounts managed by HSBC, payment processing module 120 can then generate this metadata.

[0196] In step S504, payment processing module 120 generates metadata corresponding to two further payments: a first for a payment of 5 GBP from Alice's GBP HSBC account to HSBC's GBP account (i.e., Alice gives 5 GBP back to HSBC) and a second for a payment of 5.81 EUR from HSBC's EUR account to Bob's EUR HSBC account.

[0197] In step S506, the payment processing module 120 verifies the cryptographic signatures of Alice and Bob (if necessary) by generating a hash of each signature and comparing the hash to those stored in the records generated in steps S200 through S214. This also verifies the identities of Alice and Bob. Alternatively or additionally, standard PKI techniques based on private / public cryptographic key pairs may also be used to verify each signature. These techniques may also be used to verify the identity of the client.

[0198] Because the bank and asset identities now match, the requirements of step S326 are met and the payment protocol criteria may be satisfied, i.e., metadata is created that matches the bank and asset identities.

[0199] Another way to show this may utilize a template (XXX_BBBB:AAAA) to show the bank and asset identities, where XXX is the account operator, BBBB is the bank identity, and AAAA is the asset identity. That is, prior to the generation of the metadata in step S504, the attempt to transfer 5 GBP from Alice_HSBC:GBP to Bob_HSBC:EUR could not be completed. However, the creation of the metadata in step S504 means that 5 GBP is paid from Alice_HSBC:GBP to HSBC_HSBC:GBP, and then 5.81 EUR (the EUR equivalent of 5 GBP) is paid from HSBC_HSBC:EUR to Bob_HSBC:EUR, which means the bank identity and asset identity balance, which means the transaction can be completed.

[0200] Upon completion of step S506, the payment processing resources 106 enable a payment of 5 GBP from Alice to Bob to be made in accordance with the payment instruction dataset, i.e., the payment processing resources 106 resolves the lack of a match in the payment instruction dataset by applying two further payments to resolve the lack of a match and make the payment instruction dataset suitable for making a payment using the payment instruction dataset.

[0201] Two-currency rendezvous transaction The payment processing resource 106 then retrieves, in step S508, the blockchain transactions for each of Alice and Bob from the blockchain 112. This is explained with reference to the exemplary schematic diagram of FIG. 5b.

[0202] Alice's blockchain transaction 702 includes a dust output (Tx0, Alice_HSBC:GBP) and Bob's blockchain transaction 704 includes a dust output (Tx0, Bob_HSBC:EUR). The dust outputs may be retrieved from the dust chain corresponding to the event streams associated with Alice and Bob. The payment processing resource 106 also retrieves blockchain transactions for currency accounts also involved in the payment. The retrieved blockchain transaction 708 for HSBC's GBP (i.e., HSBC_HSBC:GBP) account includes a dust output (Tx0, HSBC-GBP). The retrieved blockchain transaction 710 for HSBC's EUR (i.e., HSBC_HSBC:EUR) account includes a dust output (Tx0, HSBC-EUR). As shown in Figure 5b, each of the blockchain transactions 702, 704, 708, and 710 also includes a provably unspendable output that has a redeem script that includes an OP_RETURN command to ensure that the output cannot be spent but that the data carrier associated with the output remains on the blockchain. The dust outputs (Tx0, HSBC-GBP) and (Tx0, HSBC-EUR) may be retrieved from the dust chain corresponding to the event streams associated with HSBC's EUR and GBP accounts.

[0203] The payment processing resource 106 then generates (at step S510) a new rendezvous blockchain transaction 706 that includes dust inputs for each of Alice and Bob using their respective dust outputs from the blockchain transaction retrieved in step S508. This is also shown in Figure 5b. The rendezvous blockchain transaction 706 further includes dust inputs for HSBC-GBP and HSBC-EUR retrieved from blockchain transactions 708 and 710, respectively.

[0204] The relationship between the chain of dust transactions and the event stream has already been made clear with reference to Figure 3d.

[0205] Rendezvous blockchain transaction 606 is a blockchain transaction for synchronizing multiple event streams corresponding to Alice, Bob, Revolut, and HSBC.

[0206] The dust input that uses Alice's dust output is denoted as (Tx1, Alice), and the dust input that uses Bob's dust output is denoted as (Tx1, Bob). The new rendezvous transaction also contains dust inputs corresponding to HSBC's GBP and EUR accounts, denoted as (Tx1, HSBC-GBP) and (Tx1, HSBC-EUR), respectively.

[0207] Funds to the rendezvous blockchain transaction 706 are added by and paid back to the payment processing resource 106. This may be minus any miner's fees after the rendezvous blockchain transaction 706 is validated if the rendezvous blockchain transaction 706 is sent to the blockchain 112 for validation.

[0208] The rendezvous blockchain transaction 706 includes further dust outputs using Tx1, Alice and Tx1, Bob, respectively. The rendezvous blockchain transaction 706 also includes dust outputs corresponding to the dust inputs retrieved from the blockchain for HSBC-GBP and HSBC-EUR.

[0209] The payment processing resource 106 also adds provably unspendable outputs to the blockchain transaction 706 for Alice, Bob, and each of the HSBC-GBP and HSBC-EUR accounts, which are used as data carriers 712a, 712b, 712c, and 712d.

[0210] As with the first example, the data payload held in the data carrier (i.e. the hash of the payment instruction metadata) is held in a non-spendable OP_RETURN output of the transaction, meaning that the data payload can then be stored on the blockchain as a non-spendable output.

[0211] Similar to the first and second examples, the payment processing resource 106 may be configured to generate new dust transactions using dust that does not form part of the existing event stream and the HD key chain. A combination of dust inputs from the existing dust chain and the new dust transactions may be used to generate blockchain transactions 706.

[0212] The data in the data carriers 712a, 712b, 712c, and 712d include hashes of payment instruction data sets generated by the payment processing resource 106. The data carriers may be identical because they are based on the same payment instruction data set. Alternatively or additionally, the data in the data carriers may be different because each relates to a different party.

[0213] That is, each data carrier may contain data relevant to each party in that each data carrier may differ depending on each party. For example, the difference may be that a data carrier relating to Alice may contain data relevant only to Alice, i.e., Alice's name and Alice's account number, and a data carrier relating to Bob may contain data relevant only to Bob, i.e., Bob's name and Bob's account number.

[0214] The data carrier therefore generates a different hash, which is generated in step S512. The provably unspendable output allows the rendezvous transaction 706 to carry the hash of the payment instruction dataset in the transaction, and for the hash to be stored on the blockchain. This means that the payment instruction dataset, and thus the record of the payment, is stored on the blockchain. This means that the record of the payment benefits from the immutability of the blockchain.

[0215] Similar to the above example, each of the data carriers may hold a different dataDigest and / or a different streamDigest.

[0216] The blockchain transaction 706 may then be checked to see if the transaction and the user correspondence with the accounts provided by HSBC (for both GBP and EUR) are correct and correspond to the users, i.e., Alice and Bob. This is step S514.

[0217] The payment processing resource 106 issues (at step S516) a notification to the event stream resource 110 confirming that the blockchain transaction 606 can be used as the basis for adding data to the event stream, i.e., the event streams relating to Alice, Bob, Revolut, and HSBC.

[0218] In this example, Alice, Bob, and HSBC (for both GBP and EUR) each have their own event streams, but if they do not, event streams may be initialized: Alice has an event stream (E-Alice), Bob has an event stream (E-Bob), and HSBC has event streams for both currencies, i.e., (E-HSBC-GBP) and (E-HSBC-EUR).

[0219] The payment processing resource 106 synchronizes the payment with the event streams E-Alice, E-Bob, E-HSBC-GBP, and E-HSBC-EUR using the rendezvous transaction 706 by appending an entry to each of those event streams that includes a hash of the payment instruction metadata included in the data carrier of the blockchain transaction 706. This is step S518. That is, if the data output 712a corresponds to Alice, the data output 712a is hashed and added to Alice's event stream. This is shown diagrammatically in FIG. 5c. Each entry includes a hashed digest of the data included in the stream up to that entry. Such a hashed digest of the stream is stored with the entry in the stream.

[0220] The payment processing resource 106 then generates an identifier for the entry added to each of the event streams. This is step S520. As with other examples, the identifier may be alphanumeric or may be a number generated based on a hash of the payment instruction metadata. For example, if the hash of the payment instruction metadata is generated by a SHA256 cipher, the identifier may be generated by applying a further SHA256 cipher to the hash of the payment instruction metadata. That is, the identifier may be a hash of the hash of the payment instruction metadata.

[0221] The payment processing resource 106 then stores the identifier along with a copy of the payment instruction metadata in the payment data store 124. This allows for verification of the payment between Alice and Bob, upon request.

[0222] 6a and 6b, an exemplary scenario is described below in which Alice uses the payment processing resource 106 to send a payment to Bob. The payment may be for an amount of gold. An amount of gold is an example of an asset, the transfer of which and the payment of which are recorded in the manner described below.

[0223] In step S600, Alice contacts Bob and informs him that Alice would like to obtain 1g of gold in exchange for 49.20GBP. In step S602, Bob informs Alice of the price, i.e., 49.20GBP. Both Alice and Bob have registered accounts with a gold issuer, such as, for example, the Royal Mint in the United Kingdom, with an address at Ynysmaerdy, Pontyclun CF72 8YT (royalmint.com). This allows Alice and Bob to buy and sell gold in a legal and recordable manner, as described below.

[0224] Then, Alice, using the first computing device 102, indicates to the payment processing resource 106 her agreement with Bob to pay 49.20 GBP for 1 g of gold. The first computing device 102 accesses the API 108 to initiate the payment process using the account created by Alice according to steps S200 to S214. The gold is identified by the first computing device 102 when it accesses the API 108 to initiate the payment process. This allows the payment processing resource 106 to identify the transfer as relating to gold. The gold may be identified using an alphanumeric identifier, by a numeric code, or by any other suitable identifier. This is step S606. The request from the device 102 to the API 108 indicates the amount Alice wants to pay Bob. The request from the device 102 further indicates the account from which Alice wants to pay, the currency in which Alice wants to pay, and the person to whom Alice wants to pay, i.e. Bob. The amount Alice wants to pay Bob, Bob's identity, the identity of the account Alice wants to pay from, and the currency in which Alice wants to make the payment form a set of payment metadata that is sent to the payment processing resource 106 in step S608.

[0225] That is, to the payment processing resource 106, the asset is identified as being GBP and the bank is also identified.

[0226] Upon receiving the payment metadata from Alice, the payment processing resource 106 retrieves metadata from Bob's account based on the metadata provided by Alice in step S608. This is step S610. The payment processing resource 106 retrieves from Bob's account the currency with which Bob's account is associated, i.e., Pound Sterling (GBP), and the account of the issuer of gold, i.e., The Royal Mint.

[0227] The payment processing resource 106 then generates a payment instruction data set in step S612 using the payment metadata received from Alice and the information retrieved from Bob's account.

[0228] In this example, the provider of Bob's bank account is "HSBC" (i.e., the same as Alice's), the currency is specified as GBP, the amount of the payment (i.e., the amount being received by Bob) is 49.20 GBP, and the account identity is <bob:hsbc>where the user is identified as Bob by the "kyc" value and the actor is identified as the beneficiary of the payment, i.e. the individual receiving the payment. This forms a further part of the payment instructions dataset. The payment instructions dataset may optionally be further appended with a signature<Bob_sig> It may also contain a version of the terms and conditions signed by Bob using

[0229] A further part of the payment instruction dataset is formed by the details of the gold transaction. The payment processing resource 106 requests access to the issuer of Bob's gold account, i.e. Bob's gold account at the Royal Mint. The payment processing resource 106 is given a request for Bob's signature to enable access to be granted. The payment processing resource 106 may then either retrieve Bob's cryptographic signature from the user profile corresponding to Bob, or by a separate request to Bob for the signature corresponding to Bob's gold account. The signature may be the same as or different from Bob's signature on his "HSBC" account. Bob's signature may be required especially for large amounts of gold or gold-related business transactions, which may include a set of terms and conditions and the need for attestation by Alice or Bob against those terms and conditions.

[0230] Another part of the payment instructions dataset is formed by Alice's details: the provider of her account is "hsbc.com", the currency is specified as GBP, the amount of the payment being sent to Bob is 49.20GBP (i.e. a debit of 49.20GBP from Alice to be paid to Bob, and therefore represented in the payment instructions dataset as -49.20), and the account identity is <alice:hsbc>where the user is identified as Alice by the "kyc" value, and the terms and conditions signed by Alice are identified by the signed document and a hash of said document provided at a URL provided by Alice. The actor is identified as the sender of the payment, i.e. the individual making the payment.

[0231] The payment processing resource 106 also requests access to the issuer, i.e., Alice's gold account at the Royal Mint. The payment processing resource 106 is given a request for Alice's signature to enable access to be granted.

[0232] A message is then sent to the first computing device 102 in step S614 with a request for Alice's signature on the payment instruction data set. Alice then provides her cryptographic signature in step S516 to authorize the payment of 49.20 GBP to Bob. The signature is then applied to the payment instruction data set by the payment processing resource 120. The signature corresponding to Alice's gold account may be a different signature than the signature for Alice's account at "hsbc.com". If the signatures are different, Alice provides both signatures in step S616. The payment processing resource 106 may alternatively have already had access to the signature for Alice's gold account. That is, if the payment processing resource 106 is trusted by Alice, retrieving the signature from Alice is optional.

[0233] The payment processing resource 106 then generates further metadata corresponding to the transfer of money from Bob's gold account to Alice's gold account, the metadata detailing the payment from Alice to Bob and the transfer from one gold account to the other.

[0234] The payment processing resource 106 then applies the payment protocol criteria to the payment instruction data set in step S618. The payment processing resource 106 accesses the payment protocol module 120 in step S620.

[0235] The payment protocol module 120 first checks that the payment instruction dataset adheres to the zero-sum rule in terms of matching amounts, i.e., the amount being debited from Alice's account is equal to the amount being paid to Bob's account. This is step S622. The zero-sum rule is adhered to because 49.20 GBP is being debited from Alice's account and 49.20 GBP is being paid to Bob's account. The discrepancy in amounts may be due to, for example, different currencies. That is, the payment protocol module 120 determines that the asset identification information and the bank identification information match (because, according to the template above, Alice_HSBC:GBP balances Bob_HSBC:GBP and Alice_MINT:GOLD balances Bob_MINT:GOLD).

[0236] Alternatively or additionally, if Bob only has a GBP account with HSBC and Alice only has a EUR account with Revolut, there may be a mismatch, i.e., different asset identities and different asset registries (i.e., a payment to Bob_HSBC:GBP cannot be made from Alice_REVOLUT:EUR). The payment protocol module 120 then generates further metadata corresponding to the intermediary portion of the transaction. This metadata corresponds to the role that a financial broker (here listed as a first broker) plays in the transaction to resolve the currency and bank mismatch, similar to that described above in the example where the currencies and banks are different, which causes the asset identities and banks to be mismatched. In this example, the broker has a GBP account with HSBC and a EUR account with Revolut. The payment protocol module 120 accesses the cryptographic signatures corresponding to those two accounts. The metadata details the transfer of an agreed amount of gold from Bob's gold account to Alice's gold account, a payment of EUR from Alice's EUR Revolut account (i.e., Alice_REVOLUT:EUR) to the broker's Revolut EUR account (i.e., Broker_Revolut:EUR), and a corresponding amount of GBP payment from the broker's GBP account (i.e., Broker_Revolut:GBP) to Bob (Bob_HSBC:GBP), to balance the identities of the banks and the types of assets. This further metadata is also signed with the cryptographic signatures corresponding to those accounts.

[0237] Optionally or additionally, if the first broker only provided EUR to GBP conversion within a Revolut account only, i.e. not between different banks, the payment protocol module 120 needs to generate further metadata corresponding to the role played by the second broker in addition to the first broker. This metadata details the transfer of an agreed amount of gold from Bob's gold account (Bob_MINT:GOLD) to Alice's gold account (Alice_MINT:GOLD), a payment from Alice's EUR account (Alice_REVOLUT:GOLD) to an EUR account held by a first broker (i.e., the Revolut EUR account identified as Broker1_REVOLUT:EUR), a payment from the first broker's GBP account (i.e., the Revolut GBP account identified as Broker1_REVOLUT:GBP) to a second broker's HSBC GBP account (Broker2_HSBC:GBP), and a payment from the second broker's GBP account (Broker2_HSBC:GBP) to Bob's HSBC GBP account (Bob_HSBC:GBP). That is, the payment protocol module 120 may be used to construct a set of metadata to address inconsistencies (or lack of correspondence) between aspects of the payment instruction metadata checked in step S622.

[0238] Then, the payment protocol module 120 checks that the amount being transferred from Alice to Bob does not put Alice's balance below some minimum value. This is step S624. That is, is Alice spending too much money on the money she is getting from Bob? If Alice is spending too much money, i.e., if her balance would be below the minimum value, the payment protocol module 120 issues an error message to Alice informing her that she cannot spend the money she wants to spend. Moreover, the minimum value can become negative if a credit line is used. The payment protocol module 120 returns to step S520 until it is instructed to start again, i.e., when Alice deposits more funds into her account or when Alice's minimum balance is changed.

[0239] Next, the payment protocol module 120 checks whether the data related to the payment matches between the two parties of the transaction by checking the fields in the data corresponding to the issuer. This is step S626. The data matches between the two parties because the parties providing the accounts are the same and the asset identification information is the same or the lack of a match has been resolved by the payment protocol module 120 introducing further metadata corresponding to the role that a broker can play in resolving discrepancies in transfers of assets where the asset identifiers or asset registries do not match. When the transfer concerns gold, the amount of gold being transferred from Bob to Alice must complement the amount of gold being added to Alice's account.

[0240] That is, there is a requirement that there must be a match between the bank and asset identifiers specified on both sides of the transfer for the transfer to be possible. There is also a requirement that the zero-sum rule be met with respect to both GBP and gold.

[0241] The payment processing module 120 verifies the cryptographic signatures of Alice and Bob by generating a hash of each signature and comparing the hash to those stored in the records generated in steps S200 to S214. This is step S628. This also verifies the identity of Alice and Bob. Alternatively or additionally, standard PKI techniques based on private / public cryptographic key pairs may also be used to verify each signature. These techniques may also be used to verify the identity of the client. The payment processing module 120 also verifies the signatures of Alice and Bob's gold accounts using similar techniques. The payment processing module 120 also performs a check on Bob's account to determine that the required amount of gold is recorded in Bob's name and therefore can be transferred from Bob to Alice. If a broker was also used, the cryptographic signature corresponding to the intermediary account is also verified.

[0242] Satisfaction of steps S622, S624, S626, and S628 means that the criteria prescribed by the payment protocol have been met, and thus the payment processing resource 106 enables the payment of 49.20 GBP from Alice to Bob in accordance with the payment instruction dataset, and also the transfer of gold may be recorded by the issuer of the gold account.

[0243] Next, the payment processing resource 106 retrieves blockchain transactions from the blockchain 112 for each of Alice and Bob in step S630. Alice's blockchain transaction 802 includes a dust output (Tx0, Alice) and Bob's blockchain transaction 804 includes a dust output (Tx0, Bob). The dust output may be retrieved from the dust chain corresponding to the event streams related to Alice and Bob. The payment processing resource 106 also retrieves blockchain transactions for both gold accounts involved in the payment, i.e., Royal Mint - Alice and Royal Mint - Bob. Royal Mint - Bob's retrieved blockchain transaction 808 includes a dust output (Tx0, RYB) and Royal Mint - Alice's retrieved blockchain transaction 810 includes a dust output (Tx0, RYA). If brokers are also involved, blockchain transactions may also be retrieved from the blockchain 112 for each of the brokers. Dust outputs (Tx0, RYB) and (Tx0, RYA) may be taken from the Dust chain corresponding to the event streams associated with Alice and Bob’s gold accounts.

[0244] Creating rendezvous transactions with additional issuers The payment processing resource 106 then generates a new rendezvous blockchain transaction 806 that includes dust inputs for each of Alice and Bob that use the respective dust outputs from the blockchain transaction retrieved in step S530. This is shown in Figure 7. The rendezvous blockchain transaction 806 further includes dust inputs that use the corresponding outputs retrieved from blockchain transactions 808 and 810, i.e., for Alice and Bob's gold accounts.

[0245] Each retrieved blockchain transaction may also include an OP_RETURN script, i.e. a data carrier associated with a provably unusable output.

[0246] The dust input using Alice's dust output is denoted as Tx1, Alice, and the dust input using Bob's dust output is denoted as Tx1, Bob. The new rendezvous transaction also includes dust inputs corresponding to the gold accounts held by Alice and Bob, denoted as (Tx1, RYA) and (Tx1, RYB), respectively. A rendezvous blockchain transaction 806 is generated in step S632.

[0247] Funds to a rendezvous blockchain transaction 806 are added by and paid back to the payment processing resource 106. This may be minus any miner's fees after the rendezvous transaction 806 is validated if the rendezvous transaction 806 is sent to the blockchain 112 for validation.

[0248] The rendezvous blockchain transaction 806 includes further dust outputs using Tx1, Alice and Tx1, Bob, respectively. The rendezvous blockchain transaction 806 also includes dust outputs corresponding to the dust inputs retrieved from the blockchain for the two gold accounts. As it is a rendezvous transaction, the indices of the input / output pairs corresponding to Alice, Bob, and the two gold accounts, respectively, are identical in that, for example, the input index of Tx1, Alice may be assigned as number 1, and the output index of the corresponding dust output is assigned as output index number 1.

[0249] The payment processing resource 106 also adds provably unspendable outputs to the blockchain transaction 806 for Alice, Bob, and the two gold accounts, which are denoted as data carriers 812a, 812b, 812c, and 812d, respectively.

[0250] Provably unusable outputs corresponding to the brokers involved in the transaction may also be added, where those provably unusable outputs correspond to the data carriers of the brokers.

[0251] As with other examples, each of the data carriers may hold a different dataDigest and / or streamDigest. The streamDigest may be salted, as with other examples.

[0252] Additionally, blockchain transactions 806 may be generated using dust that has not already been used as the basis for an event stream, and this "new dust" is used in combination with the HD Key Chain, as described in UK Patent Application No. 2102217.3, to generate blockchain transactions 806, among other examples.

[0253] As with the other examples, the data payload (i.e., the hash of the payment instruction metadata) held in the respective data carrier is held in an unusable OP_RETURN output of the transaction, meaning that the data payload may subsequently be stored in the blockchain as an unusable output. As with the first example, holding the data payload (i.e., the hash of the payment instruction metadata) held in the respective data carrier is held in an unusable OP_RETURN output of the transaction, meaning that the data payload may subsequently be stored in the blockchain as an unusable output.

[0254] The data in the data carriers includes a hash of the payment instruction dataset generated by the payment processing resource in steps S600 to S628. The data in the data carriers may be identical in that it is based on the same payment instruction dataset. Alternatively or additionally, the respective hash of each data carrier may be different since the data is different. For example, Alice's data is different from Bob's data since it relates to activity in Alice's account and not Bob's account. This is step S634. The provably unspendable output allows the rendezvous transaction 806 to carry the hash of the payment instruction dataset in the transaction and allows the hash to be stored on the blockchain. This means that the payment instruction dataset, and thus the record of the payment, is stored on the blockchain. This means that the record of the payment benefits from the immutability of the blockchain. In the case of a transfer of gold, this means that the blockchain can be used to support the record of the transaction from one gold account to another gold account. Also, the anonymity provided by the blockchain and the system described herein means that the confidentiality of the transfer of gold can be maintained.

[0255] The blockchain transaction 806 may then be checked to see if the transaction and the correspondence of the users with the corresponding gold accounts owned by Alice and Bob are correct. This is step S636.

[0256] The payment processing resource 106, in step S638, issues a notification to the event stream resource 110 confirming that the blockchain transaction 806 can be used as the basis for adding data to the event stream, i.e., the event stream relating to Alice, Bob, and the two gold accounts.

[0257] The payment processing resource 106 synchronizes the payment with the event streams E-Alice, E-Bob, E-RYA (i.e., Alice's gold account), and E-RYB (i.e., Bob's gold account) by adding an entry to each of those event streams containing a hash of the payment instruction metadata contained in the respective data carrier of the blockchain transaction 806 using the rendezvous transaction 806. That is, a hash corresponding to data output 812a may be added to E-Alice, and a hash corresponding to data output 812b may be added to E-Bob. This is step S640. This is shown diagrammatically in FIG. 8. Entries may also be added to the event streams corresponding to the brokers involved in the transfer of gold.

[0258] The payment processing resource 106 then generates an identifier for the entry added to each of the event streams. This is step S642. The identifier may be alphanumeric, or may be a number generated based on a hash of the payment instruction metadata. For example, if the hash of the payment instruction metadata is generated by a SHA256 cipher, the identifier may be generated by applying a further SHA256 cipher to the hash of the payment instruction metadata. That is, the identifier may be a hash of the hash of the payment instruction metadata.

[0259] The payment processing resource 106 then stores the identifier in the payment data store 124 along with a copy of the payment instruction metadata.

[0260] Alternatively or additionally, the payment processing resource 106 may utilise the principle of chain of commitment to record transactions. The principle of chain of commitment is fully described in UK patent application no. 2204293.1 (filed 25 March 2022), but its application to recording asset transfer events is described below.

[0261] The application of a chain of commitments to recording transactions provides the unforkable benefits associated with the dust chain approach described above, but with further advantages, including links between transactions that are invisible on the chain because they are contained in a data payload that, in short, contains hashed data from previous and future transactions, as explained below, meaning that data from previous and future transactions cannot be distinguished by an observer.

[0262] Above we have described four examples of different complexity where rendezvous transactions are used to synchronize event streams corresponding to multiple parties involved in an asset transfer event by synchronizing chains of dust. As an alternative, we propose to use a chain of commitments to record asset transfer events. For the sake of brevity, we choose only the fourth of the described examples to illustrate it in the context of a chain of commitments, but this should in no way be taken as limiting only to the fourth example.

[0263] First, let us briefly illustrate the concept of a chain of commitments using Fig. 8a, with reference to the event streams shown in Fig. 8. The event stream corresponding to each chain of commitments is off-chain, i.e., outside the blockchain, and represents a way to store data off-chain (immutably).

[0264] The system 1400 includes an off-chain (i.e., not on the blockchain) data storage system 1404 that stores a number of log entries 1406a-d. The log entries 1406a-d may correspond to entries of an event stream initialized by the event stream manager 110.

[0265] The system 1400 of FIG. 8a may be used as part of an event stream-based system for logging events (such as asset transfer events) that map events to blockchain transactions.

[0266] Each event 1406a-d in the off-chain data storage 1404 is mapped to a blockchain transaction 1408a-d, and the sequence of blockchain transactions is ordered and linked using a chain of commitments. A chain of commitments can be viewed as a set of transactions that contain information such that they may be related to one another and / or traversable. In the example discussed below in connection with rendezvous transaction 1000, the chain of commitments is a set of transactions linked by data digests and state digests that are generated based on payment instruction metadata corresponding to the asset transfer event being recorded.

[0267] As described below, a set of transactions is constructed as a "chain" in that each transaction contains a reference to a previous transaction and a reference to a next transaction (or contains data based on those references). As described in the example below with reference to rendezvous transaction 1000, the payload of the output of a rendezvous transaction is based on references to the previous and next transactions.

[0268] Each transaction includes "funding in" inputs 1410a-d that pay for the transaction to be mined onto the blockchain. Each transaction may also include a data payload 1412a-d that may be held in an unspendable output of the respective transaction. The data payloads 1412a-d may be prepended with an OP_RETURN opcode, which is a script opcode that may be used to write arbitrary data onto the blockchain and also to mark a transaction output as invalid (i.e., unspendable), which causes the data held in the payload to be immutably recorded on the blockchain when the respective transaction is recorded on the blockchain.

[0269] The "data and references" shown in Figure 8a refer to the state digest and data digest included in the output. In the example described below with reference to rendezvous transaction 1000, these are based on the payment instruction data set recorded in the corresponding event stream entry.

[0270] Briefly, refer to the fourth example above where Alice sends a payment to Bob for an amount of gold. A complication arises due to the existence of a Royal Mint account which also requires a signature. In the example, we illustrate that an asset transfer event (the transfer of gold from one Royal Mint account to another Royal Mint account) is recorded in four separate event streams, each corresponding to a chain of dust. An alternative approach would be to record the transfer of gold on the four chains of commitments, using a rendezvous transaction to atomically synchronize the four chains of commitments.

[0271] Hereafter, with reference to FIG. 9, it will be described how a chain of commitments can be used to immutably record the transfer of gold from Alice to Bob, i.e., the asset transfer event shown in the fourth example above. The payment processing resource 106 is configured to utilize the commitment management module 160. The commitment management module 160 is configured to interact with the payment processing resource 106 and the event stream management module 110 using any suitable means. Each of Alice and Bob and their respective Royal Mint gold accounts have a corresponding chain of commitments initialized with the commitment management module 160 in step S900. Initialization of the chain of commitments may include setting up hardware resources that may be allocated to the chain of commitments. The chain of commitments may already be initialized or may be initialized in response to a request to the commitment management module 160. Step S900 may include accessing the event stream management module 110 to access an event stream corresponding to the participants of the asset transfer event.

[0272] The payment processing resource 106 is configured to determine the association between the chain of commitments and the respective entities (in this example, Alice and Bob and their gold accounts). In determining the association, the payment processing resource 106 identifies an entry in the user profile indicating that the chain of commitments has been initialized and provides an identifier that the commitment management module 160 can use to identify the correct chain of commitments. The initialization of the chain of commitments may have occurred before step S600, where Alice contacts Bob and informs him that Alice wants to obtain 1g of gold in exchange for 49.20GBP. The initialization of the chain of commitments may have occurred during the execution of any of steps S600 to S642 by a suitable request to the commitment management module 160. The initialization of the chain of commitments may occur after the positive completion of step S628, i.e. when the payment protocol criteria are met. After this step, i.e. step S628, step S900 may be initiated as an alternative to steps S630 to S642.

[0273] Each chain of commitments corresponds to an event stream managed by the event stream management module 110, corresponding to a respective participant. However, for the avoidance of doubt, the chain of commitments must indeed correspond exactly to the corresponding event stream, in that the event stream may carry more information in each entry than is stored in the corresponding payload of the chain of commitments. In step S902, it is determined that the criteria determined by the payment protocol are met, i.e., steps S622, S624, S626, and S628 (as shown in FIG. 6a) are met, and the transfer of money can take place and can be recorded as an asset transfer event. This may be by accessing a flag generated by the payment processing resource 106 indicating that the transfer of money needs to be recorded as an asset transfer event. Alternatively or additionally, steps S622, S624, S626, and S628 may be repeated if a predetermined amount of time has passed since the first flag generated by the payment processing resource was generated.

[0274] In step S904, the payment processing resource 106 provides a request to the commitment management module 160 with a request that the transfer of gold be recorded in the chain of commitments corresponding to Alice, Bob and each of their respective Royal Mint accounts. A flag generated by the payment processing resource 106 may be provided to the commitment management module 160 during performance of step S904.

[0275] The commitment management module 160 is configured to generate a rendezvous transaction 1000 that includes funding inputs (provided by the commitment management module 160) for each of Alice, Bob, and the Royal Mint accounts corresponding to both Alice and Bob. This is step S906. The rendezvous transaction is described with reference to Figure 10. The described rendezvous transaction synchronizes event streams corresponding to chains of commitments initialized for the parties involved in the transfer of gold. This differs from other example rendezvous transactions that synchronize event streams linked to chains of dust.

[0276] The rendezvous transaction 1000 shown in Figure 10 includes outputs for each of the accounts Alice, Bob, and The Royal Mint. Each output is generated as a data digest H Dni and the state digest S ni The subscript i refers to the party number involved in the asset transfer event. Subscript 1 corresponds to Alice's HSBC account. Subscript 2 corresponds to Bob's HSBC account. Subscript 3 corresponds to Alice's Royal Mint account. Subscript 4 corresponds to Bob's Royal Mint account. The outputs are listed as 1004, 1006, 1008, and 1010.

[0277] Each data digest and state digest is in the transaction's data payload that is preserved in the unspendable output of the transaction in that it is prepended with an OP_RETURN opcode, which is a script opcode that can be used to write arbitrary data to the blockchain and also to mark the output of a transaction as invalid, i.e., unspendable. Thus, the corresponding data is immutably recorded in the blockchain.

[0278] As seen in FIG. 10, each output of the rendezvous transaction 1000 is based on a reference to a corresponding previous blockchain transaction (i.e., it may be a previous transaction in the respective chain of commitments) through the use of the state digest of the corresponding link in the chain of commitments. The previous blockchain transaction may be a rendezvous transaction or a non-rendezvous transaction. As shown in FIG. 10, those transactions are 1012 (corresponding to Alice's HSBC account, i.e., Alice_HSBC:GBP), 1014 (corresponding to Bob's HSBC account, i.e., Bob_HSBC:GBP), 1016 (corresponding to Alice's gold account, i.e., Alice_MINT:GOLD), and 1018 (corresponding to Bob's gold account, i.e., Bob_MINT:GOLD). Also, the output of each rendezvous transaction is based on a reference to its corresponding next transaction (which may also be a rendezvous transaction) using a reference of the funding input of the next transaction's reference. As shown in FIG. 10, the transactions are 1020 (corresponding to Alice's HSBC account), 1022 (corresponding to Bob's HSBC account), 1024 (corresponding to Alice's gold account), and 1026 (corresponding to Bob's gold account). The relationship between the output of rendezvous transaction 1000 and the next transaction will become clear below when the generation of data digests and state digests is described. The inputs to each of the transactions and rendezvous transaction 1000 may be provided by the platform. If the inputs provided by transactions 1012, 1014, 1016, and 1018 do not provide sufficient funds, further inputs may be provided. The inputs correspond to commitment funds N-1, N, and N+1.

[0279] To generate the data digest and state digest, commitment management module 160 retrieves the payment instruction data set generated in steps S600 through S628. This is step S908. As described below, the payment instruction data set is then used to determine the data digest and state digest.

[0280] The data digest is generated in step S910 by ni The payment instruction data set is derived using the formula: H Dni := H 2 (H 2 (Di)||H 2 (SALT) In the formula, || is the concatenation of the elements before and after it, and H 2 is a double hash function, although a one-time hash function (H) could also be used. Di is the payment instruction dataset of the corresponding party, i.e., if i = 1, then the party is Alice, and so on. The payment instruction dataset may be the same for all parties, or it may be different for each party.

[0281] Hash is provided herein as the primary example of a one-way function. Those skilled in the art will appreciate that other one-way functions may be used. "Hash" as used throughout this specification means hashing at least once, and may include several applications of each hash application. Hashing more than once provides resistance to stretching attacks. Instead of hashing twice (or more), a different hash function or method is used that is not vulnerable to stretching attacks. For example, SHA-3 and / or HMAC (optionally using the same salt or a different salt as the key) provide such functionality. A further alternative is to generate a Merkle tree with leaf items {payment instruction dataset, salt}, and the data digest is the root of the Merkle tree.

[0282] Salting a hash means using a "salt", which is any arbitrary piece of data, as part of the input to the hash function (along with the payment instruction data set being hashed). The salt may be concatenated with the other inputs to the hash function. Optionally, the salt is random.

[0283] A different salt may be selected for each data item being hashed, i.e., each event in the event stream, or in this example, a different salt may be used for each of Alice, Bob, and their respective gold accounts.

[0284] Data Digest (H D ) can be considered a unique fingerprint of that payment instruction dataset (which in the primary example was sent to the event stream). By storing the data digest (relative to the payment instruction dataset itself), clients using this system can store a proof of existence of a payment instruction dataset of known and consistent size (regardless of the size of the client data) on the blockchain without disclosing the contents of the payment instruction dataset.

[0285] A state digest is then derived in step S912 as the root of a Merkle tree as shown in Figure 11, and the leaves of the Merkle tree are based on the previous transaction reference, the next transaction reference, and the client data. Alternatively or additionally, the state digest may be derived based on a JSON object and a salted path.

[0286] In particular, the Merkle tree contains a previous transaction reference, a next transaction reference, and a state client data digest (H D The state client data digest is based on the data digest (H D ), and optionally, any metadata associated with the events and / or event stream. State client data digests are described in more detail below.

[0287] The state digest (S) (ignoring the subscripts ni for convenience only) is calculated according to the following formula (reference to the exemplary previous transaction, state client data digest (H D ') (again, merely for convenience, ignoring the subscript ni), and a reference to the next transaction).

[0288]

number

[0289] where the “Merklize” function generates a Merkle root from an ordered set of data elements as leaves,

[0290]

number

[0291] is an ordered set of leaves based on the elements. The Merklize function may also take additional input parameters corresponding to other data that may be used in the computation of S, including secrets to prevent a malicious third party from forking the stream if the recovery protocol is invoked. Each of the leaves is first double-hashed in the Merklize function. Notably, due to how hashing and Merkle trees work, the order of the set of inputs to it matters, and therefore the order of the inputs must be the same whenever a Merkle tree is created, recreated, or verified, so that the same tree (and therefore the same state digest) is produced for the same input data.

[0292] Optionally, the state digest is based on a version number. If a version number is specified for the call to the Merklize function as described below, then each leaf node is based on a version number. The preimage of each leaf node may be prepended with a version number. Alternatively, the preimage of each leaf node may be postpended with a version number. Advantageously, the use of version numbers allows the state digest to be tied to a specific version (as different version numbers will result in different Merkle tree roots even if the same input data is used). The use of changing version numbers may be used in concert with any changes to the specification of how the Merkle tree is constructed (e.g., new and / or different leaf nodes). Each version number may be tied to a unique specification of the Merkle tree that is generated.

[0293] The Merklize function optionally takes a version number (v) as an additional argument according to the following formula:

[0294]

number

[0295] The Merklize function can be written as follows:

[0296]

number

[0297] 1. If v == null: 1.1.

[0298]

number

[0299] Generate a Merkle tree T as 1.2. Root R of a tree T T Get the. R T Return 2. Else: 2.1. Update each leaf in the leaf list by prepending a version number: 2.1.1. PREV ← v||PREV 2.1.2.

[0300]

number

[0301] 2.1.3. NEXT ← v||NEXT 2.2. Create a Merkle tree T with the updated set of leaves:

[0302]

number

[0303] 2.3. Root R of a Tree T T Get the. R T Return

[0304] The Merklize function may take additional inputs in addition to those mentioned above.

[0305] The function GenMerkleTree may be understood to mean a standard method for generating a Merkle tree given a set of leaf data items. The first step of GenMerkleTree is to find the set of leaves (in this example

[0306]

number

[0307] ) items.

[0308] Referring to FIG. 11, an exemplary generated Merkle tree 1100 includes leaf nodes PREV 1102, H D ' 1104, and NEXT 1106. The root 1108 of the Merkle tree is the state digest (S) used for each of the outputs of the rendezvous transaction 1000. This exemplary Merkle tree is constructed as a binary tree with each node (except for the leaves) having two children. Because there are an odd number of input data items (and therefore an odd number of leaves), the last unpaired leaf node (i.e., the furthest "NEXT") is doubled. Those skilled in the art will appreciate that this presented form of the Merkle tree need not be strictly followed, and that there are other forms that may function similarly. As discussed above, each item in the input set is hashed twice (1110), and each twice-hashed item is used as a leaf of the Merkle tree.

[0309] As an alternative to the Merkle tree structure shown in Figure 11, the state digest can be generated by hashing a pre-image, which is constructed by concatenating the objects on which the state data is based. Thus, in an example where the state digest is based on a reference to the previous transaction, a state client data digest, and a reference to the next transaction, the formula becomes:

[0310]

number

[0311] Optionally, a salt may also be incorporated into the preimage. For example, the salt may be concatenated to the beginning or end of the preimage.

[0312] As a further alternative to the root of a Merkle tree, the state digest can be generated by using a hash chain or a canonical JSON structure. A hash chain is constructed such that each intermediate hash result is prepended with the item on which the state digest is based. For example, a state digest can be generated by adding a reference to the previous transaction, a client data digest (H D '), and based on a reference to the next transaction, the expression is

[0313]

number

[0314] Optionally, a salt is incorporated into the hash chain. Optionally, the salt is incorporated by prepending the salt to each intermediate preimage.

[0315] PREV is a reference to a previous transaction and may be state data for the previous transaction being referenced. n1 is the previous transaction from the chain of commitments corresponding to Alice, transaction 1012, which is a component of S n1-1 Based on S n2 Similarly, S n2-1 and so on. That is, a reference to a previous transaction is the state data of the previous transaction being referenced as that transaction is recorded in the blockchain. A reference to a previous transaction is optionally called a reference to a parent transaction, of which the current transaction is a child.

[0316] If there is no previous transaction referenced (i.e., it is the first transaction in the commitment chain), the previous transaction reference may be considered a null reference, which may be a string of zeros. The size of the string of zeros may be the same size as the size of the previous transaction reference if it were not null. The string may be 32 bytes long. The table below illustrates an example of PREV:

[0317] [Table 1]

[0318] Optionally or alternatively, the pre-image of PREV may be and / or be represented using a JSON structure, which includes the data options described above. Advantageously, the use of JSON objects provides the capability, because if more data elements were to be added, they may be easily added and referenced.

[0319] NEXT is a reference to the next transaction. Advantageously, many of the components of the next transaction are unknown (as a result of the future existence of the next transaction and the data sent by the client) and therefore the unknown components cannot be used as a reference, but the input UTXO or UTXOs used to fund the transaction can be pre-determined and are unique only to that transaction, i.e., the "NEXT" transaction, when the transaction is committed to the blockchain. The input UTXO may be referenced by an outpoint, which includes the transaction ID of the transaction to which the UTXO belongs (called TxID) and the index of the output on the referenced transaction (called vout). The next transaction reference is optionally called a child transaction reference, with the current transaction being the parent.

[0320] Similar to a previous transaction reference, a next transaction reference may be considered a null reference if there is no next transaction referenced (i.e., the current transaction is the last in the commitment chain). A null reference may be a string of zeros that may be the same size as the size of the next transaction reference (i.e., the size of the transaction outpoint) if it was not null. The string may be 32 bytes long. The table below describes NEXT:

[0321] [Table 2]

[0322] Optionally or alternatively, the preimage of NEXT may be and / or be represented as a JSON structure, including the data options described above. Advantageously, the use of JSON objects provides the capability because if more data elements were to be added, they may be easily added and referenced.

[0323] The table below shows the state client data digest (H D ') is based on.

[0324] [Table 3]

[0325] If there are several metadata elements, they are listed as M1, M2, etc. This is shown by the Merkle tree in Figure 12.

[0326] Exemplary metadata elements may include any one or more of the following: whenRecorded -- the time when the payment instruction metadata was received from the client and / or stored in an off-chain log; appVersion – the version number of the chain of commitments, seed – the seed value used at the beginning of the event stream generation, delWriteIV -- the initial value used to generate a delegated authorisation token for writing to the event stream; delWriteH0 -- the final hash value used to validate the delegated authorization token for writing to the event stream; timeAC -- the start and / or end time when the event stream is considered open for writing, delAuthIndex -- the index of the delegated token that the client used to send the event, TxIDcreate -- the transaction ID of the first transaction in the chain of commitments, and / or index -- the index of the current event in the event stream (not necessarily the same as the index in the chain of commitments, since not all events need to be recorded in the chain of commitments). nextHashSalt -- hash of the salt to be used for the next event. A salt may be pre-generated for the next event in the chain of commitments, and this salt is hashed and used to generate the state-client-data-digest Merkle tree. Those skilled in the art will appreciate that other metadata elements may also be used.

[0327] Referring to FIG. 12, the root is the state client data digest (H D An exemplary Merkle tree 1200 is shown, which is a 1104 .

[0328] The set of leaf nodes 1206, 1208, 1210, 1212, and 1214 is the data digest (H D ) and metadata leaf nodes are interleaved with the salt. This interleaving increases the security of the data in the Merkle tree by making it prohibitively expensive for a third party to brute force the Merkle tree. If a third party were to obtain a protocol description of the chain of commitments, H D (data digest) may be publicly stored on the transaction, a third party may then m Given that the values ​​of H are often predictable or can be easily enumerated (e.g., if one of the metadata elements is a timestamp, this may be guessable given the time the transaction was sent to the blockchain, or if one of the metadata elements is a monotonically increasing index, this may be guessable from a previous state), it is possible to brute force these metadata values. A third party could brute force these values ​​and obtain a value H D ' (i.e., the root of the tree) can be correctly reconstructed, then the third party can obtain the metadata values ​​M1, ..., M m In some cases, these metadata may be sensitive, for example the whenRecorded or writeAccessControl.region properties are used as metadata in an EventStream transaction and may be important to malicious third parties.

[0329] The preimage underlying a leaf node may be prepended with a protocol version number.

[0330] Thus, the process of creating the exemplary Merkle tree 1200 may be described as follows: DataDigestCommit(H D , SALT, M1, ..., M m , v): 1. Create m copies of SALT 2. {H D , SALT, M1, SALT, ..., M m , SALT} to order the data items. 3.

[0331]

number

[0332] Generate 4.

[0333]

number

[0334] Return

[0335] Notably, the same Merklize function is used here as in the creation of the state digest discussed above. Since the same Merklize function is used, the preimage of the leaf node is also hashed, optionally, twice. The Merklize function is H' D The input may receive other additional inputs corresponding to other parameters that may be used in the calculation of .

[0336] Similar to the discussion of generating Merkle trees above, there are several possible alternatives to Merkle trees, including concatenating the inputs and hashing the result, and generating a hash chain.

[0337] State Client Data Digest H D To generate the ', the protocol version number may be used (compared to the state digest (S) discussed above, which may give v = null). The state digest (S) is the sum of the state client data digest (H D '), so H D By making H' depend on the protocol version number (v), S also ends up depending on v (even though it is not directly used in its creation). Here, "depends" means that H D This means that S would be different if the same input were used to generate S', except for the different protocol version numbers used to generate S'. This allows S to depend on the protocol version number, as long as the protocol version number is not used twice to generate two Merkle trees.

[0338] In step S914, the rendezvous transaction 1000 is sent for inclusion in the blockchain. Then, in step S916, the event streams corresponding to Alice, Bob, and the gold accounts corresponding to Alice and Bob can be populated with the hash of the payment instruction data set by accessing the event stream management module 110 with a request that the hash of the payment instruction data set be added to the respective event streams. The state digest and the data digest may be included in the event stream entries, and additionally or alternatively, the hash of the state digest and / or the hash of the data digest may be included in the event stream entries. The rendezvous transaction 1000 then forms part of each of the chains of commitments corresponding to Alice, Bob, and the gold account in that it is linked to the corresponding event stream entries. The rendezvous transaction is then immutably and securely linked to the event stream entries, and the asset transfer event is immutably and securely recorded without disclosing the details.

[0339] That is, following a determination by the payment processing resource that the criteria for the asset transfer are met, the commitment management module 160 generates a rendezvous transaction 1000 that synchronizes the chain of commitments corresponding to Alice, Bob (i.e., their HSBC GBP account), and the two gold accounts corresponding to Alice and Bob. An output of the rendezvous transaction 1000 is generated and includes a payment instruction dataset, a state client data digest, and an element based on the state data digest. The rendezvous transaction 1000 can then be sent to the blockchain and linked to the chain of commitments corresponding to the parties.

[0340] Alternatively or additionally, there is an alternative form of rendezvous transaction 1300 that may be generated by commitment management module 160, as shown in Figure 13. Instead of different inputs and outputs for each chain of commitments as in rendezvous transaction 1000, a single transaction input 1302 and output 1304 may be used. Again, the inputs may be provided by commitment management module 160.

[0341] The output includes a data digest and a state digest that may be assembled based on a combination of the corresponding PREV and NEXT transactions. The combination may be accomplished by concatenation, addition, or any other method of combining related quantities. When the data digest and state digest are generated, the transaction 1300 may be sent for inclusion in the blockchain, and the rendezvous transaction 1300 may be linked (as rendezvous transaction 1000) to corresponding entries in the event stream corresponding to Alice, Bob, and the gold accounts corresponding to Alice and Bob.

[0342] It should be noted that the above-mentioned aspects and embodiments illustrate, rather than limit, the present disclosure, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure, as defined by the appended claims. In the claims, reference signs placed in parentheses shall not be construed as limiting the scope of the claims. The words "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or in the specification as a whole. In this specification, "comprise" means "includes or consists of" and "comprising" means "including or consisting of". The singular reference of an element does not exclude the plural reference of such element and vice versa. The present disclosure may be implemented by hardware comprising several different elements, and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. [Explanation of symbols]

[0343] 100 Systems 102 first computing device 102a Computer equipment 102b Computer equipment 103 Users, Entities, Parties, and Agents 103a User, Entity, First Party 103b User, entity, second party 104 Second Computing Device 105 Client Applications 106 Payment Processing Resources, Network, Bitcoin Network, Blockchain Network 108 Application Programming Interface (API) 110 Event Stream Resources, Event Stream Manager 110a Event Stream 112 Blockchain 120 Payment protocol module, payment processing module 122 Key Storage Module 124 Payment Data Store 126 nodes, Bitcoin nodes, blockchain nodes 130 Packet Switching Networks 132 Blockchain network, Bitcoin network, Peer-to-Peer (P2P) network, network 140 Database Management Systems (DBMS) 150 Blockchain, Bitcoin Blockchain 151, 151n, 151n-1 blocks 152, 152i, 152j Transactions 153 Genesis Block (Gb) An ordered set of 154 unpublished transactions 155 Block Pointer 160 Commitment Management Module 401 Protocol Engine 402 Blockchain Transactions 404 Blockchain Transactions 406 Rendezvous Blockchain Transactions 412, 412a, 412b Data carriers 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 502 Events 504 Blockchain Transactions 506 Edge 602 Blockchain Transactions 604 Blockchain Transactions 606 Rendezvous Blockchain Transactions 608 Blockchain Transactions 610 Blockchain Transactions 612 Data Carrier 702 Blockchain Transactions 704 Blockchain Transactions 706 Rendezvous Blockchain Transactions 708 Blockchain Transactions 710 Blockchain Transactions 712a, 712b, 712c, 712d Data Carriers 802 Blockchain Transactions 804 Blockchain Transactions 806 Rendezvous Blockchain Transactions 808 Blockchain Transactions 810 Blockchain Transactions 1000 Rendezvous Transactions 1004, 1006, 1008, 1010 Output 1012, 1014, 1016, 1018, 1020, 1022, 1024, 1026 transactions 1100 Merkle Tree 1102 Leaf Node PREV 1104 State client data digest, leaf node H D ' 1106 Leaf node NEXT 1108 Merkle Tree Root 1200 Merkle Tree 1206, 1208, 1210, 1212, 1214 Leaf nodes 1300 Rendezvous Transactions 1302 Transaction Entry 1304 Transaction Output 1400 System 1404 Off-chain (i.e., not on the blockchain) data storage system 1406a~d Log entries, events 1408a-d Blockchain transactions 1410a~d "Funding input" input 1412a~d Data payload< / alice:hsbc> < / bob:hsbc> < / alice:hsbc> < / bob:hsbc>

Claims

1. A method implemented by a computer for recording an asset transfer event including at least a first user and a second user, implemented by computing resources, receiving instruction data, wherein the instruction data is related to a requested asset transfer event, wherein the instruction data includes a first set of metadata related to a sender of an asset and a second set of metadata related to at least one recipient of the asset, wherein each of the sender and the recipient is respectively associated with an account related to an asset registry, associating the sender of the asset with a first chain of commitments and associating the recipient of the asset with a second chain of commitments, wherein each chain of commitments associates an event stream with a plurality of blockchain transactions, comparing the first set of metadata with the second set of metadata to determine whether the transfer of the asset from the sender to the at least one recipient can be performed according to a transfer protocol, wherein the transfer protocol defines at least one criterion that enables an asset transfer event to occur, determining one or more items of correspondence between the respective sets of metadata based on a comparison between the respective sets of metadata according to the transfer protocol, generating a rendezvous blockchain transaction including at least one input and at least one output for each of the sender and the recipient, wherein the at least one output includes data related to the first set of metadata and the second set of metadata, wherein the data related to the first set of metadata and the second set of metadata is based on data related to future blockchain transactions, appending the rendezvous blockchain transaction to the first chain of commitments and the second chain of commitments respectively, associating the rendezvous blockchain transaction with each entry of each event stream and including.

2. The method according to claim 1, wherein the rendezvous blockchain transaction is sent to a blockchain. **Claim 3** wherein the output corresponding to the sender includes a data payload including metadata generated based on the first set of metadata, and the output corresponding to the recipient includes a data payload including metadata generated based on the second set of metadata. The method according to claim 1. **Claim 4** The method according to claim 3, wherein the metadata includes a data digest and a state digest. **Claim 5** The method according to claim 4, wherein the data digest is generated based on hashes of the first set of metadata and the second set of metadata. **Claim 6** The method according to claim 5, wherein the data digest is generated based on a combination and sort of the first set of metadata and the second set of metadata. **Claim 7** The combination of the first set of metadata and the second set of metadata is obtaining a double hash of the combination of the first set of metadata and the second set of metadata, and concatenating the double hash of the combination of the first set of metadata and the second set of metadata with the double hash of the sort. The method according to claim 6, comprising. **Claim 8** The method according to claim 4, wherein the state digest is generated based on the data digest and future transactions. **Claim 9** The method according to claim 4, wherein the state digest is further generated based on previous transactions. **Claim 10** The method according to claim 4, wherein the state digest is the root of a Merkle tree. **Claim 11** The step of determining the one or more items of correspondence between the respective sets of metadata is i) the currency of the payment identified within each of the respective sets of metadata, ii) the amount of currency paid from the account corresponding to the sender and the amount of currency requested from the account corresponding to the recipient, and iii) the identifier of the asset registry associated with the sender's account and the recipient's account. The method according to claim 1, comprising determining a correspondence between at least one of. **Claim 12** The computing resources are Determine that the transfer cannot be made in accordance with the transfer protocol, The method of claim 1, further comprising generating a further set of metadata to resolve a lack of conformity with the transfer protocol. **Claim 13** The method of claim 12, wherein generating the further set of metadata includes generating metadata that enables conversion between a first currency and a second currency. **Claim 14** The method of claim 12, wherein generating the further set of metadata includes generating metadata for one asset registry to record the transfer of a given asset in another asset registry. **Claim 15** A system configured to implement the method according to any one of claims 1 to 14.

Images