Method and system for adding rendezvous blockchain transactions 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] This disclosure generally relates to methods and systems for implementing a platform for one or more services related to a distributed ledger, i.e., a blockchain, for one or more clients. In particular, this disclosure relates to providing access to a number of blockchain-related functions and applications for one or more clients, such as 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 their variations. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referenced herein for convenience and illustrative purposes, but this disclosure is not limited to the use of the Bitcoin blockchain, and alternative blockchain implementations and protocols relating to any kind of digital asset or representation of a digital asset fall within the scope of this disclosure. The terms “client,” “entity,” “node,” “user,” “sender,” “receiver,” “payer,” and “payee” may, in this specification, refer to computing or processor-based resources. 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, tokens representing at least part of an asset, smart contracts, licenses, i.e., software licenses, or DRM agreements for media content. It will be understood that throughout this specification, the term “digital asset” is used to describe a product that may be associated with value that may be transferred or offered as payment for a transaction from one entity to another.

[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 containing at least one input and at least one output, encoding the transfer of control of a digital asset among participants in the blockchain system. Each block contains a hash of the previous block, creating a chain to form a permanent and immutable record of all transactions written to the blockchain since its inception. A transaction contains a small program known as a script, embedded in the transaction's inputs and outputs, specifying how and by whom the transaction's output can be accessed. On 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, and invalid transactions are rejected from the network. Software clients installed on the nodes perform this validation work by executing lock and unlock scripts for 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. Therefore, for a transaction to be written to the blockchain, it must be i) validated by the first node receiving the transaction—if the transaction is validated, the node relays the transaction to other nodes in the network—ii) added to a new block built by a miner, and iii) mined, that is, added to the public ledger of past transactions.

[0005] It will be understood that the nature of the work performed by miners is determined by 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 understood that other consensus mechanisms such as Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Capacity (PoC), Proof of Elapsed Time (PoET), and Proof of Authority (PoA) may be used. Different consensus mechanisms differ in how mining is distributed among nodes, and the probability of successfully mining a block depends on, for example, the miner's hash power (PoW), the amount of cryptocurrency held by the miner (PoS), the amount of cryptocurrency entrusted to delegate miners (DPoS), the miner's ability to remember a given solution to a cryptographic puzzle (PoC), and the waiting time randomly assigned to the miners (PoET). Typically, miners are offered incentives or rewards for mining blocks. For example, the Bitcoin blockchain rewards miners with newly issued cryptocurrency (Bitcoin) and transaction fees associated with transactions within a block. In the case of the Bitcoin blockchain, the amount of cryptocurrency issued decreases over time, and the incentive eventually consists only of transaction fees. Therefore, it can be understood 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 described above, each transaction within a given block encodes the transfer of control of digital assets between participants in the blockchain system. Digital assets do not necessarily correspond to cryptocurrencies. For example, digital assets may relate to digital representations of documents, images, or physical objects. Payment of cryptocurrency and / or transaction fees to miners can simply act as an incentive to maintain the validity of the blockchain by performing the necessary work. The cryptocurrency associated with the blockchain may act as security for miners, while the blockchain itself may be a ledger of transactions related primarily to digital assets other than cryptocurrencies. In some cases, the transfer of cryptocurrency between participants may be handled by entities different from and / or unrelated to the entities that use the blockchain to maintain the transaction ledger.

[0007] Once stored on the blockchain as a UTXO, a user can transfer control of the associated resources to another address associated with the input of another transaction. This transfer is typically, but not always, carried out using a digital wallet. This 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. A digital wallet can be used to store public and private keys, track ownership of resources, tokens, and assets associated with a user, receive or consume digital assets, and transfer tokens that may be associated with digital assets such as cryptocurrencies, licenses, property, or other types of resources.

[0008] Blockchain technology is most widely known in relation to the use of cryptocurrency implementations, but digital entrepreneurs are exploring the use of both the Bitcoin-based cryptographic security system for implementing new systems and the data that can be stored on the blockchain. Blockchain technology can be highly advantageous when the blockchain has potential use in automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions can utilize the benefits of the blockchain (such as permanent tamper-proof recording of events, distributed processing, etc.) while expanding their applications.

[0009] One area of current research is the use of blockchain for the implementation of "smart contracts". There exist computer programs designed to automate the execution of machine-readable contracts or the terms of an agreement. Unlike traditional contracts written in natural language, smart contracts are programs executable by machines that contain rules capable of processing inputs to generate results and execute actions according to those results.

[0010] In particular, one area of research relates to the transfer of assets and how such transfers can be recorded on the blockchain to ensure they benefit from the immutability of the blockchain. Additionally, there is particular interest in providing an efficient and secure protocol for the transfer of assets, in addition to means of logging such transfers to ensure that, supported by the underlying blockchain infrastructure, asset transfers are securely recorded and logged.

Prior Art Documents

Patent Documents

[0011]

Patent Document 1

Patent Document 2

[0012] Throughout this specification, variations of the word such as “comprise,” “includes,” “comprises,” or “comprising” are understood to imply the inclusion of the elements, integers, steps, or groups of elements, integers, or steps described herein, but not the exclusion of any other elements, integers, steps, or groups of elements, integers, or steps.

[0013] This disclosure relates to a method and system that can enable the recording of payment events, which may, for example, be payment in currency in exchange for goods.

[0014] In some embodiments, a method is provided that is implemented by a computer recording an asset transfer event, which involves at least a first user and a second user. The asset may be understood as a representation of a physical asset using blockchain tokens. The asset may be a precious metal represented using blockchain tokens. The asset may be a tokenized asset. A tokenized asset may be a certain amount of currency. The asset may be a product or a service. The asset transfer event may be a payment of currency for a product, item, or service. Some embodiments may allow the recording of a payment of currency. A payment of currency may be any currency or type of currency, may be for a product or service, or may be an exchange for a different currency or type of currency. Some embodiments may be implemented by computing resources. Computing resources may be implemented by hardware or software. Computing resources may include multiple processing resources that are distributed either locally or over a wide geographical area. The method may include the step of receiving instruction data, wherein the instruction data relates to a requested asset transfer event, and the instruction data includes a first set of metadata relating to the 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, the currency of the payment, the account, the person designated to receive or make the transfer, the terms and conditions of the payment, and at least one of the following: 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 includes the steps of associating the sender of an asset with a first chain of commitments and associating the recipient of an asset with a second chain of commitments, wherein each chain of commitments may further include the step of associating 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 each time a commitment is added to a chain of commitments, an entry is added to the event stream. The entry added to the event stream may contain some metadata from the commitment. The metadata may be contained within the data payload of the commitment, and at least some of the metadata may be stored within the entry in the event stream.

[0016] An event stream may include a blockchain-supported append-only log to which data recorded in blockchain transactions may be appended in a time-ordered log. In other words, an event stream may log data recorded on the blockchain in chronological order, i.e., in the order in which the data appears on the blockchain. This means that the order of transactions within 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 always the case. Two events occurring simultaneously mean that the order of the events is not reflected in the order of transactions within the block. It is possible that an event with index N+1 on the event stream 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 can be implemented using any preferred data structure. An event stream may include a series of entries stored in a sequence, each entry in the sequence being referenced within 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 changes to the event stream are detectable, ensuring that individual entries in the event stream have not been modified since they were written, that no entries have been inserted between previously consecutive entries, that no entries have been deleted, and that entries have not been reordered.

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

[0018] The association of either or both of the first and second chains of commitments with each sender or recipient may include initializing the chains of commitments and associating the chains of commitments with each sender or recipient. The method may further include the step of associating other entities with each chain of commitments. Other entities may be a registry manager associated with an 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 resources owned or controlled by the respective individual or organization. Examples of assets include cash or anything else of monetary value. An example of an asset registry might be a bank that records cash deposits into accounts that can be used to fund transactions in a particular currency. Another example might be a gold account, which is a record book of gold deposits owned by an individual. An asset registry is associated with the issuer of the assets related to the accounts managed by the asset registry. An exemplary issuer might be the Royal Mint.

[0020] The method includes the step of comparing a first set of metadata with a second set of metadata to determine whether an asset transfer can take place from a sender to at least one recipient in accordance with a transfer protocol, the step of the transfer protocol defining at least one criterion that enables an asset transfer event to occur.

[0021] A transfer protocol may define at least one criterion that must be met in order for an asset transfer event to take place. At least one criterion may require that the sender and recipient be associated with accounts related to the same asset registry. For example, at least one criterion may require that the accounts belong to the same bank. At least one criterion may require that the accounts be associated with the same type of asset. For example, such a criterion may require that both accounts be denominated in sterling pounds (GBP).

[0022] Based on a comparison between each set of metadata in accordance with the transfer protocol, the method may further include the step of determining one or more correspondences between each set of metadata.

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

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

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

[0026] A rendezvous blockchain transaction may be added to the first and second chains of commitments, respectively. In other words, a rendezvous blockchain transaction forms a commitment within the chain of commitments.

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

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

[0029] The method may further include the step of adding 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 jointly form a payment instruction dataset for an asset transfer event.

[0031] The method described above allows asset transfer events to be recorded using a chain of commitments, which associates the blockchain with an event stream and generates blockchain transactions that form a chain of transactions in which each transaction commits to the next transaction, using future transaction data. This provides a secure, relatively simple, user-friendly, efficient, and robust method for recording asset transfer events. This allows users, such as senders or receivers, to quickly and easily access and interact with their history of asset transfer events.

[0032] Aspects and embodiments of this disclosure will be described hereafter with reference to the accompanying drawings, merely as examples. [Brief explanation of the drawing]

[0033] [Figure 1a] This is a diagram showing a system according to an embodiment. [Figure 1b]This diagram shows a node configured to implement Bitcoin software to enable blockchain transactions. [Figure 1c] This is a diagram showing a blockchain network. [Figure 2] This flowchart provides a detailed explanation of account setup according to the embodiment. [Figure 3a] This flowchart details the payment from sender to receiver according to the embodiment. [Figure 3b] This flowchart details the payment from sender to recipient according to the embodiment. [Figure 3c] This figure shows a rendezvous transaction according to the embodiment. [Figure 3d] This diagram shows the relationship between the dust transaction chain and the event stream. [Figure 3e] This diagram shows multiple event streams corresponding to the parties involved in a transaction. [Figure 4a] This flowchart details the payment from sender to receiver according to the embodiment. [Figure 4b] This figure shows a rendezvous transaction according to the embodiment. [Figure 4c] This diagram shows multiple event streams corresponding to the parties involved in a transaction. [Figure 5a] This flowchart details the payment from sender to receiver according to the embodiment. [Figure 5b] This figure shows a rendezvous transaction according to the embodiment. [Figure 5c] This diagram shows multiple event streams corresponding to the parties involved in a transaction. [Figure 6a] This flowchart details the payment from sender to receiver according to the embodiment. [Figure 6b] This flowchart details the payment from sender to recipient according to the embodiment. [Figure 7]This figure shows the rendezvous blockchain transactions generated by the embodiment. [Figure 8] This figure shows the event streams of the parties involved in a transaction according to the embodiment. [Figure 8a] This is a diagram showing the commitment chain. [Figure 9] This diagram shows the steps of a method for recording asset transfer events using a commitment chain. [Figure 10] This diagram shows a rendezvous transaction that synchronizes multiple chains of commitments. [Figure 11] This is a diagram of a Merkle tree representing a state digest. [Figure 12] This diagram shows a Merkle tree representing data digest. [Figure 13] This diagram shows an alternative rendezvous transaction that synchronizes multiple chains of commitments. [Modes for carrying out the invention]

[0034] Hereafter, we will provide a detailed examination of the aspects and embodiments of this disclosure in order to give the reader the most complete understanding of this disclosure.

[0035] In a first aspect, a method is provided which is implemented by a computer for recording asset transfer events, including at least a first user and a second user. The method may enable the recording of currency payments. Currency payments may be in any currency and may be for goods or services. The method may be implemented by computing resources. Computing resources may be implemented by hardware or software. Computing resources may include multiple processing resources that are distributed either locally or over a wide geographic area. The method may include a step of receiving instruction data, the instruction data relating to a requested asset transfer event, and the instruction data including a first set of metadata relating to the sender of the payment and a second set of metadata relating to at least one recipient of the payment. The metadata may identify at least one of the following: the currency of the payment, an account associated with an asset registry, an individual designated to receive or make the payment, the terms and conditions of the payment, and evidence of a public key or digital signature authorizing the payment. Each of the sender and recipient may be associated with an account associated with an asset registry, respectively.

