Method and system for synchronizing user event streams with dust-based rendezvous transactions - Patents.com

Abstract

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

Description

[Technical field]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0016] In an embodiment, a method is provided that further includes initializing a first event stream corresponding to the sender and a second event stream corresponding to at least one receiver. The embodiment may alternatively or additionally include accessing the first event stream or the second event stream corresponding to the sender and receiver, respectively. The event streams may be implemented using any suitable hardware or data structure. The method provided by the embodiment may further include comparing the first set of metadata and the second set of metadata to determine whether a transfer from the second set to the at least one receiver can be performed according to a transfer protocol. Based on a comparison between the respective sets of metadata according to a payment protocol, the method provided by the embodiment includes determining one or more corresponding items between the respective sets of metadata. The transfer protocol may define at least one criterion that must be satisfied to allow an asset transfer event to occur. The at least one criterion may require that the sender and receiver are associated with accounts related to the same asset registry. For example, the at least one criterion may require that the accounts are of the same bank. The at least one criterion may require that the accounts are associated with the same type of asset. For example, such criteria may require that both accounts be denominated in Pound Sterling (GBP).

[0017] An event stream has a blockchain-enabled append-only log, where data recorded in a blockchain transaction is appended to a chronologically ordered log. That is, an event stream can record data recorded in the blockchain in chronological order, i.e., in the order in which they appeared on the blockchain. This means that the order of transactions in a block on the blockchain is usually reflected by the corresponding index of the corresponding event recorded in the event stream. However, this does not necessarily have to be the case. Two simultaneous events mean that the order of events is not reflected in the order of transactions in a block. For example, an event on the event stream with index N+1 may be recorded in block B, while an event with index N (i.e., recorded in the event stream before the other event) may be recorded in block B+1.

[0018] Event streams may be implemented using any suitable data structure. An event stream may contain a set of entries stored in a sequence, with each entry in the sequence referenced in the sequence by a monotonically increasing number. That is, the first entry in an event stream is entry 1, the second entry is entry 2, and so on. The use of the underlying blockchain means that it can be guaranteed that individual entries in an event stream have not been modified since they were written, that entries have not been inserted between previously adjacent entries, that entries have not been removed, and that entries have not been reordered. It also means that unauthorized parties cannot append events to an event stream. Event streams may be off-chain, i.e., not on the blockchain. Malicious parties can append events to an event stream, but the user who initialized the event stream must sign all events appended to the event stream in a way that makes instances of malicious parties attempting to append events detectable.

[0019] Based on the determined correspondence, a previous blockchain transaction can be identified for the sender and the at least one receiver. The method provided by the embodiment further comprises generating a further blockchain transaction for the payment event, the further blockchain transaction including a dust input for each of the sender and the at least one receiver using a dust output associated with the previous transaction and a respective unspent transaction output (UTXO) corresponding to the dust input, and an unspent transaction output associated with the transfer event, and synchronizing the respective first and second event streams to the payment event.

[0020] The above method allows for the immutability of the blockchain to be relied upon and allows for recording of asset transfer events that do not necessarily relate to cryptocurrency payments: transfers are performed from one account associated with an asset registry to another account associated with an asset registry and can then be securely verified against an event stream that records metadata related to the payment.

[0021] The dust input generally corresponds to the minimum amount of cryptocurrency that a miner is willing to process at any given time. It can be seen that this value changes over time and is therefore not limited to a specific value. The dust input generally corresponds to the minimum amount of cryptocurrency that a miner is willing to process, and the dust input is practically indivisible so that miners do not process smaller values. This means that it is practically impossible to split the dust input, and it is more difficult for a malicious third party attacker to split the chain using the dust input, since there is no smaller dust input that a miner can process. In other words, since the dust input is indivisible, the amount of cryptocurrency corresponding to the dust input changes over time, and the minimum amount that a miner is willing to process at any given time can be used to support the dust input and maintain security.