[0036] The sender of an asset may be associated with a first chain of commitments, and the recipient 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 blockchain transactions in that set are linked by information which may be included in the output data payload.

[0037] The method includes the step of comparing a first set of metadata with a second set of metadata to determine whether an asset transfer can take place from a sender to at least one recipient in accordance with the transfer protocol, the step of defining at least one criterion that enables an asset transfer event to occur.

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

[0039] The method includes the step of adding entries to the respective event streams associated with a first chain and a second chain of commitments, the entries including data associated with a first set and a second set of metadata, which may further include the step of adding entries to the respective event streams associated with a first chain and a second chain of commitments, the entries including data associated with a first set and a second set of metadata.

[0040] The method is a step of generating a rendezvous blockchain transaction having at least one input and at least one output, the step of which at least one output includes output data relating to a first set and a second set of metadata, and the data relating to the metadata is further based on data relating to future transactions and which may also be based on previous transactions. The at least one input and output may be a plurality of corresponding inputs and outputs.

[0041] The method may further include the step of associating a rendezvous blockchain transaction with each entry in each event stream. Associating a rendezvous blockchain transaction with each 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 the blockchain. A rendezvous transaction may be sent along with a set of other blockchain transactions.

[0043] A rendezvous blockchain transaction may include input-output pairs corresponding to the sender and receiver, respectively. The input-output pairs may be understood to mean corresponding inputs and outputs in terms of their indices. That is, for example, if the input has index 0, the output of the input-output pair will also have index 0. There may also be input-output pairs corresponding to other entities, such as an asset registry.

[0044] At least one output may include a data payload containing a first and second set of metadata, as well as output metadata generated based on future transactions. The output metadata may include a data digest and a state digest. At least one output may be unavailable. The first and second sets of metadata may be hashed or double-hashed before being included in the data payload. Future transaction data may be identifiers for future transactions. In other words, the data payload may include information to commit to future transactions, which may link the current transaction to a future transaction, and may also link previous transactions to future transactions.

[0045] The data digest may be generated based on hashes of a first and second set of metadata. Further hashes may be applied to the hashes of the first and second sets of metadata, which provides resistance to decryption attacks.

[0046] A data digest may be generated based on a combination of a first set of metadata and a second set of metadata, and a salt. That is, a salting operation may be applied to the hashes 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 any freely chosen piece of data, as part of the input to the hash function (along with the data being hashed). The salt may be concatenated with other inputs to the hash function. Optionally, the salt is random. A different salt may be chosen for each data item being hashed.

[0048] A combination of the first and second sets of metadata may include obtaining 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 the double hash of the salt.

[0049] The state digest may be generated based on the data digest and future transactions, and may be further 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 each set of metadata is: i) The currency of payment identified within each set 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, iii) Identifiers of asset registries related to the sender and recipient accounts This may include determining a correspondence between at least one of the following.

[0052] The computing resources determine that a transfer cannot be made according to the transfer protocol and generate a further set of metadata to resolve the non-conformity with the transfer protocol, which may include generating metadata that enables conversion between a first currency and a second currency.

[0053] Generating further sets of metadata may involve generating metadata for one asset registry in order to record the transfer of a given asset in another asset registry.

[0054] Specific embodiments are described hereafter as examples with reference to the attached drawings, where similar reference numbers indicate similar features.

[0055] System Overview Hereafter, with reference to Figure 1a, we will describe a system 100 that enables the recording of asset transfers between a first user and a second user of the system 100.

[0056] 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 resources. Each of the first computing device 102 and the second computing device 104 is configured to interact with a payment processing resource 106 via their respective first and second application programming interfaces (APIs) 108.

[0057] The payment processing resource 106 is configured to initialize and / or interact with the event streams provided for at least each of the following: 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 the event streams and interaction with the event streams by the payment processing resource 106 will be understood from UK Patent Application No. 2102314.8, filed in the name of nChain Holdings Limited on 18 February 2021.

[0058] The payment processing resource 106 is further configured to interact with blockchain 112. 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 additional dedicated ledger of blocks (BSV1, BSV2, BSV3) composed of transactions.

[0059] Blockchain 112 includes multiple nodes 126 configured by software, which will be described below in relation to Figure 1b. Each node is configured as part of the blockchain by this software, as will be described below in relation to Figure 1c.

[0060] Figure 1b shows an example of node software 450 executed on each blockchain node 126 of network 132 in an example of a UTXO or output-based model. Note that another entity may execute node software 450 without being classified as a node 126 on network 132, i.e., without performing the required actions of node 126. Node software 450 may include, but is not limited to, a set of a protocol engine 451, a script engine 452, a stack 453, an application level decision engine 454, and one or more blockchain-related functional modules 455. Each node 126 may execute node software including, but 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., a database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process those fields according to the node protocol. When a transaction 152j (Tx m-1 ) having an input that refers to an output (e.g., a UTXO) of another previous transaction 152i (Tx j ) is received, the protocol engine 451 identifies the unlock script of Tx j and passes that unlock script to the script engine 452. Also, the protocol engine 451 identifies and retrieves Tx j based on the pointer of the input of Tx i . Tx i may be published on the blockchain 150, in which case the protocol engine may retrieve Tx i from a copy of block 151 of the blockchain 150 stored at node 126. Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 retrieves Tx iYou may extract it. In any case, protocol engine 451 will Tx i Identify the lock script in the referenced output and pass it to script engine 452.

[0061] Therefore, script engine 452 is Tx i The lock script and Tx j The corresponding input has a lock-release script. For example, transactions labeled Tx0 and Tx1 are shown in Figure 2, but the same could be true for any pair of transactions. The script engine 452 executes the two scripts together as already discussed, which involves putting data into the stack 453 and taking data out of 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 satisfies one or more criteria defined in the lock script—that is, whether the unlock script "unlocks" the output containing the lock script. 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 satisfies one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, the script engine 452 returns "false."

[0063] In output-based models, the result "true" from script engine 452 is one of the conditions for transaction validity. Generally speaking, Tx j The total amount of digital assets specified in the input does not exceed the total amount indicated by the input, and Tx iThere are also one or more further protocol-level conditions, which must be satisfied and are evaluated by the protocol engine 451, such as that the indicated output has not already been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and only if they are all true does transaction Tx proceed. j Enable it. The protocol engine 451 outputs an indication to the application-level determination engine 454 whether the transaction is valid. Tx j Only under the condition that it is indeed enabled, the decision engine 454 controls both the consensus module 455C and the propagation module 455P, and Tx j You may choose to perform each of those blockchain-related functions. This means that the consensus module 455C will input Tx into each ordered set 154 of the transaction nodes for incorporation into block 151. j Adding the propagation module 455P, Tx j This includes transferring the transaction to another blockchain node 126 on network 106. Optionally, in an embodiment, 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 a transaction only if it is valid and leaves sufficient transaction fees.

[0064] It should be noted that the terms “true” and “false” as used herein are not necessarily limited to returning a result represented in the form of a single binary digit (bit), although that is certainly one possible implementation. More broadly, “true” can refer to any state indicating a successful or positive outcome, and “false” can refer to any state indicating a failed or unpositive outcome. For example, in an account-based model, a “true” result might be indicated by a combination of the implicit protocol-level validation of the signature and an additional positive output from the smart contract (the overall result is considered to indicate true if both individual results are true).

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

[0066] For example, some of the embodiments described above have been explained in terms of a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 126. However, it will be understood that the Bitcoin blockchain is just one specific example of blockchain 150, and the above description may be broadly applicable to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More broadly, all of the above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 126 may be replaced with references to blockchain network 106, blockchain 150, and blockchain node 126, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 126 as described above.

[0067] In a preferred embodiment of the present invention, the blockchain network 132 is a Bitcoin network, and the Bitcoin node 126 performs at least all of the described functions of creating, publishing, propagating, and storing block 151 of blockchain 150. It is not ruled out that there may be other network entities (or network elements) that perform only one or some of these functions, but not all of them. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (it should be noted that these entities are not considered nodes of the preferred Bitcoin network 132).

[0068] In an unfavorable embodiment of the present invention, the blockchain network 132 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or part of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150, but not all of them. For example, on those other blockchain networks, “node” may be used to refer to a network entity that is configured to create and publish blocks 151, but is not configured to store and / or propagate those blocks 151 to other nodes.

[0069] More broadly, any reference to the above term “Bitcoin node”126 may be replaced with the term “network entity” or “network element,” such entity / element configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above in relation to blockchain node126.

[0070] More broadly, any reference to the above term “Bitcoin node”126 may be replaced with the term “network entity” or “network element,” such entity / element configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above in relation to blockchain node126.

[0071] Figure 1c shows an exemplary system 100 for implementing blockchain 150. System 100 may consist of a packet-switched network 130, typically a wide-area internet such as the internet. The packet-switched network 130 may include multiple blockchain nodes 126, which may be arranged to form a peer-to-peer (P2P) network 132 within the packet-switched network 130. Although not shown, the blockchain nodes 126 may be arranged as a near-complete graph, so that each blockchain node 126 is tightly connected to other blockchain nodes 126.

[0072] Each blockchain node 126 includes the computer equipment of its peers, and different nodes among the nodes 126 belong to different peers. Each blockchain node 126 includes processing equipment, including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media or multiple non-temporary computer-readable media. Memory may include one or more memory units employing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0073] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 126 of the decentralized or blockchain network 130. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean remembering the entire blockchain 150. Rather, blockchain 150 may be pruned, as long as each blockchain node 150 remembers the block header (considered below) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction 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 contains at least one input and at least one output. Each output specifies an amount representing the quantity of a digital asset as property, an example being user 103 whose output is cryptographically locked (requiring the user's signature or other solution to be unlocked and thereby performed or consumed). Each input points backward to the output of the preceding transaction 152, thereby linking the transactions.

[0074] Each block 151 also includes a block pointer 155 that points backward to a previously created block 151 in the chain, defining the order in which they occurred up to block 151. Each transaction 152 (other than a coinbase transaction) includes a pointer that goes back to the previous transaction, defining the order of the transaction sequence (note that the sequence of transactions 152 is allowed to branch). The chain of block 151 traces back to the genesis block (Gb) 153, which was the first block in the chain. One or more initial transactions 152 in the early stages of chain 150 pointed to the genesis block 153, rather than a preceding transaction.

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

[0076] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be performed or "consumed" in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or even when it is sent to network 132, but for the current transaction to be valid, a preceding transaction 152i must exist and be enabled. Thus, "predecessor" as used herein refers to a predecessor in a logical sequence linked by pointers, and not necessarily to the time of creation or transmission in a temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or sent out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i may similarly be called an antecedent or predecessor transaction.

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

[0078] According to output-based transaction protocols like Bitcoin, when an entity 103, such as a user or machine, wants to define a new transaction 152j, the entity sends the new transaction from its computer terminal to the recipient. The entity or recipient then sends this transaction to one or more of the blockchain nodes 126 on the network 132 (which are generally servers or data centers, but in principle could be other user terminals). It is also not ruled out 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 examples, may not send it to the recipient. The blockchain node 126 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 126. The blockchain node protocol generally requires the blockchain node 126 to check that the cryptographic signature of the new transaction 152j matches the 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 the cryptographic signature or other authorization of entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i allocated by the new transaction, which generally includes checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of transaction 152i before the input of the new transaction was linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, the condition may be determined solely by the blockchain node protocol, or by a combination of these.In any case, if the new transaction 152j is valid, blockchain node 126 forwards it to one or more other blockchain nodes 126 in blockchain network 132. These other blockchain nodes 126 apply the same test 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 way, 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., a 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 invalid, transaction 152j is not propagated (unless flagged as invalid for warning and propagated) and is not recorded on blockchain 150. This prevents double spending, where the transactional party attempts to allocate the output of the same transaction more than once. Account-based models, on the other hand, prevent double spending by maintaining account balances. Again, since there is a defined order of transactions, account balances always have a single defined state.

[0080] In addition to activating transactions, blockchain node 126 further competes to become the node that first creates a block of transactions in a process usually called mining, supported by "proof of work". At blockchain node 126, the new transaction is added to an ordered set 154 of valid transactions that have not yet appeared in block 151 recorded in blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transaction 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 the output of the hash satisfies a given condition when the nonce is concatenated with a representation of the ordered set 154 of transactions and hashed. For example, a given condition may be that the output of the hash has leading zeros of a certain predefined number. Note that this is just one specific type of proof of work puzzle, and does not exclude other puzzles. A property of hash functions is that they have an unpredictable output for their inputs. Therefore, this search can only be performed by brute force, and thus consumes a considerable amount of processing resources on each of the 126 blockchain nodes attempting to solve the puzzle.

[0081] The first blockchain node 126 to solve the puzzle announces this to the network 132 and provides the solution as proof which can then be easily checked by other blockchain nodes 126 on the network (given a hash solution, it is easy to check that it satisfies the conditions for the hash output). The first blockchain node 126 accepts the block and thus propagates it until a threshold consensus is reached among the other nodes enforcing the protocol rules. Then, the ordered set of transactions 154 is recorded as a new block 151 in blockchain 150 by each of the blockchain nodes 126. Also, a block pointer 155 that points backward to previously created blocks 151n-1 in the chain is assigned to the new block 151n. The significant amount of effort required to create the proof of work solution, for example in the form of a hash, signals the first node 126's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, also known as double spending. Once created, block 151 is recognized and maintained in each of the blockchain nodes 126 of the blockchain network 132, and therefore cannot be modified. Furthermore, block pointers 155 assign an order of occurrence to block 151. Since transaction 152 is recorded in the ordered blocks of each blockchain node 126 of the network 132, this thus provides an immutable public ledger of transactions.

[0082] It should be noted that different blockchain nodes 126 competing to solve the puzzle at any given time may be doing so based on different snapshots of an ordered set 154 of transactions not yet published at any given time, depending on when those blockchain nodes 126 began searching for the solution or the order in which the transactions were received. Whoever first solves each of those puzzles defines which transactions 152 will be included in the next new block 151n in what order, and the current set 154 of unpublished transactions is updated. The blockchain nodes 126 then continue to compete to create a block from the newly defined unprocessed ordered set 154 of unpublished transactions, and so on. There is also a protocol for resolving all possible "forks," which are points where two blockchain nodes 126 solve the puzzle of their respective blockchain nodes 126 within a very short time, so that opposing views of the blockchain propagate between the nodes 126. In short, the fork claw of whichever one is the longest becomes the final blockchain 150. Please note that this should not affect any network users or agents, as the same transaction will appear on 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 defined amount of digital assets in a new special type of transaction that distributes a defined amount of digital assets (as opposed to inter-agent or inter-user transactions, which transfer a certain amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but is sometimes called an "initiation transaction." This special type of transaction generally forms the first transaction of a new block 151n. Proof of work informs the node constructing the new block of its intention to follow the protocol's rules, which allow this special transaction to be fulfilled later. The blockchain protocol's rules may require a maturity period, for example, 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 block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and will be discussed below.

[0084] Due to the resources involved in validating and publishing transactions, each of the blockchain nodes 126 generally takes the form of a server containing one or more physical server units, or even an entire data center. However, 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 run on the processing unit of the blockchain node 126 in order to perform one or more of its respective roles in accordance with the blockchain node protocol and to process transaction 152. It will be understood herein that all actions attributed to blockchain node 126 may be performed by software running on the processing unit of each computer device. The node software may be implemented in one or more applications of the application layer, in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0086] Further connected to network 130 are the computer devices of multiple stakeholders 103 acting as consumer users. These users may interact with the blockchain network but do not participate in the activation, 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 blockchain 150 without necessarily acting as senders or receivers. For example, some stakeholders may act as storage entities that store copies of blockchain 150 (e.g., copies obtained from blockchain node 126).

[0087] Some or all of the stakeholders 103 may be connected as part of a different network, for example, a network superimposed on the blockchain network 132. Users of the blockchain network (often referred to as “clients”) may be said to be part of the system including the blockchain network, but these users are not blockchain nodes 126, as they do not perform the required role of a blockchain node. Instead, each stakeholder 103 may utilize the blockchain 150 by interacting with the blockchain network 132 and thereby connecting to (i.e., communicating with) the blockchain node 132. For illustrative purposes, two stakeholders 103 and their respective devices are shown, namely, a first stakeholder 103a and its respective computer device 102a, and a second stakeholder 103b and its respective computer device 102b. The first computing device 102 and the second computing device 104 may be configured to implement either the functionality of their respective computer devices 102a or 102b. Many further such parties 103 and their respective computer equipment may exist and participate in System 100, but for convenience, they are not shown in the illustrations. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to herein as Alice, and the second party 103b is referred to as Bob, but this is not limited, and all references herein to Alice or Bob may be replaced by “first party” and “second party,” respectively.

[0088] Each of the computer devices of Parties 103 includes one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each of the computer devices of Parties 103 further includes memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media or multiple non-temporary computer-readable media. This memory may include one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each of the computer devices of Parties 103 stores software, each including at least one instance of a client application 105 arranged to run on the processing unit. It will be understood that all actions attributed to a given Parties 103 in this specification may be performed using software running on the processing unit of each of the computer devices. Each of the computer devices of Parties 103 includes at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment of the given party 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 computer equipment of any given party 103 on one or more suitable computer-readable storage media, for example, by downloading from a server or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive. The client application 105 corresponds to 105a and 105b on devices 102a and 102b shown in Figure 1c, respectively.

[0090] The client application 105 includes at least a “wallet” function, which has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign) a transaction 152, and then propagate it throughout the network of blockchain nodes 126, thereby sending it to one or more Bitcoin nodes 126 so that it may be included in blockchain 150. The other is to return to each party a report of the amount of digital assets they currently own. In an output-based system, this second function includes matching the defined amounts in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0091] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client function described herein may instead be implemented in a suite of two or more different applications, for example, interfaced by an API or one being a plug-in to another. More broadly, client functions may be implemented in the application layer, or in lower layers such as the operating system, or any combination thereof. The following description will be from the perspective of client application 105, but it will be understood that this is not limiting.

[0092] Each computer device's instance of the client application or software 105 is coupled to at least one of the blockchain nodes 126 of the network 132 in an operable manner. This enables the client 105's wallet function to send transaction 152 to the network 132. The client 105 can also contact the blockchain node 126 to query the blockchain 150 for any transaction in which each party 103 is the recipient (or, in embodiments, the blockchain 150 is a public facility that provides partial trust in transactions by its public visibility, so as to ensure that it checks the transactions of other parties within the blockchain 150). The wallet function of each computer device is configured to assemble and send transaction 152 according to the transaction protocol. As described above, each blockchain node 126 runs software configured to activate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate it throughout the blockchain network 132. The transaction protocol and 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 152 transactions on blockchain 150. The same node protocol is used by all 126 nodes on network 132.