[0022] In some embodiments, a computer-implemented method of transferring assets from a first account associated with an asset registry to a second account associated with the asset registry is provided. The method provided by the embodiments is performed by a first computing resource associated with a sender of the transfer. The method provided by the embodiments includes receiving a request for the transfer of assets from a second computing resource configured to perform the method of the first aspect.

[0023] The method provided by the embodiment further comprises: (i) the asset registry associated with at least one sender account used for the transfer; (ii) the value of the assets withdrawn from the Sender Account; and (iii) Indicators of assets to be used for the transfer The method includes generating a first set of metadata indicative of the

[0024] The method provided by the embodiment further comprises: transmitting a first set of metadata to a second computing resource to initiate the transfer; receiving instruction data related to the requested transfer from the second computing resource; signing the instruction data with the cryptographic signature to generate signed instruction data; sending the signed instruction data to a second computing resource; Equipped with.

[0025] To initiate the transfer, a first set of metadata is sent to a second computing resource to request required instructional data from a user of the second computing resource.

[0026] The above method allows computing devices to enable the transfer of assets and benefit from the immutability, confidentiality and security of the approach provided by the first aspect.

[0027] In some embodiments, a computer-implemented method of verifying an asset transfer event recorded according to a first aspect, the method being performed by a first computing resource, the method comprising: receiving a request to verify an asset transfer event, the request including an identifier associated with the asset transfer event from the computing resource; searching event stream entries associated with the identifier to extract metadata associated with the asset transfer event; sending a confirmation of the asset transfer event to a computing resource; Equipped with.

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

[0029] [Figure 1a] FIG. 1 illustrates a system according to an embodiment. [Figure 1b] FIG. 1 illustrates a node configured to implement Bitcoin software to enable blockchain transactions. [Figure 1c] FIG. 1 illustrates a blockchain network. [Diagram 2] 4 is a flow diagram detailing an account set-up according to an embodiment. [Figure 3a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 3b] 1 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment; [Figure 3c] FIG. 2 illustrates a rendezvous transaction according to an embodiment. [Figure 3d] FIG. 1 illustrates the relationship between chains of dust transactions and event streams. [Figure 3e] FIG. 2 illustrates multiple event streams corresponding to participants in a transaction. [Figure 4a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 4b] FIG. 2 illustrates a rendezvous transaction according to an embodiment. [Figure 4c] FIG. 2 illustrates multiple event streams corresponding to participants in a transaction. [Figure 5a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 5b] FIG. 2 illustrates a rendezvous transaction according to an embodiment. [Figure 5c] FIG. 2 illustrates multiple event streams corresponding to participants in a transaction. [Figure 6a] 4 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment. [Figure 6b] 1 is a flow diagram detailing a payment from a sender to a receiver according to an embodiment; [Figure 7] FIG. 1 illustrates a rendezvous blockchain transaction generated by an embodiment. [Figure 8] FIG. 2 illustrates an event stream for participants in a transaction according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0032] A sender of an asset may be associated with a first event stream and a receiver of an asset may be associated with a second event stream. Association with an event stream may mean that a user holds a cryptographic key that allows the user to append data to that event stream and / or that the user can initialize and / or terminate an event stream to which data is appended by the user or computing resources operated by the user. Initialization of an event stream may include configuration of computing resources necessary to implement the event stream.

[0033] The method further comprises initializing a first event stream corresponding to the sender and a second event stream corresponding to the at least one receiver. The event streams are implemented using any suitable hardware or data structure. The method further comprises retrieving details of the first event stream corresponding to the sender and / or retrieving details of the second event stream corresponding to the at least one receiver.

[0034] The method further comprises comparing the first set of metadata and the second set of metadata to determine whether a transfer from the sender to the at least one recipient can be performed according to a transfer protocol, determining one or more corresponding items between the respective sets of metadata based on the comparison between the respective sets of metadata according to the transfer protocol, and identifying at least one prior blockchain transaction for the sender and the at least one recipient based on the determined correspondence, the prior blockchain transaction including the dust output. Prior blockchain transactions are identified for the sender and the recipient. Blockchain transactions are also identified for an asset registry and an issuer of an asset associated with an account corresponding to the sender and the recipient.