[0093] When a given party 103, for example Alice, wants to send a new transaction 152j so that it can be included in blockchain 150, party 103 constructs the new transaction according to the relevant transaction protocol (using the wallet function of party 103's client application 105). Then, party 103 sends transaction 152 from the client application 105 to one or more blockchain nodes 126 to which it is connected. For example, this could be blockchain node 126 best connected to Alice's computer. When any given blockchain node 126 receives the new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be examined 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 transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol or defined by a combination of the script and the node protocol.

[0094] Subject to the test that a newly received transaction 152j passes to be considered valid (i.e., subject to the condition that a newly received transaction 152j is "activated"), all blockchain nodes 126 that receive transaction 152j add the new activated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 126. Furthermore, all blockchain nodes 126 that receive transaction 152j propagate the activated transaction 152 to one or more other blockchain nodes 126 in network 132. Since each blockchain node 126 applies the same protocol, assuming that transaction 152j is valid, this means that transaction 152j is immediately propagated throughout network 132.

[0095] Once placed in an ordered set 154 of transactions maintained at a given blockchain node 126, blockchain node 126 begins a competition to solve a proof-of-work puzzle about the latest version of each of those ordered sets 154 of transactions, including the new transaction 152 (other blockchain nodes 126 may be attempting to solve the puzzle based on different ordered sets 154 of transactions, but remember that whoever succeeds first will define the ordered set of transactions included in the latest block 151. Ultimately, blockchain node 126 solves the puzzle about the portion of the ordered set 154 that includes Alice's transaction 152j). Once proof-of-work is performed on the ordered set 154 containing the new transaction 152j, the ordered set 154 immutably becomes part of one of the blocks 151 of blockchain 150. Each transaction 152 contains a pointer back to a previous transaction, and therefore the order of transactions is also immutably recorded.

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

[0097] An alternative type of transaction protocol operated by some blockchain networks is sometimes referred to as an “account-based” protocol, as part of an account-based transaction model. In an account-based protocol, each transaction defines the amount to be sent by referencing the absolute balance of the account, rather than by backward referencing the UTXOs of preceding transactions in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes of that network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called a “position”) of the account. This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of a transaction reference calculation. Additionally, an arbitrary data field may be signed into the transaction. This data field may, for example, point backward to a previous transaction if the previous transaction ID is included in the data field.

[0098] Transactions recorded on Blockchain 112 are either used or not used, modeling the transfer of value protected by a lock script. A transaction consumes value through its input and sends value to another party through its output. The value input to a transaction must be greater than or equal to the value output by the previous transaction, and any extra input is charged as a transaction fee. A transaction is invalid if the solution presented in the lock script, i.e., the unlock script, is incorrect, if the transaction outputs more value than it takes as input, if the transaction consumes output that has already been consumed, or if the transaction attempts to consume value that does not exist at all.

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

[0100] The payment processing resource 106 in Figure 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 unused outputs (UTXOs) from the blockchain transactions. Unused transactions may be stored in a distributed hash table (DHT). The payment processing resource 106 is configured to generate blockchain transactions using unused outputs and to provide its funds as input to those transactions. The payment processing resource 106 is configured to check the DHT or a temporary / secondary mempool for the existence of outputs, ensuring that the outputs consumed by a transaction are not already consumed outputs, i.e., that the outputs consumed by a transaction are unused outputs and not double-spending. The payment processing resource 106 is further configured to send blockchain transactions to the blockchain 112 and to receive notifications from the blockchain 112 when the transactions are received. Upon receiving notification that the transaction has been received by the blockchain 112, the payment processing resource 106 is configured to generate a transaction identifier. The identifier may be alphanumeric. The payment processing resource 106 is configured to add outputs that can be proven to be unusable for the blockchain transactions it generates, and to use those outputs to add a data carrier containing a hash of the data provided by the payment processing resource 106.

[0101] Once the payment processing resource 106 generates an identifier, the payment processing resource 106 is configured to request that the data be logged to the event stream (as further described 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 use a database management system (DBMS) 140 to create, delete, and manage this account-related information. The DBMS 140 may be located locally or remotely from the payment processing resource 106, and the payment processing resource 106 may access the DBMS 140 using any suitable telecommunications medium.

[0103] The payment processing resource 106 in 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 parties who use the payment processing resource 106 to enable transactions to be performed. The key storage module 122 may utilize any suitable storage and may use a database management system (DBMS) to initialize, store, and retrieve data from records in the database of parties who store cryptographic keys in the key storage module 122. The payment data store 124 is configured to store data related to all payments performed 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. The establishment of such an account will be described below with reference to Figure 2.

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

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

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

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

[0109] Then, in step S214, the payment processing resource 106 sends a confirmation message to the first computing device 102 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 (related to a bank such as HSBC). An event stream 110b corresponding to Bob's account is also initialized.

[0110] Event streams are blockchain-based, append-only logs. Users of payment processing resource 106, such as Alice or Bob, can create event streams corresponding to their accounts, append to those event streams, and close those event streams. These will be explained later.

[0111] Alternatively, Alice or Bob may bypass steps S200 through S214, provided they provide account details related to an asset registry they are already using and provide all the necessary information.

[0112] Preparing payment data for recording Here, we describe several exemplary scenarios in which the payment processing resource 106 enables the transfer of assets. These examples are intended to be illustrative and non-exclusive, in that the features of each example may be combined with the features of the others.

[0113] Hereafter, with reference to Figures 3a and 3b, we will describe an exemplary scenario in which Alice sends 5 GBP to Bob using 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 let him know that she 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] Next, Alice 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 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 device 102 to API 108 indicates the amount Alice wants to pay to Bob. The call from device 102 further indicates the account from which Alice wants to pay, the currency Alice wants to pay in, and the recipient of the payment, namely Bob. The amount Alice wants to pay to Bob, Bob's identification information, and the identification information of the account from which Alice wants 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 payment processing resource 106 receives 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. Payment processing resource 106 retrieves the currency associated with Bob's account, namely the sterling pound (GBP) and the bank from Bob's account.

[0117] Next, in step S312, the payment processing resource 106 generates a payment instruction dataset 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 identified as "hsbc.com", the currency as GBP, the payment amount (i.e., the amount received by Bob) as 5 GBP, and the account identification information is <bob:hsbc>Provided by, 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 instruction dataset. The payment instruction dataset is optionally signed.<Bob_sig> This may also include versions of the clauses and conditions signed by Bob using [the specified method / tool].

[0119] Another part of the payment instruction dataset is formed by Alice's details. Specifically, the account provider is identified as "hsbc.com", the currency as GBP, the amount of the payment being sent to Bob as 5 GBP (i.e., a 5 GBP debit from Alice to Bob, and therefore represented as -5 in the payment instruction dataset), and the account identification information is <alice:hsbc>Provided by, the user is identified as Alice by the "kyc" value. The payment instruction dataset may also include terms and conditions signed by Alice, which may be contained in documents that may be accessed from the uniform resource locator (URL). The payment instruction dataset also identifies the agent as the originator of the payment, i.e., the individual making the payment.

[0120] Then, in step S314, the message is sent to the first computing device 102 with a request for Alice to sign the payment instruction dataset. Alice then provides her cryptographic signature in step S316 to authorize the payment of 5 GBP to Bob. At that time, Alice's signature is applied to the payment instruction dataset by the payment processing model 132. In other words, Alice signs the payment instruction dataset with her cryptographic signature. In short, Alice's account has been withdrawn and Bob's account has been deposited. Therefore, Alice's signature is required. Bob's signature may only be required if Bob has provided a T&C link (i.e., a URL to a document containing the terms and conditions that Bob has signed) and a hash of the document containing the terms and conditions. This means that if Alice is purchasing something from Bob in exchange for the transferred funds, it may be possible to demonstrate that Bob presented the terms and conditions in exchange for the payment.

[0121] Since the banks are the same and the amounts are equal, only one signature is required in this example. As mentioned above, if Bob provides a T&C link, two signatures may be required.

[0122] Next, in step S318, the payment processing resource 106 applies payment protocol criteria to the payment instruction dataset. In step S320, the payment processing resource 106 accesses the payment protocol module 120.

[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 withdrawn from Alice's account is equal to the amount paid to Bob's account. This is step S322. 5 GBP has been withdrawn from Alice's account and 5 GBP has been paid to Bob's account; therefore, the amounts are the same and the banks are the same, so the zero-sum rule is met. In other words, -5 GBP has been added to Alice's account and +5 GBP has been added to Bob's account, so the sum of the amounts is 0. Since the banks are the same, this step is met and the dataset adheres to the zero-sum rule.

[0124] Next, the payment protocol module 120 checks that the amount being sent from Alice to Bob does not cause Alice's balance to fall below a certain minimum value. This is step S324. In other words, is Alice overspending? If Alice is overspending, i.e., if Alice's balance (minus 5 GBP) falls below the minimum value, the payment protocol module 120 issues an error message to Alice to let her know that she cannot spend the money she wants to spend, i.e., that she does not have the funds to pay Bob 5 GBP. Furthermore, if the credit line has been used, the minimum value may even be negative. The payment protocol module 120 returns to step S320 until it is instructed to start again, i.e., when Alice deposits more funds into her bank account or when Alice's minimum balance changes.

[0125] Next, the payment protocol module 120 checks whether the payment-related data matches between the two parties in the transaction by checking fields in the data corresponding to the asset identification information. This is step S326. The data in this example matches because the zero-sum rule is satisfied, the banks are the same, i.e., "hsbc.com", and the currencies are the same. In other words, the bank and asset identification information balances out. When the bank and asset identification information does not balance out, as seen in further examples below, additional metadata needs to be generated to provide the required balance.

[0126] Another way to demonstrate this is to use a template (XXX_BBBB:AAAA) to show bank and asset identification information, where XXX is the account manager, BBBB is the bank identification information, and AAAA is the asset identification information. Using this template, we can show that 5 GBP is paid from Alice_HSBC:GBP to Bob_HSBC:GBP, demonstrating that the bank and asset identification information is balanced.

[0127] The payment processing module 120 then 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 for each signature and comparing the hashes to those stored in the records generated in steps S200 to 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] The satisfaction of steps S322, S324, S326, and S328 means that the criteria specified by the payment protocol have been met, and therefore the payment processing resource 106 is able to make the payment of 5 GBP from Alice to Bob in accordance with the payment instruction dataset.

[0129] At that time, in step S330, the payment processing resource 106 retrieves blockchain transactions from blockchain 112 for Alice and Bob, respectively. This is illustrated with reference to the illustrative schematic diagram in Figure 3c.

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

[0131] Generating a rendezvous transaction The payment processing resource 106 then generates a new rendezvous blockchain transaction 406 containing the respective dust inputs for Alice and Bob, using the respective dust outputs from the blockchain transactions retrieved in step S330. The dust outputs may be retrieved from the dust chain corresponding to the event stream associated with Alice and Bob, as shown in Figure 3c. The chain from transactions 402 and 404 to 406 can be described as a chain of dust transactions. Dust inputs / outputs are inputs / outputs of an amount of cryptocurrency indicated as “dust” by the cryptocurrency field. In the context of blockchain transactions in this disclosure, “dust” is understood to be a usable transaction relating to a digital asset or cryptocurrency with a low or minimum value output, i.e., the value may be much less than the fee for mining the output on the blockchain.

[0132] Alternatively, payment processing resource 106 may generate new dust transactions using a combination of dust that does not form part of an existing event stream and a hierarchical deterministic (HD) keychain, as described in UK Patent Application No. 2102217.3. In other words, a dust transaction is generated using dust as input, including inputs corresponding to Alice and Bob, respectively, and that dust has not already been used in an event stream. A party owning an HD keychain may use one of the subkeys and the dust to generate the first transaction of a new event stream. In short, a new event stream may be started based on dust that has been extracted from an existing transaction on blockchain 112 and can be used as the basis for starting a new event stream. That is, dust may be used to generate a transaction (to start a new event stream) and then returned to the platform before being used to start another event stream.

[0133] The relationship between the dust transaction chain and the event stream will be further clarified later, with reference to Figure 3d.

[0134] Figure 3d relates to a first aspect of this disclosure and illustrates the basic data structure and paradigm of an ordered additional dedicated data storage system. This could also be described as a data logging system. The particular system shown in Figure 3d is an event stream system for logging events. As an example, event streams are used throughout for illustrative purposes only, but those skilled in the art will understand that the proposed systems and aspects described herein may be used more broadly with data items and with ordered additional dedicated data item logging or storage systems. Consistent with Figures 4 and 6, data items refer to hashes of actual data. Advantageously, using hashes instead of the data itself provides proof of data existence without requiring the data (which may be large, and even too large for a transaction) to be stored in a transaction. It also protects data privacy because the data is indistinguishable from the hash, even if the hash is exposed on the chain. The data described herein is payment instruction data related to payments recorded by 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 using a "chain of dust" (506). Data associated with 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 the transaction's unusable OP_RETURN output -- an example of such a transaction is the rendezvous transaction 406 described above. This is a Script opcode that can be used to write arbitrary data to the blockchain and also to mark the transaction output as invalid. As another example, OP_RETURN is a Script language opcode for creating an unusable output of a transaction that stores data such as metadata within the transaction, thereby immutably recording the metadata on the blockchain.

[0136] The Dust Chain, in this context, is a seamless chain of cryptocurrency inputs and outputs used to impose a spending dependency on each blockchain transaction in a sequence to its direct predecessor.

[0137] The use of dust output in transactions is advantageous and important for maintaining an immutable, continuous record of all those transactions in the order in which they occur, with respect to ordered, additional-dedicated data storage systems such as event streams. This is because, while recording transactions on the blockchain ensures that all blockchain transactions remain in a specific order, time-stamped, and in a particular sequence once they are confirmed or added to the blockchain, this does not guarantee the preservation of the order in which those transactions occurred. 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 output, used by the initial input of the next transaction in a sequence, ensures that the order of transactions is tracked chronologically, creating a tamper-proof record of both the events themselves and the order in which they occurred. This is because, once mined into a block, the payment of dust from the previous transaction to the next transaction in a sequence, in accordance with Bitcoin's protocol rules, is called the payload, and ensures that the sequence of embedded data carrier elements, considered below, cannot be reordered, and that insertions or deletions that could alter the sequence without immediately revealing that the event stream has been compromised are unlikely to occur. In some embodiments, the double-spending 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 chain of dust transactions utilizes topological ordering to provide preservation of the order of transactions between and within blocks (and therefore, associated events and data). This thus improves the integrity of ordered append-only data item storage.

[0138] In this way, blockchain transaction 504 forms a directed graph of transactions. Note that the direction of the graph can be thought of as unidirectional, from the previous transaction to the next transaction in a sequence, as indicated by edge 506. The arrow on edge 506 in Figure 3d indicates that a transaction points to the next transaction, but the expenditure relationships in Bitcoin transactions are actually directed from one transaction to the preceding one. This graph is created by the expenditure relationships between transactions. These expenditure 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 non-exclusively, in the sections that refer to "Ordered, Append-only data Storage," "Event Stream and the Chain of Dust," and "Backward Referencing in the Chain of Dust."

[0139] The rendezvous blockchain transactions, such as transaction 406 shown in Figure 3c, are blockchain transactions for synchronizing multiple event streams, each related to the given entity / user described above. This is achieved by using multiple dust outputs as corresponding inputs. In this example, this allows chains of dust (i.e., dust input / output pairs) corresponding to Alice, Bob, and HSBC to pass through a single transaction. Each dust chain input / output pair must have a corresponding input / output index within the transaction. In this case, the dust chain input / output pairs are used to ensure that payments are recorded in all event streams related to the transaction, as shown below.

[0140] A dust input using Alice's dust output is denoted as Tx1, Alice, and a dust input using Bob's dust output is denoted as Tx1, Bob. In step S332, a new rendezvous blockchain transaction 406 is generated.

[0141] Funds for Rendezvous blockchain transaction 406 are added by payment processing resource 106 and refunded to payment processing resource 106. This may be subject to any miner fees after the activation of Rendezvous blockchain transaction 406, if Rendezvous blockchain transaction 406 is sent to blockchain 112 for activation.

[0142] 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 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] Additionally, the payment processing resource 106 adds outputs in the form of data carriers 412a and 412b that can be certified as unavailable for blockchain transaction 406 for Alice and Bob, respectively.

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

[0145] The data payload held within each data carrier (i.e., the hash of the payment instruction metadata) is held in the transaction's unusable OP_RETURN output, which means the data payload can then be stored on the blockchain as an unusable output.

[0146] The data in data carrier 412 includes the hash of the payment instruction dataset generated by the payment processing resource in steps S300 to S328. This hash is generated in step S334. The output, which can be proven to be unavailable, allows rendezvous transaction 406 to carry the hash of the payment instruction dataset within the transaction, and allows the hash to be stored on the blockchain. This means that the payment instruction dataset, and by extension the payment record, is stored on the blockchain. This means that the payment record benefits from the immutability of the blockchain.

[0147] Next, blockchain transaction 406 may be checked to verify that the user correspondence with the transaction is correct and that it corresponds to the users, namely Alice and Bob. This is step S336.

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

[0149] An event stream is a blockchain-backed, additional, dedicated log. In this example, Alice and Bob each have their own event stream, but if they don't, the 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 Figure 3d, an event stream can be represented as a series of entries, and each entry in the stream may be referred to by a monotonically increasing sequential number, that is, the first entry may be called ES1, the second entry may be called ES2, and so on.

[0151] Payment processing resource 106 adds to each event stream only if Alice and Bob are authorized to access or add to the event stream. Authorization may be checked, for example, by comparing the signature with a signature stored in payment processing resource 106. By adding payment data to the event stream, payments can benefit from being recorded in an immutable log associated with blockchain 112. In short, the event stream is used to track the sequence of transactions from accounts associated with Alice and Bob. That is, entries in the event stream are an immutable log associated with 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 entries have been inserted between previously consecutive entries. • The entry has not been deleted. • Entries have not been reordered. Unauthorized parties are not allowed to add events to the stream.

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

[0153] Next, the payment processing resource 106 generates an identifier for each entry added to the event stream. This is step S342. The identifier may be alphanumeric or 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 SHA256 encryption, the identifier may be generated by applying further SHA256 encryption to the hash of the payment instruction metadata. In other words, the identifier may be a hash of the hash of the payment instruction metadata.

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

[0155] Next, we will describe a further exemplary scenario in which Alice still pays Bob the total of 5 GBP, but Bob's account is provided by Revolut instead of HSBC. This will be illustrated with reference to Figures 4a and 4b. This example is identical to the example illustrated with reference to Figures 3a through 3e up to step S326. Therefore, for brevity, we will begin the explanation from the stage illustrated with reference to step S326.

[0156] In other words, for step S326 to yield a positive result and the transaction to proceed, the banks must be balanced. This means that metadata must be created that balances both the bank and asset identification information.

[0157] In other words, the payment protocol module 120 checks (in step S326) whether the payment-related data 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 are the same and the amounts complement each other, i.e., Alice receives a withdrawal of -5 GBP and Bob receives a deposit of 5 GBP, 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 demonstrate this is to use a template (XXX_BBBB:AAAA) to identify the bank and asset, where XXX is the account operator, BBBB is the bank's identification, and AAAA is the asset's identification. In this case, the attempt to transfer 5 GBP from Alice_HSBC:GBP to Bob_REVOLUT:GBP could not be completed.

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

[0160] Generating further metadata for two different banks The payment processing resource 106 accesses the key storage module 122 in response to requests for cryptographic keys corresponding to "Revolut.com" and "HSBC". This is step S400.

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

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

[0163] Next, payment processing resource 106 modifies the payment instruction dataset to include further metadata detailing two additional payments. The metadata details that the first payment is 5 GBP from Alice to HSBC, which is a payment from Alice's HSBC account but is signed by the HSBC key retrieved from key storage module 122, as it is not a payment already signed by Alice, i.e., a payment to Bob. The metadata further details that the second payment is from HSBC to Revolut (5 GBP, i.e., 5 GBP is deducted from the HSBC account), which is signed by the Revolut.com key retrieved from key storage module 122. The metadata further details that a further payment is made from Revolut to Bob's Revolut account (i.e., Bob's balance is increased by 5 GBP, which Revolut must then deduct from his HSBC account). This is signed by Bob's key. This means that the discrepancies between the data identified in step S326 are resolved by the payment processing resource 106. This is step S404. In other words, once the existence of a discrepancy is determined, the payment processing resource 106 resolves the discrepancy to ensure that the banks match and the amounts match.

[0164] Modifying the payment instruction dataset to include additional metadata using the template described above means that 5 GBP is paid from Alice_HSBC:GBP to HSBC_HSBC:GBP, then 5 GBP is paid from HSBC_HSBC:GBP to HSBC_REVOLUT:GBP, and then HSBC_REVOLUT:GBP is paid to Bob_REVOLUT:GBP, which means that the bank identification information and asset identification information are balanced and the transaction can be completed.

[0165] Since step S326 initially returned a negative result due to a lack of matching banks, the payment protocol module 120 must restart to evaluate the payment instruction dataset in light of the payment protocol. The payment instruction dataset has already returned a positive determination regarding the satisfaction of the zero-sum rule and Alice's spending limit, as shown in relation to steps S322 and S324. Now that the payment instruction dataset has been modified to resolve the lack of matching between banks and to include the payments introduced by the payment processing resource 106 to ensure that the asset identification information and banks are balanced, the payment processing module 120 moves on to step S406, where the cryptographic signatures of Alice and Bob are verified.

[0166] The payment processing module 120 verifies Alice and Bob's cryptographic signatures by generating a hash for each signature and comparing the hash to the one stored in the record generated in steps S200 to S214. This also verifies Alice and Bob's identities. 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 client's identity. The payment processing module 120 also uses similar techniques to verify the signatures of two banks, namely HSBC and Revolut.

[0167] Once step S406 is complete, the payment processing resource 106 enables the payment of 5 GBP from Alice to Bob to be made according to the payment instruction dataset. In other words, the payment processing resource 106 resolves the lack of match in the payment instruction dataset by applying two further payments to resolve the lack of match and by making the payment instruction dataset suitable for making payments using the payment instruction dataset.

[0168] Rendezvous transaction between two banks Next, in step S408, the payment processing resource 106 retrieves blockchain transactions from blockchain 112 for Alice and Bob, respectively. This is illustrated with reference to the illustrative schematic diagram in Figure 4b.

[0169] Alice's blockchain transaction 602 includes the dust output (Tx0, Alice), and Bob's blockchain transaction 604 includes the 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 the dust output (Tx0, HSBC). Revolut's retrieved blockchain transaction 610 includes the dust output (Tx0, Revolut).

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

[0171] Alternatively, similar to the first example, payment processing resource 106 may generate new dust transactions using a hierarchical determinism (HD) keychain, along with dust that does not form part of an existing event stream.

[0172] The relationship between the dust transaction chain and the event stream has already been clarified by referring to Figure 3d.

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

[0174] A dust input using Alice's dust output is denoted as (Tx1, Alice), and a 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 a dust input corresponding to HSBC, denoted as (Tx1, HSBC), and a dust input corresponding to Revolut, denoted as (Tx1, Revolut).

[0175] Funds for Rendezvous blockchain transaction 606 are added by payment processing resource 106 and refunded to payment processing resource 106. This means that if Rendezvous blockchain transaction 606 is sent to blockchain 112 for activation, any miner fees may be deducted after activation of Rendezvous blockchain transaction 606.

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

[0177] Additionally, payment processing resource 106 adds an output to blockchain transaction 606 that can be certified as unavailable. This is used as a data carrier 612. Each data carrier may be identical, based on the same data, and based on the same payment instruction dataset. A data carrier may hold several different pieces of data based on the streamState of the particular data stream to which the carrier is attached, the streamState being based on the previous streamState and / or index (or sequence number) and / or individual salts used for notarizing that data carrier. Alternatively or additionally, to add a data carrier for each of the parties that provide input to blockchain transaction 606, further outputs that can be certified as unavailable may be added to correspond to those parties. That is, each data carrier may contain data relevant to each party, in that each data carrier may differ depending on the party. For example, the difference may be that a data carrier for Alice contains data relevant only to Alice, i.e., Alice's name and Alice's account number, and a data carrier for Bob contains data relevant only to Bob, i.e., Bob's name and Bob's account number.

[0178] Similar to the first example, the data payload held within the data carrier (i.e., the hash of the payment instruction metadata) is held in the transaction's unavailable OP_RETURN output, which means the data payload can then be stored on the blockchain as an unavailable output.

[0179] The data within 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 output, which can be proven to be unavailable, allows the rendezvous transaction 606 to carry the hash of the payment instruction dataset within the transaction, and allows the hash to be stored on the blockchain. This means that the payment instruction dataset, and by extension the payment record, is stored on the blockchain. This means that the payment record benefits from the immutability of the blockchain.

[0180] Then, blockchain transaction 606 may be checked to verify that the transaction and the user correspondence with the accounts provided by HSBC and Revolut are correct and that they correspond to the users, namely Alice and Bob. This is step S412.

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

[0182] In this example, Alice, Bob, and HSBC each have their own event streams, but if they don't, their event streams may be initialized. That is, 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 an event stream (E-Revolut).

[0183] The payment processing resource 106 synchronizes the payment with the event streams E-Alice, E-Bob, E-Revolut, and E-HSBC by using rendezvous transaction 606 to append an entry containing a hash of the payment instruction metadata contained in the data carrier of blockchain transaction 606 to each of those event streams. This is step S418, which is schematically shown in Figure 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 at different positions (also known as indices) within each event stream. This is because 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 with respect to an individual. After the number of entries appended to an event stream exceeds a predetermined amount, the bank may choose to start a new event stream.

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

[0185] Next, the payment processing resource 106 generates an identifier for each entry added to the event stream. This is step S420. The identifier may be alphanumeric or 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 SHA256 encryption, the identifier may be generated by applying further SHA256 encryption to the hash of the payment instruction metadata. In other words, the identifier may be a hash of the hashes of the payment instruction metadata.

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

[0187] Next, we will describe a further illustrative scenario where Alice pays Bob 5 GBP, but Bob's account is managed by HSBC and is a Euro account, not a GBP account.

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

[0189] In other words, the payment protocol module 120 checks whether the payment-related data matches between the two parties in the transaction (in step S326) by checking the fields in the data corresponding to the parties. It is found that Alice and Bob's accounts have different currencies. In other words, Alice has an account with HSBC in GBP, and Bob has an account with HSBC in Euros, meaning they are the same bank but have different currencies, and therefore 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. Then, the payment processing resource 106 generates additional metadata to be added to the payment instruction dataset.

[0191] Generating further metadata when accounts have different currencies The payment processing resource 106 accesses the key storage module 122 by requesting cryptographic keys corresponding to accounts owned by HSBC with respect to GBP and accounts owned by HSBC with respect to EUR. This is step S500.

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

[0193] In other words, in this case, the assets do not have the same identification information (because GBP and EUR are not the same currency), but Alice and Bob certainly have the same bank. This is why step S326 results in a negative outcome in this example. That is, because the currencies are different, the asset identification information and banks do not perfectly match.

[0194] In other words, since the types of assets must be balanced, the currencies must be balanced for step S326 to yield a positive result.

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

[0196] In step S504, the payment processing module 120 generates metadata corresponding to two further payments: the first is a payment of 5 GBP from Alice's GBP HSBC account to HSBC's GBP account (i.e., Alice returns 5 GBP to HSBC), and the second is 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 hashes with those stored in the records generated in steps S200 to 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] Since the bank and asset identification information now matches, the requirements of step S326 are met, and the payment protocol standards can be satisfied. In other words, metadata is created that matches the bank and asset identification information.

[0199] Another way to demonstrate this is to use a template (XXX_BBBB:AAAA) to represent the bank and asset identification information, where XXX is the account operator, BBBB is the bank identification information, and AAAA is the asset identification information. In other words, the attempt to transfer 5 GBP from Alice_HSBC:GBP to Bob_HSBC:EUR could not have been completed before the metadata was generated in step S504. 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 (5 GBP converted to EUR) is paid from HSBC_HSBC:EUR to Bob_HSBC:EUR, which means that the bank identification information and asset identification information are balanced, which means that the transaction can be completed.

[0200] Once step S506 is complete, the payment processing resource 106 enables the payment of 5 GBP from Alice to Bob to be made according to the payment instruction dataset. In other words, the payment processing resource 106 resolves the lack of match in the payment instruction dataset by applying two further payments to resolve the lack of match and by making the payment instruction dataset suitable for making payments using the payment instruction dataset.

[0201] Rendezvous transaction using two currencies Next, in step S508, the payment processing resource 106 retrieves blockchain transactions from blockchain 112 for Alice and Bob, respectively. This is illustrated with reference to the illustrative schematic diagram in Figure 5b.

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

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

[0204] The relationship between the dust transaction chain and the event stream has already been clarified by referring to Figure 3d.

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

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

[0207] Funds for Rendezvous blockchain transaction 706 are added by payment processing resource 106 and refunded to payment processing resource 106. This means that if Rendezvous blockchain transaction 706 is sent to blockchain 112 for activation, any miner fees may be deducted after activation of Rendezvous blockchain transaction 706.

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