[0035] The method further comprises generating a further blockchain transaction for the asset transfer event, where the further blockchain transaction, for each of the sender and at least one recipient, uses dust inputs, dust outputs associated with the previous transaction, respective unspent transaction outputs (UTXOs) that correspond to the dust outputs (i.e., the transaction indices match), and unspent transaction outputs associated with the asset transfer event; and synchronizing the first and second event streams, respectively, to the asset transfer event.

[0036] Advantageously, the method according to the first aspect allows for recording of asset transfer events. Because the recording is recorded in a data stream associated with the blockchain, the recording of the asset transfer event can rely on the immutability of the blockchain and need not be related to cryptocurrency payments. Transfers can be made from one account to another and can be securely verified against an event stream that records metadata associated with the payment.

[0037] Optionally, based on a comparison between the respective sets of metadata according to a transfer protocol, the method further comprises: i) the identity of the assets identified in each set of metadata; ii) the value of the assets transferred from the account corresponding to the sender and the value of the assets requested from the account corresponding to the recipient, and iii) Identifiers of the asset registries associated with the sender and recipient accounts determining a correspondence between at least one of the

[0038] Examples of asset registries include a bank, a gold vault, or another registry detailing asset ownership. Determining a correspondence between asset identities may include determining that the currencies used by the sender and receiver are the same. Determining a correspondence between the value of the assets being transferred may include determining that the amount of currency paid from the receiver's account is equal to the amount of currency paid to the sender's account, or vice versa. Determining a correspondence between asset registry identifiers may include determining that the sender's and receiver's banks are the same, or that a precious metals mint (e.g., the Royal Mint's gold vault) is used as a registry for the precious metals accounts of both the sender and receiver.

[0039] Advantageously, this allows transfers of assets to be recorded only if a correspondence can be determined between at least one of the identity of the assets, the amount of the assets, and the identity of the party providing the asset registry, meaning that in this manner only transfers where the terms of the transfer are consistent will be recorded.

[0040] Optionally, the further blockchain transaction may be a rendezvous blockchain transaction for synchronizing multiple event streams, the transaction including at least one data carrier including metadata associated with the asset transfer event, the data carrier may include a hash of the metadata associated with the asset transfer event.

[0041] A rendezvous transaction is a blockchain transaction that contains multiple dust chain input / output pairs and an output marked with an OP_RETURN opcode to invalidate the output and allow the addition of a data carrier. The OP_RETURN opcode immediately terminates the execution of the corresponding redemption script and invalidates the script, i.e. the output cannot be redeemed. This means that the output cannot be used and the data carrier remains on the blockchain as part of the rendezvous transaction. Dust chain input / output pairs can have the same index in the transaction and can advance input funds and exchange outputs, respectively. The data carrier may be a final output. Multiple dust chain inputs that form a rendezvous transaction may each be from different event streams.

[0042] Advantageously, the effect of this is that multiple parties to a transaction can be integrated into the method by resources, with each party benefiting from the immutability of the blockchain to record the transaction in their own event stream without compromising security or confidentiality. By using a hash of the metadata, the metadata of a transaction can be proven without exposing the details of the transaction to malicious actors. Given that two different sets of metadata will not produce the same hash, this means that an asset transfer event can be verified by any party who wishes to show that data that produces a hash of the metadata is present on the blockchain.

[0043] Optionally, synchronizing the respective first and second event streams with the asset transfer event using the rendezvous transaction includes appending a representation of metadata associated with the asset transfer event to each of the respective first and second event streams.

[0044] Advantageously, this means that a representation of the metadata can be used to verify that a payment has been made. The representation of the metadata may be a hash of the metadata. The effect of using a hash of the metadata means that the transfer can be recorded without compromising confidentiality.

[0045] Optionally, at least one data carrier is assigned to an invalid output of a further blockchain transaction, i.e. the invalid output may include a redemption script including an OP_RETURN opcode to ensure that the output is never redeemed but the data carrier remains in the transaction. Advantageously, this allows the data contained on the data carrier to be stored in the corresponding transaction.

[0046] Each data carrier may hold an individual dataDigest, which is a hash of the event data stored off-chain and / or stored in transactions within the event data representation of the data carrier's payload.

[0047] Each data carrier may hold a separate streamDigest, which is either a hash of the pre-image of the previous state of the event stream (which may also be described as the stream digest, or stream digest reference, of the previous state of the event stream), or the seed of the first transaction (if the transaction is the second transaction in the chain, since the first transaction does not contain a streamDigest).

[0048] Optionally, the streamDigest can be salted. A unique value, the salt, can be randomly generated for each transaction associated with the event stream. The salt is optionally stored off-chain. Salting the data has the advantage that it does not reveal anything and prevents brute force pre-image attacks such as brain wallet attacks.

[0049] Each of the data carriers of all parties may be identical and based on the same data and the same payment instruction data set. A data carrier may hold several different pieces of data based on the streamState of the particular data stream to which the carrier is added, which in turn is based on the previous streamState and / or the index (or sequence number) and / or the individual salt used for the representation of that data carrier.

[0050] A streamState may be defined as a parameter that points to the current cumulative state of all data in the corresponding event stream. It may be expressed as a digest incorporating all message data and the position of each data item within the stream. When streamState is recorded on-chain, it may be accompanied by a pre-image of the latest linked events and, optionally, the data items themselves.

[0051] The streamState may be maintained as each event is added to the stream. Digests, along with individual event data, may be settled on-chain according to the values ​​of settStreamOnChain and SettleDataOnChain.

[0052] The pre-image optionally has any one or more of the following fields: · Txid create A reference to the first transaction in the chain, preferably the transaction ID of the first transaction in the chain, index: the index of the data or event, whenRecorded: the time associated with the creation of the transaction and / or data item, ·dataDegest n a hash of the event data as it is stored off-chain (and, optionally, on the transaction in its payload ([...]) representation of the event data), and streamDigest n-1 : A hash of the pre-image of the preceding state of the event stream (also called the stream digest or stream digest reference of the preceding state of the event stream), or the seed of the first transaction (if the first transaction does not contain a streamDigest and is the second transaction in the chain). The streamDigest is a hash of the preimage.

[0053] Optionally, the computing resource determines that the transfer cannot be performed according to the transfer protocol and generates a further set of metadata to resolve the lack of match with the transfer protocol. The lack of match may be a mismatch between the identity of the assets, the identification of the asset registry, or the amount of the assets being transferred. An effect of this is that the computing resource can introduce further metadata to facilitate the transfer even when a mismatch exists between at least one of the identity of the assets, the asset registry (e.g., bank), or the amount of the assets being transferred.

[0054] Generating the further set of metadata includes generating further payment instruction data having details of the asset transfer (e.g., payment) from / to the asset registry and / or a transformation between the assets and / or payment details to address discrepancies in the amount of value of the assets being transferred. Generating the further set of metadata also includes obtaining a cryptographic signature corresponding to the asset registry or the issuer of the asset.

[0055] For example, generating the further set of metadata may include generating metadata enabling conversion between the first currency and the second currency, the metadata enabling conversion between the first currency and the second currency including data detailing a payment in the first currency to an asset registry associated with an issuer of the first currency and / or data detailing a payment in the second currency from an asset registry associated with an issuer of the second currency, thereby enabling multi-currency transactions, i.e. cross-border transactions, to be recorded in accordance therewith.

[0056] For example, generating a further set of metadata may include generating metadata that allows for transfer of the asset even in the presence of different publishers of the asset.

[0057] Optionally, the method further comprises identifying prior blockchain transactions for the asset registry and / or the issuer of the asset, the blockchain transactions including dust inputs that use dust outputs associated with the respective prior transactions.

[0058] The method further comprises initializing an event stream associated with the computing resource or any asset registry, and synchronizing the asset transfer event with the event stream associated with the computing resource. Optionally, synchronizing the asset transfer event with the event stream associated with the computing resource or asset registry includes appending a representation of metadata corresponding to the asset transfer event to the asset registry or event stream associated with the computing resource.

[0059] Advantageously, this means that the asset registry can verify payments using the event stream, i.e., the participation of the asset registry is supported by the immutability of the blockchain. That is, the account provider, e.g., a bank, can verify that an asset transfer has occurred because they also have an event stream added to record the asset transfer. Additionally or alternatively, an event stream associated with the computing resource may also be initialized to record transactions involving the computing resource.

[0060] Initializing an event stream refers to setting up and configuring the computing resources and data structures necessary to implement a particular event stream.

[0061] Optionally, the computing resource applies a cryptographic signature to the further set of metadata. The cryptographic signature is generated using Public Key Infrastructure (PKI) technology. The cryptographic signature is obtained from a data store or from a device operated by either the sender or the recipient. Optionally, the computing resource obtains cryptographic signatures corresponding to the sender and the recipient and applies the respective cryptographic signatures to the metadata. The respective cryptographic signatures may be obtained, for example, from computing devices associated with the sender and the recipient.

[0062] A beneficial effect of this is that the computing resource can apply a signature to further sets of metadata such that the further sets of metadata can be cryptographically signed.

[0063] In a second aspect, a computer implemented method of asset transfer from a first user to a second user is provided. The account may be provided by an asset registry, such as a bank. The method is performed by a first computing resource associated with a sender of the transferred assets. The computing resource may be implemented by hardware or software. The computing resource may include multiple processing resources, which may be distributed either locally or over a large geographic area. The method comprises receiving a request for asset transfer from a second computing resource configured to perform the method of the first aspect. The method comprises generating a first set of metadata, the first set of metadata comprising: (i) the account used for the transfer; (ii) the amount of assets to be withdrawn from the account; and (iii) Show the indicator of the assets to be used in the transfer.

[0064] The method further comprises transmitting the first set of metadata to a second computing resource to initialize the transfer. The method further comprises receiving instruction data associated with the requested transfer from the second computing resource. The method further comprises signing the instruction data using a cryptographic signature to generate signed instruction data. The method further comprises transmitting the signed instruction data to the second computing resource.

[0065] A method relating to the second aspect enables a computing device to effect transfer of assets by a user, benefiting from the immutability, reliability and security of the approach provided by the first aspect.

[0066] A method related to the third aspect is a computer-implemented method for verifying an asset transfer event recorded according to the first aspect. The method is performed by a first computing resource, which may be defined as hardware or software. The method comprises receiving a request to verify the asset transfer event from the computing resource, the request including an identifier associated with the asset transfer event. The method further comprises searching an event stream entry associated with the identifier to extract metadata associated with the asset transfer event. The method further comprises sending a confirmation of the asset transfer event to the computing resource.

[0067] A method according to a third aspect allows verifying the occurrence of an asset transfer event by transmitting an identifier associated with an event that is used as the basis for a search, and verifying the occurrence when an event associated with the identifier is found.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0117] The payment processing resource 106 of Figure 1a is configured to interact with a key storage module 122 and a payment data store 124. The key storage module 122 is configured to store cryptographic keys corresponding to the accounts of participants who use the payment processing resource 106 to enable transactions to be conducted. The key storage module 122 may utilize any suitable storage and may utilize a database management system (DBMS) to initialize, store and retrieve data from records in the database of participants who store cryptographic keys in the key storage module 122. The payment data store 124 is configured to store data related to all payments made using the payment processing resource 106.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0275] 102 first computing device 104 Second Computing Device 105 Client Applications 106 Payment Processing Resources 112 Blockchain 120 Payment Protocol Module 122 Key Storage Module 124 Payment Data Store< / alice:hsbc> < / bob:hsbc> < / alice:hsbc> < / bob:hsbc>