[0209] Additionally, payment processing resource 106 adds outputs that can be certified as unavailable for blockchain transaction 706 for Alice, Bob, and each of the HSBC-GBP and HSBC-EUR accounts. These are used as data carriers 712a, 712b, 712c, and 712d.

[0210] Similar to the first example, the data payload held within the data carrier (i.e., the hash of the payment instruction metadata) is held in the transaction's unavailable OP_RETURN output, which means the data payload can then be stored on the blockchain as an unavailable output.

[0211] Similar to the first and second examples, the payment processing resource 106 may be configured to generate a new dust transaction using dust that does not form part of an existing event stream and an HD keychain. The combination of dust input from an existing dust chain and a new dust transaction may be used to generate blockchain transaction 706.

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

[0213] In other words, each data carrier may contain data relevant to the respective stakeholder, in the sense that each data carrier may differ depending on the stakeholder. For example, the difference might be that a data carrier for Alice contains data relevant only to Alice, namely Alice's name and Alice's account number, while a data carrier for Bob contains data relevant only to Bob, namely Bob's name and Bob's account number.

[0214] Therefore, the data carrier generates a different hash, which is generated in step S512. The output, which can be proven to be unavailable, allows the rendezvous transaction 706 to carry the hash of the payment instruction dataset within the transaction, and allows the hash to be stored on the blockchain. This means that the payment instruction dataset, and by extension the payment record, is stored on the blockchain. This means that the payment record benefits from the immutability of the blockchain.

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

[0216] Then, blockchain transaction 706 may be checked to verify that the user correspondence with the transaction and the account provided by HSBC (for both GBP and EUR) is correct and corresponds to the users, namely Alice and Bob. This is step S514.

[0217] The payment processing resource 106 issues a notification to the event stream resource 110 (in step S516) confirming that blockchain transaction 606 can be used as the basis for adding data to the event stream, namely the event streams concerning 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 don't, their event streams may be initialized. That is, Alice has the event stream (E-Alice), Bob has the event stream (E-Bob), and HSBC has event streams for both currencies, namely (E-HSBC-GBP) and (E-HSBC-EUR).

[0219] The payment processing resource 106 synchronizes payments with the event streams E-Alice, E-Bob, E-HSBC-GBP, and E-HSBC-EUR by using rendezvous transaction 706 to add an entry to each of those event streams containing a hash of the payment instruction metadata contained in the data carrier of blockchain transaction 706. This is step S518. That is, if data output 712a corresponds to Alice, data output 712a is hashed and added to the event stream for Alice. This is schematically shown in Figure 5c. Each entry contains a hashed digest of the data contained in the stream up to that entry. Such hashed digests of the stream are stored in the stream along with the entries.

[0220] Next, the payment processing resource 106 generates an identifier for each entry added to the event stream. This is step S520. As in other examples, the identifier may be alphanumeric or 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 SHA256 encryption, the identifier may be generated by applying further SHA256 encryption to the hash of the payment instruction metadata. In other words, the identifier may be a hash of the hashes of the payment instruction metadata.

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

[0222] Hereafter, with reference to Figures 6a and 6b, we will describe an exemplary scenario in which Alice uses payment processing resource 106 to send a payment to Bob. The payment may be a certain amount of gold. A certain amount of gold is an example of an asset whose transfer and payment are recorded in the manner described below.

[0223] In step S600, Alice contacts Bob to inform him that she wants to acquire 1 gram of gold in exchange for 49.20 GBP. In step S602, Bob informs Alice of the price, i.e., 49.20 GBP. Both Alice and Bob have already registered accounts with gold issuers, such as the Royal Mint of the United Kingdom, which is located at, for example, 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] Next, Alice uses the first computing device 102 to inform the payment processing resource 106 of her agreement with Bob to pay 49.20 GBP for 1 gram of gold. The first computing device 102 accesses 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 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 numerical code, or by any other preferred identifier. This is step S606. The request from device 102 to API 108 indicates the amount Alice wants to pay to Bob. The request from device 102 further indicates the account from which Alice wants to make the payment, the currency Alice wants to pay in, and the recipient Alice wants to pay, namely Bob. The amount Alice wants to pay Bob, Bob's identification information, the identification information of the account from which Alice wants to make the payment, and the currency Alice wants to pay in form a set of payment metadata that is sent to the payment processing resource 106 in step S608.

[0225] In other words, for payment processing resource 106, the asset is identified as being in GBP, and the bank is also identified.

[0226] When payment processing resource 106 receives payment metadata from Alice, it retrieves metadata from Bob's account based on the metadata provided by Alice in step S608. This is step S610. Payment processing resource 106 retrieves from Bob's account the accounts of the issuers of the currencies associated with Bob's account, namely the sterling pound (GBP) and the gold, namely the Royal Mint.

[0227] Next, in step S612, the payment processing resource 106 generates a payment instruction dataset 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 identified as "HSBC" (i.e., the same as Alice's), the currency is identified as GBP, the payment amount (i.e., the amount received by Bob) is 49.20 GBP, and the account identification information is <bob:hsbc>Provided by, the user is identified as Bob by the "kyc" value, and the agent is identified as the recipient of the payment, i.e., the individual receiving the payment. This forms a further part of the payment instruction dataset. The payment instruction dataset is optionally signed<Bob_sig> This may also include versions of the clauses and conditions signed by Bob using [the specified method / tool].

[0229] Further portions of the payment instruction dataset are formed by the details of the gold transaction. Payment processing resource 106 requests access to the issuer of Bob's gold account, i.e., Bob's gold account at the Royal Mint. Payment processing resource 106 is given a request for Bob's signature to enable the access to be granted. At that time, payment processing resource 106 may either retrieve Bob's cryptographic signature from the user profile corresponding to Bob, or retrieve Bob's cryptographic signature by a separate request to Bob for the signature corresponding to Bob's gold account. The signature may or may not be the same as Bob's signature for Bob's "HSBC" account. Bob's signature may be required in particular for large amounts of gold or gold-related commercial transactions, which may include a set of terms and conditions, and which may require certification by Alice or Bob to those terms and conditions.

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

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

[0232] Then, in step S614, a message is sent to the first computing device 102, along with a request for Alice to sign the payment instruction dataset. 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 dataset by the payment processing resource 120. The signature corresponding to Alice's gold account may be different from 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, already have 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] Next, payment processing resource 106 generates further metadata corresponding to the transfer of gold from Bob's gold account to Alice's gold account. The metadata details the payment from Alice to Bob and the transfer from one gold account to the other.

[0234] Then, in step S618, the payment processing resource 106 applies payment protocol criteria to the payment instruction dataset. In step S620, the payment processing resource 106 accesses the payment protocol module 120.

[0235] 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 withdrawn from Alice's account is equal to the amount paid to Bob's account. This is step S622. Since 49.20 GBP has been withdrawn from Alice's account and 49.20 GBP has been paid to Bob's account, the zero-sum rule is met. The amount mismatch could be due to, for example, different currencies. Thus, the payment protocol module 120 determines that the asset identification information and bank identification information match (this is because, according to the template above, Alice_HSBC:GBP balances with Bob_HSBC:GBP and Alice_MINT:GOLD balances with Bob_MINT:GOLD).

[0236] Alternatively or additionally, if Bob has only an HSBC GBP account and Alice has only a Revolut EUR account, a mismatch may occur, i.e., different asset identifiers and different asset registries may exist (i.e., payments to Bob_HSBC:GBP cannot be made from Alice_REVOLUT:EUR). In this case, payment protocol module 120 generates further metadata corresponding to the intermediary portion of the transaction. This metadata corresponds to the role that a financial broker (listed here as the first broker) plays in the transaction to resolve the currency and bank mismatch, as described above in the example where different currencies and banks cause a mismatch in asset identifiers and banks. In this example, the broker has an HSBC GBP account and a Revolut EUR account. 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, the 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 the payment of a corresponding amount of GBP from the broker's GBP account (i.e., Broker_Revolut:GBP) to Bob (Bob_HSBC:GBP), in order to match the bank's identification information and asset type. This further metadata is also signed by cryptographic signatures corresponding to those accounts.

[0237] Optionally or additionally, if the first broker only provides EUR to GBP exchanges within the Revolut account, i.e., not between different banks, then the payment protocol module 120 needs to generate additional metadata corresponding to the role performed 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), the payment from Alice's EUR account (Alice_REVOLUT:GOLD) to the EUR account held by the first broker (i.e., Revolut's EUR account identified as Broker1_REVOLUT:EUR), the payment from the first broker's GBP account (i.e., Revolut's GBP account identified as Broker1_REVOLUT:GBP) to the second broker's HSBC GBP account (Broker2_HSBC:GBP), and the payment from the second broker's GBP account (Broker2_HSBC:GBP) to Bob's HSBC GBP account (Bob_HSBC:GBP). In other words, the payment protocol module 120 may be used to construct a set of metadata to address any inconsistencies (or lack of correspondence) between aspects of the payment instruction metadata checked in step S622.

[0238] Next, the payment protocol module 120 checks that the amount being sent from Alice to Bob does not cause Alice's balance to fall below a certain minimum value. This is step S624. In other words, is Alice spending too much money on the money she is receiving from Bob? If Alice is spending too much money, i.e., if Alice's balance falls below a minimum value, the payment protocol module 120 issues an error message to Alice to let her know that she cannot spend the money she wants. Furthermore, if the credit line is being used, the minimum value can be negative. 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 changes.

[0239] Next, the payment protocol module 120 checks whether the payment-related data matches between the two parties in the transaction by checking a field 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, the asset identification information is the same, or the lack of match is resolved by the payment protocol module 120 introducing further metadata corresponding to the role that a broker can play in resolving mismatches in asset transfers where the asset identifier or asset registry does not match. When the transfer is gold, the amount of gold being transferred from Bob to Alice must complement the amount of gold added to Alice's account.

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

[0241] The payment processing module 120 verifies Alice and Bob's cryptographic signatures by generating a hash for each signature and comparing the hashes to those stored in the records generated in steps S200 to S214. This is step S628. This also verifies Alice and Bob's identities. 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 client's identity. 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 is also used, the cryptographic signature corresponding to the intermediary account is also verified.

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

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

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

[0245] Each extracted blockchain transaction may also include an OP_RETURN script, i.e., a data carrier associated with an output that can be proven to be unavailable.

[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. Rendezvous blockchain transaction 806 is generated at step S632.

[0247] Funds for rendezvous blockchain transaction 806 are added by payment processing resource 106 and refunded to payment processing resource 106. This may be subject to any miner fees after the activation of rendezvous transaction 806, if rendezvous transaction 806 is sent to blockchain 112 for activation.

[0248] Rendezvous blockchain transaction 806 includes further dust outputs using Tx1, Alice and Tx1, Bob, respectively. Rendezvous blockchain transaction 806 also includes dust outputs corresponding to dust inputs taken from the blockchain for the two gold accounts. When it is a rendezvous transaction, the indices of the input / output pairs corresponding to Alice, Bob, and the two gold accounts 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] Also, the payment processing resource 106 adds outputs that can prove that it is not available for the blockchain transaction 806 with respect to Alice, Bob, and the two gold accounts. These are respectively denoted as data carriers 812a, 812b, 812c, and 812d.

[0250] Outputs that can prove that they are not available corresponding to the brokers involved in the transaction may also be added. Those outputs that can prove that they are not available correspond to the data carriers of the brokers.

[0251] Similar to other examples, each of the data carriers may hold different dataDigests and / or streamDigests. The streamDigest may be sorted as in other examples.

[0252] Also, the blockchain transaction 806 may be generated using dust that has not already been used as the basis of an event stream. This "new dust" is used in combination with an HD key chain as described in UK Patent Application No. 2102217.3 to generate the blockchain transaction 806 as in other examples.

[0253] Similar to other examples, the data payloads (i.e., the hash of the payment instruction metadata) held within each data carrier are held in the non - spendable OP_RETURN output of the transaction, which means that the data payload can then be stored on the blockchain as a non - spendable output. Similar to the first example, holding the data payload (i.e., the hash of the payment instruction metadata) held within the data carrier in the non - spendable OP_RETURN output of the transaction means that the data payload can then be stored on the blockchain as a non - spendable output.

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

[0255] Then, blockchain transaction 806 may be checked to verify whether the user correspondence with the gold account corresponding to the transaction and what is owned by Alice and Bob is correct. This is step S636.

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

[0257] The payment processing resource 106 synchronizes the payments 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 using the rendezvous transaction 806 to add entries to each of those event streams containing hashes of the payment instruction metadata contained in each data carrier of the blockchain 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, which is schematically shown in Figure 8. Entries may also be added to the event streams corresponding to the brokers involved in the transfer of gold.

[0258] Next, the payment processing resource 106 generates an identifier for each entry added to the event stream. This is step S642. The identifier may be alphanumeric or 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 SHA256 encryption, the identifier may be generated by applying further SHA256 encryption to the hash of the payment instruction metadata. In other words, the identifier may be a hash of the hashes 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 utilize the principle of commitment chains to record transactions. The principle of commitment chains is fully described in UK Patent Application No. 2204293.1 (filed March 25, 2022), but its application to recording asset transfer events is described below.

[0261] Applying a chain of commitments to the transaction record offers the unforkable advantage associated with the dust chain technique described above, but also additional advantages. These additional advantages include 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 the data from previous and future transactions cannot be distinguished by an observer.

[0262] Above, we described four examples of varying complexity in which 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 using chains of commitments to record asset transfer events. For the sake of brevity, we will select only the fourth example described to illustrate its relationship with chains of commitments, but this should not be taken as limiting the discussion to only the fourth example.

[0263] First, using Figure 8a, we will briefly illustrate the concept of commitment chains, referring to the event streams shown in Figure 8. Each event stream corresponding to a commitment chain is off-chain, meaning it exists outside the blockchain, and represents a way to store data off-chain (immutably).

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