Claims

1. A method implemented by a computer for recording an asset transfer event involving at least a first user and a second user, the method being implemented by computing resources, the method comprising: Receiving instruction data, the instruction data being related to a requested asset transfer event, the instruction data having a first set of metadata related to the sender of the asset, a second set of metadata related to at least one recipient of the asset, each of the sender and the recipient being related to an account related to an asset registry; Associating the sender of the asset with a first event stream and associating the recipient of the asset with a second event stream; Comparing the first set of metadata with the second set of metadata to determine whether the transfer of the asset from the sender to the at least one recipient can be executed according to a transfer protocol, the transfer protocol defining at least one criterion for enabling an asset transfer event to occur; Determining one or more corresponding items between the respective sets of metadata based on the comparison between the respective sets of metadata according to the transfer protocol; Identifying previous blockchain transactions related to the respective first and second event streams for the sender and the at least one recipient based on the determined correspondence; Generating a further blockchain transaction for synchronizing the respective first and second event streams with the asset transfer event, the further blockchain transaction for each of the sender and the at least one recipient Including a dust output related to the previous transaction and a dust input related to each unused transaction output, and an unused transaction output related to the asset transfer event; A method comprising.

2. The step of determining one or more corresponding items between the respective sets of metadata comprises: i) the currency of payment identified in 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, and iii) determining a correspondence between at least one of the identifiers of the asset registry associated with the sender account and the recipient account The method according to claim 1, comprising the step of determining a correspondence between at least one of the identifiers of the asset registry associated with the sender account and the recipient account **Claim 3** The method according to claim 1, wherein the computing resource determines, according to the transfer protocol, that the execution of the transfer is not possible and generates a further set of metadata for resolving the lack of compliance with the transfer protocol **Claim 4** The method according to claim 3, wherein generating the further set of metadata includes generating metadata that enables conversion between a first currency and a second currency **Claim 5** The method according to claim 3, wherein generating the further set of metadata includes generating metadata for one asset registry to record the transfer of a given asset in another asset registry **Claim 6** The method further comprises identifying previous blockchain transactions for the asset registry associated with at least one of the accounts, wherein the further blockchain transaction includes a dust input that uses a dust output associated with the previous transaction identified for the asset registry, and the further blockchain transaction also includes each unused transaction output (UTXO) corresponding to the dust input. The method according to claim 3 **Claim 7** The method further comprises initializing an event stream in relation to the asset registry associated with the at least one account; and synchronizing the event stream associated with the computing resource with the first and second event streams based on the asset transfer event The method according to claim 6, comprising the steps of **Claim 8** The method according to claim 7, wherein the synchronization includes adding metadata corresponding to the asset transfer event to the event stream associated with the asset registry **Claim 9** The method according to claim 3, wherein the computing resource applies a cryptographic signature to the further set of metadata **Claim 10** The method according to claim 1, wherein the computing resource extracts cryptographic signatures corresponding to the sender and the receiver, and applies each cryptographic signature to the metadata.

11. The method according to claim 10, wherein each of the cryptographic signatures is extracted from a computing device associated with the sender and the receiver.

12. A method implemented by a computer for transferring an asset from a first user to a second user, the method being implemented by a first computing resource associated with a sender of the asset, the method comprising: receiving a request for transfer of an asset from a second computing resource configured to implement the method according to any one of claims 1 to 11; (i) an account used for the transfer, (ii) the amount of the asset withdrawn from the account, and (iii) an indicator of the currency used for the transfer generating a first set of metadata indicating; sending the first set of metadata to the second computing resource to initiate the transfer; receiving instruction data related to the requested transfer from the second computing resource; signing the instruction data using a cryptographic signature to generate signed instruction data; sending the signed instruction data to the second computing resource comprising a method.

13. A method implemented by a computer for verifying an asset transfer event according to any one of claims 1 to 11, the method being implemented by a first computing resource, the method comprising: receiving, from a computing resource, a request to verify an asset transfer event having an identifier related to the asset transfer event; searching for an event stream entry related to the identifier and extracting metadata related to the asset transfer event; sending a confirmation of the asset transfer event to the computing resource comprising a method.

14. A system configured to implement the method according to any one of claims 1 to 11.

Images