[0265] System 1400 in Figure 8a may be used as part of an event stream-based system for logging events, which maps events (such as asset transfer 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 considered a set of transactions, and those transactions contain information such that they can be considered a set of transactions that can be related to and / or traversed by each other. In the example considered below in relation to rendezvous transaction 1000, the chain of commitments is a set of transactions linked by data digests and state digests generated based on payment instruction metadata corresponding to recorded asset transfer events.

[0267] As explained below, a set of transactions is constructed as a "chain" in which each transaction contains (or is based on) references to the previous and next transactions. As illustrated 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 a "funding in" input 1410a-d, which pays for the transaction to be mined on the blockchain. Each transaction may also include a data payload 1412a-d, which may be held in the unusable output of each transaction. The data payload 1412a-d may be prefixed with the OP_RETURN opcode, which is a script opcode that can be used to write arbitrary data onto the blockchain and to mark the transaction output as invalid (i.e., unusable). Marking the transaction output as invalid (i.e., unusable) causes the data held in the payload to be immutably recorded on the blockchain when each transaction is recorded on the blockchain.

[0269] In Figure 8a, “Data and References” refers 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 dataset recorded in the corresponding event stream entry.

[0270] In short, refer to the fourth example above where Alice sends a payment to Bob regarding the amount of gold. The complexity arises again from the existence of Royal Mint accounts that require signatures. In the example, we illustrate that the asset transfer event (transfer of gold from one Royal Mint account to another) is recorded in four separate event streams, each corresponding to a chain of dust. An alternative approach is to use a rendezvous transaction to atomically synchronize the four chains of commitment and record the transfer of gold in the four chains of commitment.

[0271] Referring hereto to Figure 9, we will explain 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 by any preferred means. Each of Alice and Bob's gold accounts at the Royal Mint, as well as each of Alice and Bob's gold accounts, has a corresponding chain of commitments initialized using the commitment management module 160 in step S900. Initialization of the chain of commitments may include setting up hardware resources that can be allocated to the chain of commitments. The chain of commitments may already be initialized, or it 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 the event streams corresponding to the parties involved in the asset transfer event.

[0272] The payment processing resource 106 is configured to determine the association between the chain of commitments and each entity (in this example, Alice and Bob and their gold accounts). When 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, in which Alice contacts Bob to inform him that Alice wants to receive 1 gram of gold in exchange for 49.20 GBP. The initialization of the chain of commitments may have occurred during the execution of any of steps S600 through S642 by a preferred 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., after step S628, step 900 may be initialized as an alternative to steps S630-S642.

[0273] Each chain of commitments corresponds to an event stream corresponding to each stakeholder, which is managed by the event stream management module 110. However, to avoid ambiguity, it should be added that the chain of commitments must exactly correspond to the corresponding event stream in that the event stream may carry more information per entry than what 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, that is, steps S622, S624, S626, and S628 (as shown in FIG. 6a) are met, and the transfer of money is possible and can be recorded as an asset transfer event. This may be by accessing a flag generated by the payment processing resource 106, which indicates 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 elapsed since the first flag generated by the payment processing resource was generated.

[0274] In step S904, the payment processing resource 106 gives a request to the commitment management module 160 at the request that the transfer of money be recorded in the chain of commitments corresponding to each of the accounts of Alice, Bob, and each of the respective royal mints. A flag generated by the payment processing resource 106 may be provided to the commitment management module 160 during the execution of step S904.

[0275] The commitment management module 160 is configured to generate a rendezvous transaction 1000 that includes a funding input (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 illustrated with reference to Figure 10. The rendezvous transaction described synchronizes an event stream corresponding to a chain of commitments initialized for the parties involved in the transfer of gold. This differs from other example rendezvous transactions that synchronize an event stream linked to a chain of dust.

[0276] The rendezvous transaction 1000 shown in Figure 10 includes outputs for each of the accounts of Alice, Bob, and the Royal Mint. Each output is a data digest H Dni and state digest S ni This includes the following. The subscript i indicates the number of the person 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 output is listed as 1004, 1006, 1008, and 1010.

[0277] Each data digest and state digest is contained within the transaction's data payload, which is held within the transaction's invalid output in that it is prefixed with the OP_RETURN opcode. This is a script opcode that can be used to write arbitrary data to the blockchain and to invalidate, i.e., mark the transaction's output as invalid, i.e., unavailable. Thus, the corresponding data is immutably recorded on the blockchain.

[0278] As seen in Figure 10, each output of rendezvous transaction 1000 is based on a reference to the corresponding previous blockchain transaction (i.e., it could be the previous transaction in each chain of commitments) through the use of the state digest of the corresponding link in the chain of commitments. The previous blockchain transaction can be a rendezvous transaction or a non-rendezvous transaction. As shown in Figure 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 to the funding input of the next transaction reference. As shown in Figure 10, these 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 following transactions will become clear in the section below that describes the generation of data digests and state digests. The inputs to each transaction and to rendezvous transaction 1000 may be provided by the platform. If the inputs given 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 a data digest and a state digest, the commitment management module 160 retrieves the payment instruction dataset generated in steps S600 to S628. This is step S908. As will be described below, the payment instruction dataset is then used to determine the data digest and the state digest.

[0280] In step S910, the data digest is (data item D ni It is derived using a mathematical formula with the payment instruction dataset (listed as follows). H Dni := H 2 (H 2 (Di)||H 2 (SALT)) In the expression, || is the concatenation of the elements before and after it, H 2 This is a double hash function, but it is also possible that a single hash function (H) is used. Di is the payment instruction dataset for the corresponding party. That is, if i = 1, 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 understand that other one-way functions may be used. As used throughout this specification, “hash” means hashing at least once, and may include several applications of each hashing application. Hashing more than once provides resistance to stretching attacks. Instead of hashing more than once, a different hash function or method that is not vulnerable to stretching attacks may be used. For example, SHA-3 and / or HMAC (optionally using the same or different salts as keys) provide such functionality. A further alternative is to generate a Merkle tree with leaf items {payment instruction dataset, salt}, where the data digest is the root of the Merkle tree.

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

[0283] A different salt may be chosen 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 Alice, Bob, and their respective gold accounts.

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

[0285] Next, in step S912, the state digest is derived as the root of the Merkle tree, as shown in Figure 11, with the leaves of the Merkle tree based on references to the previous transaction, references to the next transaction, and client data. Alternatively or additionally, the state digest may be derived based on a JSON object and salted paths.

[0286] In particular, the Merkle tree is a reference to the previous transaction, a reference to the next transaction, and a state client data digest (H D Based on '). The state client data digest is the data digest (H D ) and optionally, any metadata related to the event and / or event stream. The state client data digest is described in more detail below.

[0287] The state digest (S) (for convenience only, the subscript ni is ignored) is calculated according to the following formula (referencing the previous transaction as an example, state client data digest (H) D ')(again, simply for convenience, the subscript ni is ignored), and it can be determined using the reference to the next transaction.

[0288]

number

[0289] In the formula, the "Merklize" function generates a Merkle root from an ordered set of data elements as leaves.

[0290]

number

[0291] S is an ordered set of leaves based on elements. The Merklize function may also accept additional input parameters corresponding to other data that may be used in the computation of S. For example, this may include secrets that prevent a malicious third party from branching the stream when the restoration protocol is called. Each leaf is first double-hashed in the Merklize function. Notably, because of how hashes and Merkle trees work, the order of the set of inputs to it matters, and therefore, whenever a Merkle tree is created, recreated, or validated, the order of the inputs must be the same 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 a call to the Merklize function, as described below, each leaf node is based on that version number. The preimage of each leaf node may have the version number prefixed to it. Alternatively, the preimage of each leaf node may have the version number appended to it. Advantageously, the use of version numbers allows the state digest to be associated with a particular version (since different version numbers result in different Merkle tree roots, even if the same input data is used). The use of version number changes may be used in conjunction 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 associated with a unique specification of the resulting Merkle tree.

[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] This generates a Merkle tree T. 1.2. Route R of the wooden T T Obtain it. 1.3. R T Return 2. Else: 2.1. Update each leaf in the list of leaves by adding a version number to the beginning: 2.1.1. PREV ← v||PREV 2.1.2.

[0300]

number

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

[0302]

number

[0303] 2.3. Route R of the wooden T T Obtain it. 2.4. R T Return

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

[0305] The function GenMerkleTree can be understood as a standard way to generate a Merkle tree given a set of leaf data items. The first step of GenMerkleTree is the set of leaves (in this example

[0306]

number

[0307] This may involve hashing each of the items in ).

[0308] Referring to Figure 11, an example of a generated Merkle tree 1100 is shown, with leaf node PREV 1102, H D This is illustrated using 1104 and NEXT 1106. The root of the Merkle tree, 1108, is the state digest (S) used for each of the outputs of rendezvous transaction 1000. This exemplary Merkle tree is constructed as a binary tree, with each node having two children (except for the leaves). Since 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 understand that one does not need to strictly adhere to this presented form of the Merkle tree, and that other forms may exist that may function similarly. As considered 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, a state digest can be generated by hashing the protoimage, which is constructed by concatenating the objects on which the state data is based. Therefore, 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 expression is:

[0310]

number

[0311] This is one possible form. Optionally, the salt may also be incorporated into the preimage. For example, the salt may be attached to the beginning or end of the preimage.

[0312] As a further alternative to the Merkle tree root, state digests can be generated using hash chains or canonical JSON structures. Hash chains are constructed such that each intermediate hash result is prefixed with the item on which the state digest is based. For example, the state digest might include references to previous transactions, client data digests (H D '), and if based on a reference to the next transaction, the expression is,

[0313]

number

[0314] This is a possible form. Optionally, a salt is incorporated into the hash chain. Optionally, a salt is incorporated by adding it to the beginning of each intermediate preimage.

[0315] PREV is a reference to the previous transaction, and may be the state data of the aforementioned previous transaction being referenced. In the rendezvous transaction 1000 shown in Figure 10, S n1 S is a component of transaction 1012, which is the previous transaction from the chain of commitments corresponding to Alice. n1-1 Based on S n2 Similarly, S n2-1 Based on this, the same applies below. In other words, a reference to a previous transaction is the state data of the previous transaction being referenced, as this data is recorded on the blockchain. A reference to a previous transaction is optionally called a reference to a parent transaction, and the current transaction is its child.

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

[0317] [Table 1]

[0318] Optionally or alternatively, the original image of PREV is a JSON structure and / or can be represented using a JSON structure. The JSON structure includes the data options described above. Advantageously, using a JSON object offers the ability to easily add and reference more data elements if they are to be added.

[0319] NEXT is a reference to the next transaction. Conveniently, many of the components of the next transaction are unknown (as a result of the fact that the next transaction will exist in the future and of the data sent by the client), and therefore, the unknown components cannot be used as references. However, one or more input UTXOs used to fund the transaction can be predetermined and, when that transaction is committed to the blockchain, are unique to that transaction, i.e., the "NEXT" transaction. The input UTXO may be referenced by an outpoint. The outpoint includes the transaction ID (called TxID) of the transaction to which the UTXO belongs and the index (called vout) of the output on the referenced transaction. A reference to the next transaction is optionally called a reference to a child transaction, with the current transaction being the parent.

[0320] Similar to references to previous transactions, a reference to the next transaction may be considered a null reference if there is no next transaction to reference (i.e., the current transaction is at the end of the commitment chain). A null reference may be a zero column, which may be the same size as the next transaction reference if it were not null (i.e., the size of the transaction outpoint). The column may be 32 bytes long. The table below explains NEXT.

[0321] [Table 2]

[0322] Optionally or alternatively, the prototype of NEXT is a JSON structure and / or can be represented as a JSON structure. The JSON structure contains the data options described above. Advantageously, the use of a JSON object offers the ability to easily add and reference more data elements if they are to be added.

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

[0324] [Table 3]

[0325] If several metadata elements exist, they are listed as M1, M2, and so on. This is illustrated by a Merkle tree in Figure 12.

[0326] The exemplary metadata elements may include one or more of the following: • whenRecorded -- The time when payment instruction metadata was received from the client and / or recorded in the off-chain log. • appVersion -- Version number of the commitment chain, • seed -- The seed value used at the beginning of event stream generation. • delWriteIV -- Initial value used to generate a delegated authorization 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 times when an event stream is considered open for writing. • delAuthIndex -- An index of the delegated token used by the client to send the event. ·TxIDcreate -- The transaction ID of the first transaction in the commitment chain, and / or • index -- The index of the current event in the event stream (not necessarily the same as the index in the commitment chain, as not all events need to be recorded in the commitment chain). • nextHashSalt -- The hash of the salt to be used in the next event. The salt may be pre-generated for the next event in the commitment chain, and this salt is hashed and used to generate the Merkle tree of the state client data digest. Those skilled in the art will understand that other metadata elements may also be used.

[0327] Referring to Figure 12, the root is the state client data digest (H) (used in the state data Merkle tree 1100 as described above with reference to Figure 11). D An exemplary Merkle tree 1200, which is ')1104, is shown.

[0328] The set of leaf nodes 1206, 1208, 1210, 1212, and 1214 is a data digest (H D ) and the leaf nodes of the metadata are arranged so as to be interleaved with the salt. This interleaving enhances the security of the data within 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 description of the protocol regarding the chain of commitments, H D If (data digest) is to be publicly stored on a transaction, then a third party can access M1, ..., M m Given that the values ​​of these metadata can often be predictable or easily counted (for example, if one of the metadata elements is a timestamp, this can be inferred if given the time the transaction was sent to the blockchain, or if one of the metadata elements is a monotonically increasing index, this can be inferred from previous states), it is possible to brute-force these metadata values. If a third party brute-forces these values, the value H D If it is possible to correctly reconstruct the '(i.e., the root of the tree), then a third party can access metadata values ​​M1, ..., M m You have successfully confirmed your knowledge regarding this. In some cases, this metadata can be sensitive; for example, the whenRecorded or writeAccessControl.region property may be used as metadata in an EventStream transaction and could be important to a malicious third party.

[0329] The protoimages that form the basis of leaf nodes may have the protocol version number prepended to them.

[0330] Therefore, the process for creating an example Merkle tree 1200 can be described as follows: DataDigestCommit(H D , SALT, M1, ..., M m , v): 1. Generate m copies of SALT. 2. {H D , SALT, M1, SALT, ..., M m Order the data items like , SALT} 3.

[0331]

number

[0332] generate 4.

[0333]

number

[0334] Return

[0335] Notably, the same Merklize function is used here, as was done when creating the state digest above. Since the same Merklize function is used, the preimage of the leaf nodes is hashed, optionally twice. The Merklize function is H' D It may accept additional inputs corresponding to other parameters that may be used in the calculation.

[0336] Similar to the considerations for generating Merkle trees above, there may be several alternatives to Merkle trees, including concatenating inputs, hashing the results, and generating a hash chain.

[0337] Status Client Data Digest H D For the generation of ', the protocol version number may be used (compared to the state digest (S) considered when v = null is given). The state digest (S) is the state client data digest (H D Since it depends on '), H D By making ' dependent on the protocol version number (v), S also ends up depending on v (even if it is not directly used in its generation). Here, "depends on" means H D This means that S is different if the same input is used except for the different protocol version numbers used to generate '. This allows S to depend on the protocol version number, as long as the protocol version number is not used twice to generate the 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 may have the hash of the payment instruction dataset appended to them by accessing the event stream management module 110 by request, which adds the hash of the payment instruction dataset to each event stream. The state digest and 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 the commitment chains corresponding to Alice, Bob, and the gold accounts, in that it is linked to the corresponding event stream entries. The rendezvous transaction is linked to the event stream entries in an immutable and secure manner, and the asset transfer event is recorded immutably and securely without disclosing details.

[0339] In other words, following a determination by the payment processing resource that the criteria for 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 accounts), and the two gold accounts corresponding to Alice and Bob. The output of rendezvous transaction 1000 is generated and includes a payment instruction dataset, a state client data digest, and elements 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, as shown in Figure 13, there are alternative forms of the rendezvous transaction 1300 that may be generated by the commitment management module 160. Instead of different inputs and outputs for each chain of commitments, as in the rendezvous transaction 1000, a single transaction input 1302 and output 1304 may be used. In this case as well, the input may be provided by the commitment management module 160.

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

[0342] The aspects and embodiments described above are illustrative, not limiting, the Disclosure, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the Disclosure as defined by the appended claims. In the claims, reference numerals in parentheses shall not be construed as limiting the scope of the claims. Words such as “comprising” and “comprises” do not exclude the existence of elements or steps other than those enumerated in any claim or throughout this Spec. In this Spec. “comprise” means “includes or consists of,” and “comprising” means “including or consisting of.” A singular reference to an element does not exclude a plural reference to such element, and vice versa. The Disclosure may be implemented by hardware comprising several different elements and by a appropriately programmed computer. In device claims that enumerate several means, some of these means may be embodied by one same piece of hardware. The mere fact that specific means are described in different dependent claims does not indicate that combinations of these means cannot be used advantageously. [Explanation of symbols]

[0343] 100 Systems 102 The First Computing Device 102a Computer equipment 102b Computer equipment 103 Users, Entities, Stakeholders, Agents 103a User, entity, first party 103b Users, Entities, and Second Parties 104 Second Computing Device 105 Client Applications 106 Payment processing resources, networks, Bitcoin networks, blockchain networks 108 Application Programming Interface (API) 110 Event Stream Resources, Event Stream Manager 110a Event Stream 112 Blockchain 120 Payment Protocol Modules, Payment Processing Modules 122-key storage module 124 Payment Data Store 126 nodes, Bitcoin nodes, blockchain nodes 130 Packet-Switched Networks 132 Blockchain network, Bitcoin network, peer-to-peer (P2P) network, network 140 Database Management Systems (DBMS) 150 blockchains, Bitcoin blockchain Blocks 151, 151n, and 151n-1 Transactions 152, 152i, and 152j 153 Genesis Block (Gb) 154 Ordered Set of Unpublished Transactions 155 Block pointers 160 Commitment Management Module 401 Protocol Engine 402 Blockchain Transaction 404 Blockchain Transaction 406 Rendezvous Blockchain Transaction 412, 412a, 412b data carriers 450 node software 451 Protocol Engine 452 Script Engine 453 stacks 454 Application Level Determination Engine 455 Blockchain-related functional modules 455C Consensus Module 455P propagation module 455S Storage Module 502 Events 504 Blockchain Transaction 506 Edge 602 Blockchain Transactions 604 Blockchain Transactions 606 Rendezvous Blockchain Transaction 608 blockchain transactions 610 blockchain transactions 612 Data Carriers 702 Blockchain Transactions 704 Blockchain Transactions 706 Rendezvous Blockchain Transaction 708 blockchain transactions 710 blockchain transactions 712a, 712b, 712c, 712d data carriers 802 Blockchain Transactions 804 Blockchain Transactions 806 Rendezvous Blockchain Transaction 808 blockchain transactions 810 blockchain transactions 1000 Rendezvous Transactions Outputs 1004, 1006, 1008, and 1010. Transactions 1012, 1014, 1016, 1018, 1020, 1022, 1024, and 1026 1100 Markle tree 1102 Leaf node PREV 1104 State Client Data Digest, Leaf Node H D ' 1106 Leaf Node NEXT 1108 Route of the Markle tree 1200 Markle trees 1206, 1208, 1210, 1212, 1214 leaf nodes 1300 Rendezvous Transactions 1302 Transaction Input 1304 Transaction Output 1400 System 1404 Off-chain (i.e., not on the blockchain) data storage systems 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 that records an asset transfer event involving at least a first user and a second user, which is performed by computing resources, The step of receiving instruction data, The aforementioned instruction data relates to the requested asset transfer event, The instruction data includes a first set of metadata relating to the sender of the asset, and a second set of metadata relating to at least one recipient of the asset. The steps include: each of the sender and the recipient being associated with an account related to the asset registry; The steps of associating the sender of the asset with a first chain of commitments and associating the receiver of the asset with a second chain of commitments, Each commitment chain involves steps that associate the event stream with multiple blockchain transactions, A step of comparing the first set of metadata with the second set of metadata in order to determine whether the transfer of the asset from the sender to the at least one recipient can be made in accordance with the transfer protocol, The transfer protocol includes a step of defining at least one criterion that enables an asset transfer event to occur, The steps include determining one or more corresponding items between each set of metadata based on a comparison between each set of metadata according to the transfer protocol, A step of generating a rendezvous blockchain transaction with respect to each of the sender and the receiver, which includes at least one input and at least one output, The at least one output includes data relating to the first set of metadata and the second set of metadata, The data relating to the first set of metadata and the second set of metadata is based on data relating to future blockchain transactions, and the steps are as follows: The steps include adding the aforementioned rendezvous blockchain transaction to the first chain of commitments and the second chain of commitments, respectively. The steps include associating the aforementioned rendezvous blockchain transaction with each entry in each event stream, and Methods that include...

2. The method according to claim 1, wherein the rendezvous blockchain transaction is transmitted to the blockchain.

3. The output corresponding to the sender includes a data payload containing metadata generated based on the first set of metadata, The method according to claim 1, wherein the output corresponding to the receiver includes a data payload containing metadata generated based on the second set of metadata.

4. The method according to claim 3, wherein the metadata includes a data digest and a state digest.

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.

6. The method according to claim 5, wherein the data digest is generated based on a combination of the first set of metadata and the second set of metadata and a salt.

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, The double hash of the combination of the first set of metadata and the second set of metadata is concatenated with the double hash of the salt. The method according to claim 6, including the method described in claim 6.

8. The method according to claim 4, wherein the state digest is generated based on the data digest and future transactions.

9. The method according to claim 4, wherein the state digest is further generated based on the previous transaction.

10. The method according to claim 4, wherein the state digest is the root of the Merkle tree.

11. The step of determining the correspondence of one or more items between each set of metadata is: i) The currency of payment identified within each of the aforementioned 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, iii) Identifiers 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 the following.

12. The aforementioned computing resources If it is determined that the transfer cannot be performed in accordance with the transfer protocol, The method according to claim 1, which generates an additional set of metadata to resolve the lack of consistency with the aforementioned transfer protocol.

13. The method according to claim 12, wherein the generation of the further set of metadata includes generating metadata that enables conversion between a first currency and a second currency.

14. The method according to claim 12, wherein the generation of the further set of metadata includes generating metadata for one asset registry to record the transfer of a given asset to another asset registry.

15. A system configured to implement the method described in any one of claims 1 to 14.

Images