Callback Mechanism for Blockchain Transactions

Abstract

In one aspect, the present disclosure presents methods, devices, and systems for processing blockchain transactions associated with a client. A payment service is implemented as a gateway or an API endpoint that can be accessed by one or more clients. A request to submit a transaction is received from a given client, which is associated with a callback identifier. The callback identifier enables direct communication between the given client and another entity, such as a network node or another counterparty. A payment processor submits the transaction to the network node, and the submission is associated with the callback identifier. Subsequently, once the corresponding blockchain transaction has been created by the network node, a callback notification related to the client can be provided directly to the client from the network node using the callback identifier.

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for implementing payment services or payment interfaces for one or more clients. In particular, but not limited to, the present disclosure relates to implementing secure and reliable payment transactions associated with a blockchain ledger or distributed ledger for one or more clients or on behalf of one or more clients, the transactions involving digital asset payments associated with a customer or payor entity. Background Art

[0002] As used herein, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers. These ledgers include consensus-based blockchain and transaction chain technologies, permissioned and non-permissioned ledgers, shared ledgers, public blockchains and private blockchains and variations thereof. The terms "client", "entity", "node", "user", "sender", "receiver", "payor", "payee" may refer to computing resources or processor-based resources herein. The term "digital asset" may refer to any transferable asset such as a smart contract, a license (i.e., software license) or a DRM contract for media content etc. It will be understood that the term "digital asset" as used throughout this document is used to denote goods that can be associated with value, which can be transferred from one entity to another in a transaction, or provided as payment in a transaction from one entity to another.

[0003] A blockchain is a peer-to-peer electronic ledger that is implemented as a computer-based decentralized distributed system, which is composed of blocks, and these blocks are in turn composed of transactions. Each transaction is a data structure that encodes the control transfer of digital assets among the participants in the blockchain system and includes at least one input and at least one output. Each block includes the hash of the previous block, such that the blocks are linked together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions include small programs called scripts that are embedded in their inputs and outputs, which specify how and by whom the outputs of the transaction can be accessed.

[0004] To write a transaction to the blockchain, the transaction must be "verified". Network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this verification work on unspent transactions (UTXOs) by executing their locking scripts and unlocking scripts. If the execution of the locking script and the unlocking script evaluates to TRUE, the transaction is valid and then the transaction is written to the blockchain. Thus, to write a transaction to the blockchain, the transaction must i) be verified by the first node that receives the transaction - if the transaction is verified, the node relays the transaction to other nodes in the network; ii) be added to a new block created by network nodes; and, iii) be mined, i.e., added to the public ledger of past transactions.

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

[0006] Digital entrepreneurs are exploring how to use cryptographically secure systems and data that can be stored on the blockchain for new systems. It would be highly beneficial if the blockchain could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of the blockchain (e.g., permanent, tamper-proof event records, distributed processing, etc.) while making the application of the blockchain more general.

[0007] One area of current research is the use of the blockchain to implement "smart contracts". These "smart contracts" are computer programs designed to automatically execute machine-readable contracts or agreements. Different from traditional contracts written in natural language, smart contracts are machine-executable programs that include rules that can process inputs to produce results, and then the rules can cause actions to be taken based on these results.

[0008] The above examples or scenarios involve the transfer of certain assets (i.e., digital assets), or the control of digital assets between users or entities. Therefore, it is desirable to implement a secure and robust system similar to existing payment systems or e-commerce systems for the exchange of funds between two entities - particularly for digital asset payments between merchants and customers. This system can respect assets in the real world, have a better user experience, lower merchant costs or payee costs, and a higher level of security. More specifically, it is desirable to utilize distributed ledger (blockchain) technology and its advantages of improved record security, transparency, and reliability to provide a public platform or public interface that enables any merchant or multiple merchants to ensure that digital asset payments made with their respective customers can be instantaneously and securely mined or written into the blockchain, thereby providing a persistent, tamper-proof, and auditable record of such payments.

[0009] Now, such an improved solution has been designed. The present disclosure addresses these technical problems by presenting techniques through which transactions of one or more clients (i.e., merchant or payee entities, who are the recipients of digital assets) can be instantaneously written into the blockchain by means, techniques, and devices that provide application programming interfaces (APIs) for such clients. Among these techniques, network nodes will be able to dynamically or instantaneously mine transactions or write transactions into the blockchain, i.e., provide a service to clients that allows for instant transactions or zero-confirmation transactions (0-conf) in a secure and reliable manner. Summary of the Invention

[0010] In one aspect, the present disclosure presents methods, devices, and systems associated with a payment service for processing blockchain transactions associated with a client. The payment service is implemented as a gateway or API endpoint that can be accessed by one or more clients. In this method, a request to submit a transaction received from a given client is associated with a callback identifier. The callback identifier enables direct communication between the given client and another entity. The payment processor submits the transaction along with the callback identifier to a network node. Subsequently, once the corresponding blockchain transaction has been created by the network node, a callback notification related to the corresponding blockchain transaction can be provided directly to the client from the network node.

[0011] In another aspect, a request from a client is associated with a channel provided by a channel service and associated with one or more functions that enable direct communication between the client and another entity. In such a case, the client is also provided with one or more access tokens and an application programming interface (API) for the channel. Subsequently, the client can provide access to the channel to another entity (such as a network node that has been identified as an entity for mining transactions for the client) based on these access tokens and / or the API. This enables data related to the corresponding blockchain transaction to be directly written to the channel by other entities. Subsequently, a callback notification specific to the corresponding transaction can be provided via the channel service. This enables data associated with a given transaction to be directly accessed by the client from the channel when needed or when possible (such as when the client is online and communicating with the channel service via the network). In some cases, the channel service can be implemented by a channel processor. The channel processor can be the same entity as the payment processor described above or can be an entity independent of the payment processor.

[0012] In this specification, the word "comprise" or variations such as "includes", "comprises" or "comprising" will be understood to mean including the stated element, integer or step, or group of elements, integers or steps, without excluding any other element, integer or step, or group of elements, integers or steps. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Aspects and embodiments of the present disclosure will now be described by way of example only and with reference to the accompanying drawings, in which:

[0014] Figure 1 is a flowchart that describes a method for implementing a payment service or payment interface to enable digital asset transactions associated with a blockchain for one or more clients, the method being implemented by a payment processor according to a first aspect.

[0015] Figure 2 is a flowchart that describes a method for requesting processing of a blockchain transaction associated with a digital asset payment associated with a client, wherein the method is implemented by one or more processors associated with the client according to a second aspect.

[0016] Figure 3 is a flowchart that describes a method for processing a blockchain transaction associated with a digital asset payment of a client, wherein the method is implemented by one or more processors associated with a network node according to a third aspect.

[0017] Figure 4 is a schematic diagram that shows a system for demonstrating a payment service or payment interface to implement blockchain transactions for a client.

[0018] Figure 5 is a schematic diagram that depicts a data flow associated with a first request for obtaining a fee quote associated with multiple network nodes.

[0019] Figure 6 is a schematic diagram that depicts a data flow associated with a second request for submitting a transaction based on a selected fee quote.

[0020] Figure 7 is a schematic diagram that depicts a data flow associated with a status query based on a blockchain transaction identifier.

[0021] Figure 8 is a flowchart that depicts a method for implementing a callback mechanism for a transaction, where the method is implemented by one or more processors associated with a payment processor according to a fourth aspect.

[0022] Figure 9 is a flowchart that depicts a method for implementing a channel service for one or more clients, where the method is implemented by one or more processors associated with a channel processor according to a fourth aspect.

[0023] Figure 10 is a flowchart that depicts a method for accessing a payment service, where the method is implemented by one or more processors associated with a client according to a fourth aspect.

[0024] Figure 11 is a flowchart that depicts a method for processing a message associated with a given blockchain transaction, where the method is implemented by one or more processors associated with a network node according to a fourth aspect.

[0025] Figure 12 is a schematic diagram that shows a computing environment in which various aspects and embodiments of the present disclosure can be implemented. Detailed Description

[0026] Although the appended claims are related to a fourth aspect of the present disclosure described in detail below, a detailed discussion of the first, second, and third aspects is provided herein to enable the reader to comprehensively and completely understand the aspects and related embodiments claimed in the present disclosure.

[0027] According to a first aspect, the present disclosure provides a computer-implemented method for implementing payment services for one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor associated with the payment services. In some embodiments, a client may be a computing resource or a node or an entity that may be associated with a digital wallet for accepting and / or processing cryptocurrency payments and may be associated with a public key or a public address for such a wallet. In some embodiments, a client may represent a merchant entity or a terminal (such as a point-of-sale device) that provides goods or services in the real world and receives digital asset payments for such goods or services, but is not limited thereto. In some embodiments, the payment processor is configured to provide a payment interface as an associated service or a third-party service for one or more clients. In some examples, the payment processor is referred to as a payment aggregator because the payment processor provides multiple payment services and functions associated with the blockchain for clients and network nodes via one or more user-friendly interfaces. In some embodiments, the payment processor is implemented as an application programming interface (API) for providing web-based interactions for one or more clients, i.e., implemented as a web service, such that communication can be performed over the Internet using standard Internet communication protocols for web-based services (such as HTTPS, TCP / IP, etc.). The API is known to, or available to, or sent / provided to one or more clients that are associated with the payment processor. In some embodiments, the API may be provided to a client during a registration or onboarding process for accessing services or functions provided by the payment processor. In some examples, the API may be provided or published via an API user interface (such as Swagger) for use by clients, and Swagger is a well-known API design and development tool or interface for clients or other entities that expect to access web-based services.

[0028] The method of the first aspect includes the following steps: obtaining a fee quote for a mining transaction from each of a plurality of network nodes. This step occurs in response to a first request from a client for a mining fee quote associated with the mining transaction. In some embodiments, the network nodes are nodes implemented by one or more processors that are entrusted with validating locking scripts and unlocking scripts, as well as mining transactions or writing transactions to the blockchain, as explained in the background section above. The method of the first aspect includes the step of providing the obtained fee quote to the client. In some embodiments, the fee quote relates to the current fee charged or collected by the network node for mining a transaction into the blockchain, regardless of what the transaction is related to or the parties involved. In other embodiments, the fee quote can be customized based on a given transaction that can be identified in the request. In some embodiments, the payment processor can provide all received fee quotes to the client, or can provide one or more recommended fee quotes to the client among the obtained fee quotes.

[0029] Advantageously, by implementing the payment service as an API provided to one or more clients (i.e., merchants or payee entities), where these clients are recipients of digital assets, the method of the first aspect allows payment transactions to be mined (written to the blockchain) almost immediately or as soon as the network nodes solve the proof-of-work problem by allowing the client to sign up for or use the web service provided by the payment processor. By providing the current fee quote, a given network node theoretically agrees or commits to adding the transaction to the next block to be mined by that given network node at that fee. Advantageously, this means that the client (i.e., the merchant entity) no longer needs to wait for any confirmation from the network node. Thus, 0-conf transactions associated with the client and the corresponding network node can be advantageously achieved. The identity of the client using the payment service API can be advantageously kept anonymous, while all transactions associated with the client can still be reliably mined by network nodes among the plurality of network nodes that meet or satisfy the selected or chosen mining fee quote. Thus, by using the proposed payment service API, a single client or merchant can take advantage of the transparency, reliability, and availability of an immutable and verifiable record of all payments associated with the corresponding client without having to implement any additional processing resources or network resources.

[0030] In some embodiments of the first aspect, in response to a second request from the client to submit a given transaction related to or including the selected fee quote among the obtained fee quotes, the method includes sending a request to one or more of the plurality of network nodes for generating a blockchain transaction for the given transaction.

[0031] In some embodiments, a selected fee quote is received from a client and selected for a given transaction, which in turn may be related to a payment request or payment transaction between the client and another node or entity (such as a customer of the client who requires digital asset payment due to goods or services purchased from the client). Subsequently, the method includes receiving an output script associated with a blockchain transaction, such as a UTXO, from at least one network node among a plurality of network nodes that meets the selected fee quote. For example, in some embodiments, in order to meet the fee quote, according to one or more rules, or a predetermined criterion associated with the client, the current fee quote should have been provided to at least one network node, or at least one network node should have been associated with the current fee quote, the value of which is higher or lower than the selected fee quote, and in some cases the value of the current fee quote is higher than the selected fee quote. Subsequently, the method includes sending a result to the client, the result including a transaction identifier (TxID) of the blockchain transaction related to the given transaction (i.e., the payment between the client and the customer).

[0032] Advantageously, the API of the present disclosure can be implemented as a REST (Representational State Transfer) endpoint, allowing the client to communicate using standard Internet protocols or web-based protocols such as HTTPS. Additionally, advantageously, the payment service of the first aspect enables the corresponding transaction associated with the digital asset payment to be immediately created and written into the blockchain based on the selected fee quote. Mining the transaction based on the selected fee quote (which is selected or picked by the client or on behalf of the client by the payment processor) advantageously enables at least one network node among a plurality of network nodes to mine the transaction or write the transaction into the blockchain almost immediately or as soon as possible, where it is guaranteed that a given network node will mine the transaction according to the current fee quote that conforms to or meets the selected fee quote from the client. Thus, the advantage of the payment service API is that it allows for the mining of instant transactions or zero-confirmation transactions (0-conf) in the blockchain in a secure and reliable manner for the client without the client having to wait for confirmation from the network node that the transaction has indeed been added to the block and will be mined in the blockchain. The reason is that by sending the current fee quote for mining the transaction in response to the first request, the given network node has indicated that it can perform the mining. The method of the first aspect reduces the double-spending risk associated with allowing the mining of instant transactions because the mining according to the first aspect will be based on the selected fee quote picked by the client or picked for the client. Thus, only the network nodes that meet the selected fee quote can mine the transaction, and once the transaction is added to the block associated with the blockchain by the first network node that meets the fee quote, the transaction cannot be mined by other network nodes.

[0033] Some embodiments of a method according to a first aspect, which provides a payment service implemented by a payment processor, include: providing an obtained transaction mining fee quote based on determining a proposed fee to a client, where the determined fee can be an average of the obtained fee quotes or a maximum of the fee quotes obtained from multiple network nodes. Advantageously, to avoid double-spending, the payment processor can propose submitting a transaction with the highest fee value, which is obtained from multiple network nodes in response to a first request. In this way, all network nodes can be provided with an equal opportunity to mine the transaction at their respective currently quoted fees. However, if the proposal is to submit a transaction at a fee equal to or higher than the median or average of all received fee quotes, network nodes with higher quotes can simply hold the transaction in a memory pool (such as a secondary memory pool) and use the transaction to check for any double-spending of the transaction and reject any double-spending of the transaction. Similar advantages apply if the selected fee quote is based on a proposed fee quote or if the proposal is part of a client's choice.

[0034] Advantageously, the payment processor proposes a fee quote that the client can subsequently choose as the selected fee quote, which, in some embodiments, is the maximum fee that the client is willing to pay to submit a transaction associated with the payment of digital assets going to the client. This is advantageous if the client is a computationally simple client or if the client has pre-determined that the payment processor provides the proposal rather than choosing the fee quote themselves. Thus, advantageously, the client can choose a fee quote based on the proposed fee quote rather than adopting a new or additional heuristic or calculation to choose a fee quote or choosing a fee quote arbitrarily.

[0035] In some embodiments, when the proposal or proposed fee quote is provided from a payment service (i.e., an API provided by the payment processor), the proposed fee quote can be provided, or all obtained fee quotes can be provided, including the proposed fee quote, the proposed fee quote including an identifier. Advantageously, by providing the proposal and all received fee quotes, the payment processor provides the client with the option of using the proposed fee quote to submit a transaction or choosing a different fee quote from the other received fee quotes.

[0036] In some embodiments, the method includes the steps of: verifying the identity of a given network node among a plurality of network nodes that have provided corresponding fee quotes, wherein the identity is verified based on a digital signature associated with the given network node. The encryption key pair includes a private key and a public key (or public address) associated with each network node, and this encryption key pair can be used to verify that the fee quote indeed originates from the given network node, that is, data signed by the private key can only be recovered or verified by using the corresponding public key. If the verification is based on a digital signature, standard public key infrastructure (PKI) techniques can be used and implemented.

[0037] In other embodiments, an identifier related to the given network node can be additionally or alternatively used to verify the identity of the network node. In some embodiments, the method includes a payment processor, such as NetworkNodeID (Network Node ID). In some embodiments, the identifier can be associated with a reputation metric of the given network node. In some embodiments, NetworkNodeID can be based on a mining pool, the given network node is part of the mining pool, or the mining pool is specific to the given network node. The reputation metric is related to the measurement of the performance of the network node. For example, in some examples, the reputation can be based on how the given network node has executed or mined transactions according to the quoted fees in the past. For example, if the network node regularly mines transactions at or within an acceptable range of the fees quoted by the network node, the reputation metric can indicate a good reputation, such as being higher numerically. In some embodiments, the reputation score or metric of the network node can be calculated, maintained, and managed by at least one payment processor communicatively coupled to the network node.

[0038] In some embodiments, the method of the first aspect implemented by the payment processor can include the steps of: verifying a fee quote obtained from a given network node among a plurality of network nodes based on a network node signature, which is different from the digital signature used to verify the identity of the given network node using PKI techniques. The network node signature used by the payment processor for the verification step advantageously indicates or serves as a commitment of the network node to: mine transactions according to the corresponding fee quote provided to the payment processor. The presence of the network node signature can also be advantageously used to confirm that the network node will reject any conflicting transactions. Therefore, the verification step based on the network node signature advantageously serves as a guarantee that: the given network node will include the transaction in the block for mining, and the given network node will not include any conflicting transactions. In some embodiments, monitoring the performance of the given network node based on one or more such guarantees given by the given network node can define or affect the network node reputation or network node score associated with the given network node.

[0039] In some embodiments, a fee quote provided by each of a plurality of network nodes is provided to a payment processor as a data type that includes the value of the fee quote. In some embodiments, the data type is in the form of a JavaScript Object Notation (JSON) object format.

[0040] In some embodiments, an output script received at a payment processor from at least one network node is an unspent transaction output (UTXO) associated with the memory pool of the at least one network node, the UTXO including a transaction identifier (TxID) of a blockchain transaction, wherein the blockchain transaction relates to a digital asset payment between a client and a customer.

[0041] In some embodiments, to enable a client to advantageously identify or track blockchain transactions that relate to a given payment transaction with a customer or any transaction associated with the client, the method includes the steps of: sending a request to a plurality of network nodes to obtain a corresponding blockchain transaction for a transaction identifier, the request being sent by a payment processor to at least one network node in response to a status query associated with the transaction identifier from the client. In response, the payment processor obtains the corresponding blockchain transaction previously generated from at least one of the plurality of network nodes. Based on the mining status of the blockchain transaction generated by the at least one network node, the method includes the steps of: sending a status result related to the obtained blockchain transaction to the client, the obtained blockchain transaction being associated with the transaction identifier. The result can indicate whether the blockchain transaction has been mined (i.e., whether it has been completed), or whether it has been rejected for some reason, or whether it is invalid because the blockchain transaction may have been mined by another network node among the plurality of network nodes before the given network node. In the case where mining has been completed for a particular transaction by different network nodes, this advantageously avoids double spending. In some embodiments, a network node may maintain transactions that have not yet been added to a block or mined in a secondary memory pool, which may be or serve as an alternative or additional memory pool independent of the main memory pool associated with the network node. The secondary memory pool may be a temporary memory pool such that TxIDs can be checked for double spending. This advantageously ensures that even if a transaction is not mined by a given network node, the transaction remains in the secondary memory pool and is used to check for and reject future double spending. There may be a time limit with respect to the holding of unmined or non-intended-to-be-mined transactions in the secondary memory pool of a given network node. In some embodiments, the transactions stored in the secondary memory pool may be associated with an expiration time after which the transactions will be cleared. In some embodiments, there may be a separate charge associated with a network node for storing unmined transactions of the given network node in its corresponding secondary memory pool.

[0042] In some embodiments, the method of the first aspect further comprises the following steps: providing an Application Programming Interface (API) converter associated with a payment processor for performing the following steps: receiving a first request for a fee quote, a second request for submitting a transaction associated with a digital asset payment of a client, and / or a status query for a transaction in Hypertext Transfer Protocol Secure (HTTPS) format from the client; and subsequently converting the first request, the second request, and / or the status query into a Remote Procedure Call (RPC) format and then sending these RPCs to a plurality of network nodes. This is advantageous because it allows a client to pass blockchain-related requests via HTTPS by providing interoperability with a plurality of network nodes seamlessly using a web-based API, where these network nodes do not communicate using the Internet Protocol communication standard of web services. The API converter implemented in this embodiment is not limited to converting from HTTPS to RPC (and vice versa), or from other web-based protocols to an alternative communication protocol supported by a single network node, or for a network for a given digital asset that may also be contemplated. In the reverse communication path, the method of the first aspect further comprises: receiving a response in RPC format associated with a corresponding blockchain transaction from one or more of the plurality of network nodes and accordingly converting the corresponding response for the client using HTTPS. Thus, it is advantageous that when the client (payee) and the network nodes use different wireless data communication protocols and mechanisms, the implementation of the proposed interface by the payment processor enables seamless communication for submitting transactions to the blockchain.

[0043] In some embodiments, an API gateway associated with the payment processor may be provided. In these embodiments, the above-mentioned API converter may be associated with the API gateway. Additionally, in some embodiments, the API gateway may also be implemented in one or more computing devices to perform / responsible for functions including but not limited to one or more of the following:

[0044] - Caching of transactions

[0045] - Performing a recovery function in the event of a network node failure

[0046] - Maintaining a record of one or more endpoints or URLs that can be used to send messages or notifications to / from the payment processor and / or the client and / or the network nodes

[0047] - Providing a recovery feature to track transactions that fail to be submitted for some reason.

[0048] In some examples, this can include configurable parameters maintained or set by a payment processor; and a mechanism for purging tracked transactions that have expired. The API gateway can also be associated with functions for resubmitting transactions in a failure scenario, thereby providing error handling for genuine transactions and the ability to distinguish double-spending.

[0049] According to a second aspect, the present disclosure provides a method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with a client, the client being communicatively coupled to at least one payment processor that implements a payment service for the client. In some embodiments, the payment processor is configured to implement the method of the first aspect and its associated embodiments. The method of the second aspect implemented by the client (i.e., the merchant) includes the steps of: sending a first request to a payment processor among at least one payment processor, the request being related to one or more fee quotes for mining one or more transactions obtained from a plurality of network nodes via the payment processor. As described above, the obtained fee quotes are related to mining any transaction or can be specific to a given transaction that is related to a digital asset payment from a customer.

[0050] In some embodiments of the second aspect, in response to receiving one or more fee quotes from the payment processor, the method includes selecting a fee quote from the one or more received fee quotes. As described in the first aspect, the selected fee quote may or may not be based on a recommendation made by the payment processor. Subsequently, the method of the second aspect includes requesting and / or processing a digital asset payment from the customer, the request being associated with the selected fee quote. In some embodiments, the request is similar to a payment request or document issued by the client to the customer for a digital asset payment. For example, the client can be a coffee shop terminal associated with a digital wallet, and the customer can respond to the request to pay for coffee, and the customer is also associated with a digital wallet. Since the selected fee quote is now selected, the selected fee quote can be added to the request from the customer for payment. Subsequently, the method includes submitting a second request to the payment processor, the request being for a given transaction associated with the above customer payment, the submission being based on the selected fee quote for mining the given transaction. In some embodiments, the selected fee quote is clearly indicated or included in the second request, such that the payment processor can advantageously identify network nodes that can mine the transaction at or below the selected fee quote, or additionally or alternatively, such that the network nodes can identify whether they meet the selected fee quote.

[0051] As described above, in some embodiments, the client may select a fee quote based on the value of the highest fee quote received from the payment processor, or may select a value that is the average or median of the received fee quotes or close thereto. The advantages of either option are the same as those discussed above, namely: the maximum value allows all network nodes to have the opportunity to mine; and the other values limit mining to some network nodes that meet the fee quote, since those network nodes are able to mine the transaction at the selected quote or lower, while those network nodes that are unable to mine the transaction (e.g., due to a too-high quote) can still retain a record of the blockchain transaction in temporary storage (such as a secondary memory pool), such that this can be used to verify any double-spending of a given transaction.

[0052] In some embodiments of the second aspect, the method further includes receiving a transaction identifier of a blockchain transaction that has been generated by at least one network node, the blockchain transaction corresponding to the submitted transaction, i.e., the transaction between the client and the customer. In some embodiments, the method includes sending a status query associated with the obtained transaction identifier; and obtaining a status result of the blockchain transaction corresponding to the transaction identifier.

[0053] The advantages associated with the second aspect are related to the advantages discussed above in connection with the first aspect. The second aspect is complementary to the first aspect, but describes a method implemented by the client for requesting that a transaction be written to the blockchain. In some embodiments, the client implementing the method of the second aspect may communicate with at least one payment processor that is configured to implement the payment service as a payment API according to the method of the first aspect.

[0054] Furthermore, the method of the present disclosure advantageously allows the client to select a fee quote to provide to the payment service, which provides the client or merchant with the following control: namely, that their transaction will be mined in a timely manner at a given mining fee, thereby providing improved security, interoperability, reliability, efficiency, and timeliness for those transactions that are mined for the client utilizing the proposed payment service or payment API.

[0055] As described above, since the payment service implemented by the payment processor is an API, in some embodiments, the first request and / or status query from the client is an HTTPS GET request, and the second request is an HTTPS POST request. Thus, advantageously, the client can use standard Internet communication protocols and web-based communication protocols to request that a transaction be mined into the blockchain. In some embodiments, the data associated with the first request and / or second request and / or status query from the client is provided in JavaScript Object Notation (JSON) object format.

[0056] According to a third aspect, the present disclosure provides a computer-implemented method for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a network node among a plurality of network nodes, wherein the plurality of network nodes are communicatively coupled to at least one payment processor that implements a payment service for a client. In some embodiments, the payment service is implemented by the payment processor based on the above-described method associated with the first aspect. In some embodiments, the client is configured to implement the method associated with the above-described second aspect. The method of the third aspect implemented by a network node among the plurality of network nodes includes the following steps: In response to a first request, providing a current fee quote related to the network node mining a transaction in the blockchain, the first request being a request for a fee quote for a transaction associated with the client. In some embodiments, the fee quote may be provided as a data type for a payment processor associated with the client. As described above, the first request may relate to a request for a current fee quote for any transaction or multiple transactions, or the first request may be specific to a particular transaction between the client and a customer.

[0057] In some embodiments of the third aspect, in response to a second request from a payment processor on behalf of the client (the second request relates to submitting a given transaction based on a selected fee quote in the blockchain, wherein this part may be completed by the client as described in the first and second aspects), the method includes the following steps. Based on determining that the selected fee quote associated with the given transaction satisfies the current fee quote of the network node, that is, determining that the selected fee quote is equal to or within the current fee quote, the given network node then generates a corresponding blockchain transaction associated with the given transaction. The method further includes: generating an output script (UTXO) for the created blockchain transaction, adding the generated output script to a memory pool associated with the network node, and sending the output script to the payment processor, wherein the output script includes a transaction identifier TxID associated with the corresponding blockchain transaction. In some embodiments, in response to a request for a status associated with the transaction identifier, the network node includes returning a result based on the current mining status of the corresponding blockchain transaction.

[0058] The advantages associated with the third aspect are related to the advantages discussed above in connection with the first and second aspects. The third aspect is complementary to the first and second aspects, but describes a method implemented by a network node among a plurality of network nodes that are coupled to a payment processor for constructing a transaction that can be written to the blockchain for a client. In some embodiments, a network node implementing the method of the third aspect may communicate with at least one payment processor that is configured to implement the payment service as a payment API according to the method of the first aspect.

[0059] In some embodiments, the step of providing a current fee quote and / or the step of sending an output script and / or the step of returning a result are implemented as a Remote Procedure Call (RPC). In some embodiments, the method of the third aspect may include the steps of: before propagating the RPC over a wireless communication network to a payment processor for a client, sending the RPC from a network node to a node connector and an optional firewall for a plurality of network nodes, thereby for implementing additional security and data flow between a network node pool or a network of network nodes (i.e., a plurality of network nodes associated with the payment processor). Additionally, advantageously, the node connector may provide a secure communication channel between an API converter associated with the payment processor and one or more network nodes in the pool.

[0060] In some embodiments, based on determining that a selected fee quote associated with a given transaction does not meet the current fee quote of a network node, e.g., if the current fee quote is higher than the selected fee quote, the method includes adding an output associated with the blockchain transaction to an auxiliary memory pool, which may be an additional temporary memory pool associated with the network node. As described above, the output may be stored in the auxiliary memory pool for a predetermined period of time, such that the network node may use such a temporary entry to check and advantageously ensure that there is no double spending associated with the given transaction.

[0061] With the increasing use of distributed ledger (blockchain) technology in many applications, which require secure, auditable, tamper-proof, and reliable recording of events or transactions associated therewith; solutions for participating entities (such as client or merchant entities) have traditionally relied on: real-time synchronizing a complete copy of the blockchain and directly identifying both transactions and embedded data related to the applications and associated digital wallets of the participating entities from the blockchain. However, with the evolution of the scope, capabilities, and security of clients (i.e., merchant applications), and with the expansion of the blockchain, in order to scale and fully realize and utilize the full potential of the advantages associated with the blockchain and make the solution available to any type of client or entity - regardless of their computational complexity, it is clear that a technical solution allowing participating parties to communicate directly is needed, and such applications for directly exchanging messages are needed. The fourth aspect of the present disclosure provides such a solution for clients associated with payment services, as discussed above in the first aspect.

[0062] According to a first implementation of the fourth aspect, the present disclosure provides a computer-implemented method for providing payment services for one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor. In some embodiments, the payment processor may be the payment processor as discussed in connection with the first aspect. The method includes the steps of: receiving, from a given client among one or more clients, a request for submitting a transaction associated with a digital asset to the blockchain. As described in the above aspect, the request is sent to the payment processor using the HTTP transport format. In some examples, the request is the second request for submitting a transaction received from the client as described above.

[0063] In a first implementation of the fourth aspect, the request from the client is associated with a callback identifier for enabling direct communication between the client and another entity. In some embodiments, the callback identifier may be an access point or URI or URL associated with the client. Other types of callback identifiers and mechanisms are also possible. Such a mechanism, discussed in detail below, is to provide a communication channel.

[0064] Subsequently, the method of the fourth aspect includes submitting the transaction associated with the request to a network node for including the transaction in the blockchain. In some embodiments, this step is similar to submitting a transaction according to the second request received from the client, as discussed in connection with the first aspect. The payment processor submits the transaction associated with the request and the callback identifier to a given network node among a plurality of network nodes.

[0065] In some embodiments, when a given network node receives a transaction submitted via the payment processor, as described in the first aspect and / or the second aspect and / or the third aspect above, a transaction identifier (TxID) associated with the corresponding blockchain transaction (which corresponds to the submitted request) is received as a response from the network node. In some embodiments, this includes receiving an output script, such as an unspent transaction output (UTXO), which is associated with the corresponding blockchain transaction, as described in the first aspect above. Subsequently, the transaction identifier (TxID) of the corresponding blockchain transaction is sent to the client.

[0066] The payment processor also identifies the given network node to the client by providing an access endpoint or a network node identifier (network node ID) or location associated with the network node. In some cases, the network node may be identified to the client as part of the above response with the TxID. It is advantageous for the client to have the TxID so that the client can track any further communication or message associated with the TxID. As described above, if the client chooses to initiate an inspection, the TxID can also be used for such an inspection of the status of the corresponding transaction.

[0067] Subsequently, the method includes enabling or processing, for a client, at least one callback notification associated with a corresponding blockchain transaction provided by a network node. In an embodiment, the payment processor enables the callback notification in a case where a callback identifier can be directly used by the network node (i.e., via the location or URL of the client) to contact the client regarding the corresponding transaction. If the identified callback requires further steps (such as providing an access token or exchange key, etc.) to initiate such direct communication, the payment process must handle such further access to allow the network node to communicate with the client using the callback identifier.

[0068] A second implementation of the fourth aspect of the present disclosure relates to an embodiment in which a request from a client for submitting a transaction is associated with a channel. In such a case, the channel identifier mentioned in the above first implementation is in the form of a channel configured to enable direct communication between a given client and another entity. A channel is such an implementation that is facilitated or provided by a channel service associated with the given client and is specific to a given topic or a given transaction of the given client. A channel can be identified by a location or URL associated with the client or a channel identifier.

[0069] The channel service can be provided by a separate channel processor, or can also be provided by the above-mentioned payment processor, or can be integrated with the client. In some embodiments, a channel is associated with one or more functions, including: a channel function or program related to data transmission; and / or a message function or program related to the data transmitted using the channel. Thus, a channel can enable a direct or point-to-point communication path or session between entities for the delivery of messages or data. In most embodiments, each channel is only used for two entities.

[0070] The UK patent application with application number 2007597.4, filed in the name of nChain Holdings Limited, describes in detail examples of channel services and / or channel processors, the subject matter of which is incorporated herein by reference.

[0071] In some embodiments, one or more functions are provided to the client in the form of an interface or access point, and in most cases, the one or more functions are specific to a given channel among multiple channels that may be associated with the client, for example, one function is specific to each transaction. In most embodiments, a channel can enable full-duplex transmission, i.e., two-way communication between the client and another entity. In some embodiments, communication may only be allowed in one direction, i.e., the client may wish to only send a message to another entity or only receive a message from another entity.

[0072] In some embodiments, the client can be the owner of multiple channels or associated with multiple channels, and the above-mentioned channel is one of the multiple channels, and these channels are channels based on one or more functions provided by the channel service. In some embodiments, the one or more functions are application programming interfaces (APIs) published for or provided to a given client, and the API includes: a channel API for one or more channels; and a message API for data (i.e., messages related to a topic, where the topic is associated with each channel or a given channel). The API can be understood as an endpoint, an interface, or a set of functions and programs that allow an entity (such as a client in this case) to create or manage an application, and the entity can access the characteristics or data of the application or other services. In this case, the API is used to implement the channel function and the message function.

[0073] In a second implementation, the request from the client is also associated with one or more access tokens for the channel. These tokens are provided by the channel processor. In some embodiments, the one or more tokens are configured for secure communication with another entity, the one or more tokens are related to a given channel, or even for one or more messages in a given channel. In some embodiments, the access token is an API token specific to a given channel or a given message. The access token, especially the API token, can act as a unique identifier of the entity or application requesting access to the channel in some embodiments. In some embodiments, the access token can be considered as the unique authentication credential assigned to the client, and can even be refined for each individual channel or a single message in each channel. In some embodiments, the access token can enable the client to provide these tokens to another entity for verification for each channel of the client. In this embodiment, the access token can be generated or provided by the client or the channel service for each transaction and for the network nodes associated with the transaction.

[0074] In some embodiments, a channel may be associated with a channel identifier, and the channel identifier is associated with the location of the channel or an access point. In some embodiments, each channel is associated with a specific channel identifier. The same given client may have multiple separate channels, each with its own unique identifier, which may correspond to a location or an endpoint via which the channel can be accessed. In some embodiments, a given channel is used to communicate with any other entity related to data, where the data is associated with a specific type or topic, and the data associated with each topic in the channel is one or more messages or transactions, or is included in one or more messages or transactions. Advantageously, having a specific channel for a specific topic or transaction ensures higher clarity, reliability, and flexibility for the client, especially in the case of a client such as a merchant entity, which may have multiple topics (such as transaction numbers, transaction IDs, or document numbers), and these topics need to be tracked or processed independently of all other topics or other transactions associated with the same client.

[0075] In an embodiment, in the case where the payment processor in a first implementation is also a channel processor (i.e., the payment processor implements payment services as well as channel services for the client), the method of the fourth aspect may further include providing access to a channel associated with a given client of a transaction to a network node. This is advantageous in embodiments where all communications of the client are managed by or implemented via the payment processor, such that the channel is also set up by the payment processor on behalf of the client. In some embodiments, access may be provided by making the channel identifier and / or location and one or more access tokens available to the network node, which may be required by the network node to access one or more channel functions and / or message functions or APIs associated with the channel in order to retrieve data from or write data to the channel for the client.

[0076] Once the channel has been provided or access to the channel has been provided, a callback notification associated with a corresponding blockchain transaction from the network node to the client is then provided using the channel. Thus, the network node can use the channel to provide data, i.e., write data into the channel using one or more channel functions and message functions or APIs, which are obtained using the access tokens of the corresponding channel.

[0077] In some embodiments, the callback notification for the client can be an alert or a message that is obtained immediately when data is written to the channel. In some cases, the notification includes a channel identifier. The callback notification is called a callback because it relates to a specific TxID or blockchain transaction of a given client that has been processed by the payment processor, i.e., has been sent by the payment processor to the network node. Advantageously, the channel enables messages or responses to be provided in the channel that has been specifically allocated the TxID of a given client.

[0078] In some embodiments, the callback notification relates to a notification of a double spend of a transaction that has been submitted by a given client and recorded on the blockchain. In this case, the data provided by the network node in the channel is a return payload that includes the following data:

[0079] - The transaction identifier (TxID) of the blockchain transaction that is a double spend; and, in some cases, optionally

[0080] - The service endpoint of the payment processor that submitted the blockchain transaction. This is useful in cases where the client is associated with multiple payment services, and thus, the identifier clearly indicates the payment processor that first submitted the request to the network node.

[0081] In some embodiments, the callback notification relates to proof that a transaction submitted by a given client is included in the blockchain, i.e., a Merkle proof. In this case, the data provided by the network node in the channel is a return Merkle proof in the channel, which is provided by the network node and includes the following data:

[0082] - The transaction identifier (TxID) of the blockchain transaction related to the Merkle proof;

[0083] - The block header of the block that includes the blockchain transaction; and

[0084] - An array of sibling hashes of the transaction identifier (TxID).

[0085] In some embodiments, one or more of the provided channel functions or message functions include a JavaScript Object Notation (JSON) API based on the Hypertext Transfer Protocol (HTTP) to enable access to, creation of, and / or management of one or more data or messages in the channel for callback notifications.

[0086] These data or callback messages associated with the callback notification provided via the channel can be particularly advantageous for many applications associated with the blockchain, because the network nodes can then use the channel to directly send to another entity (i.e., the client, in this case, the client that requested the transaction submission) the Merkle tree of the transaction submitted to the blockchain, including the proof or double-spending notification. This is useful because it means that the client (such as a merchant or other entity) no longer has to search the blockchain to find such a transaction to evaluate whether it has been mined. This is because it is advantageous that once mined, the proof is directly provided using the channel.

[0087] The method of the second implementation of the fourth aspect further includes storing the notification and / or providing the notification to the client. In some embodiments, when the client is offline or not communicatively coupled to the channel processor, the callback notification is stored by the channel processor, i.e., as a push notification of data that is queued in the channel for a given client. In other embodiments, when the client is online or communicatively coupled to the channel processor, the relevant data in the channel (which is associated with the callback notification) can be directly extracted from the channel.

[0088] Advantageously, the use of the channel allows for asynchronous processing of each request or message in a given channel. This allows for a seamless, accurate, discontinuous, or delayed processing flow of the messages in the channel, because for any given topic or transaction, the order as well as the messages are always clear, because the channel is specific to such a topic. This can be particularly useful for implementations or situations where the client or other entity may not be able to run or be online, or process any data associated with the callback notification. Thus, the above techniques enable the reliable transmission of requests and the accurate and sequential processing of requests using the channel even when one side of the channel is offline or unresponsive, because the messages will still be present in the channel when that side of the channel is next online or connected to the network, so that side of the channel can access the messages in the channel based on the notifications queued by the channel processor. As described above, the functions of the channel processor can also be implemented by the same entity that implements the payment processor.

[0089] In addition, other entities are able to access these messages in the order in which they are transmitted, regardless of how many other messages may have been provided in the channel. Thus, despite delays or interruptions in the connection, the processing of the messages in the channel can still be completed accurately and seamlessly as if there were no delays at all.

[0090] Accordingly, the second implementation of the fourth aspect described above and its embodiments associated with the present disclosure provide a secure, off-chain, peer-to-peer (point-to-point / direct) application messaging mechanism for processing transactions for a client by implementing a channel for direct communication. This aspect provides a mechanism through which parties can communicate securely, even in the case where one of the parties is temporarily offline. For client entities (such as merchants) associated with an enterprise or potentially representing an organization, such clients may have a large number of other entities (customers) transacting with them for a large number of goods. Thus, in such a scenario, it would be highly beneficial to communicate with one or more customers or transactions via a channel while decoupling or disconnecting any functionality related to the blockchain that maintains all such transaction records. By providing channel functionality as well as messaging functionality via the channel service, such clients can use a specific channel for a specific customer related to a specific transaction (such as a specific invoice or a query for a specific good) and can obtain any further information specific to such a transaction via the said channel at any time.

[0091] In a third implementation of the fourth aspect, the present disclosure provides a computer-implemented method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with a client. The third implementation is similar to the second implementation and is associated with similar advantages. The method includes the steps of: sending a channel request related to a channel service, the channel service being implemented by a channel processor. The channel processor can implement the channel service for the client, as described in the United Kingdom patent application with application number 2007597.4. The first request can be a Hypertext Transfer Protocol Secure (HTTPS) transport GET request to the channel processor. Subsequently, the method implemented by the client includes obtaining access to one or more functions that enable direct communication between a given client and another entity. Similar to the second implementation, the one or more functions include: a channel function or program related to one or more channels for transmitting data; and / or a messaging function or program related to the data transmitted using one or more channels. The client also obtains one or more access tokens for the channel, as described above.

[0092] Subsequently, the method includes sending a request to a payment processor implementing a payment service (such as the processor explained in the first aspect or the first implementation of the fourth aspect) for submitting a transaction associated with a digital asset to the blockchain. The request can be a Hypertext Transfer Protocol Secure (HTTPS) transport POST request to the payment processor, which can be associated with an HTTPS API.

[0093] Subsequently, the client obtains a response from the payment processor, which includes a transaction identifier (TxID) of a blockchain transaction corresponding to the submitted transaction. The corresponding blockchain transaction is related to the transaction submitted by the payment processor to the network node. The TxID received in the response is useful for tracking the blockchain transaction generated by the network node and corresponding to the TxID.

[0094] The client also receives, separately from or together with the above response, the identifier or access point or location of the network node providing the TxID from the payment processor.

[0095] Subsequently, by using one or more channel functions received from the channel processor, the method includes: creating a channel for communicating with the identified network node and sending one or more access tokens associated with the channel to another entity, which in this case is the network node. This advantageously enables a secure, reliable, and accurate establishment of the channel for direct communication between the client and the network node.

[0096] Subsequently, a callback notification is received from the channel processor, which can be received at the client when the client is online or communicatively connected to the payment processor. Based on this notification, when the client is online, the client can directly obtain data related to a specific blockchain transaction (i.e., the TxID associated with the client) from the network node.

[0097] Some embodiments of a third implementation of a fourth aspect relate to providing secure addressing and encryption for a channel for peer-to-peer communication. In some examples, the method includes: providing a client addressing key associated with the client and obtaining at least one network node addressing key associated with the network node. In some cases, if the client endpoint and the network node endpoint are not yet available to or known by the client, the client endpoint can also be provided, and the network node endpoint can be obtained. The addressing key can be a static key or a temporary key or both, and can be used to verify the identity of the corresponding endpoint. In this case, communication using the channel can be initiated based on the client addressing key and / or the network node addressing key, such that a shared key can be derived based on a handshake pattern. Subsequently, such a shared key can be used to encrypt all communications via the channel. The handshake pattern can be based on the Noise protocol format, but other mechanisms can also be used to derive the encryption / decryption key or key pair, such as the Libsodium key exchange or generation techniques.

[0098] Advantageously, endpoints (such as API endpoints for a client) and addressing keys (such as static keys and / or dynamic keys / temporary keys) are provided, allowing one or more processors associated with the client to securely access network nodes. In some embodiments, the keys also allow an authentication process to be initiated prior to any message transmission over the channel, thereby enhancing security by authenticating the identities of the parties managing the channel, ensuring that all communications over the channel occur only between two authenticated entities.

[0099] It is further advantageous to obtain a shared key for encrypting direct communications using the channel, as the shared key is identity-based (i.e., the addressing keys of the two parties or entities managing the channel). Thus, only the corresponding valid and authenticated parties can decode the encrypted ciphertext, enhancing reliability and privacy and resisting spoofing attempts by malicious parties.

[0100] In some embodiments, the endpoints for the client and / or the network node can be HTTP API endpoints, and wherein prior to communicating over the channel, the endpoints are transmitted to the other party (or counterparty) using the HTTP Secure (HTTPS) transport protocol. This advantageously ensures that the endpoints can be authenticated via a certificate chain pointing back to a known and trusted Certificate Authority (CA). In some embodiments, the client endpoint and the network node endpoint can be a Uniform Resource Locator (URL) that is included in a response to a request for one or more functions associated with the channel service. In the above manner, advantageously, the identity of one party can be known and authenticated by at least one party of the channel using PKI or other mechanisms.

[0101] In some embodiments, the endpoint for a client can be an alias associated with the corresponding entity of the channel, where the alias is specific to the client and provided by an alias-based addressing service that has a machine-readable resource accessible from a defined or known location, and the machine-readable resource includes one or more functions related to the channel processor. The alias can be known or provided to one or more other entries, and the alias is associated with an asymmetric encryption key pair for authentication. In the above manner, advantageously, both parties can use PKI or other mechanisms to know and verify the identities of both parties. There already exist such mechanisms in which memorable and more user-friendly aliases are used for one or more client entities instead of complex public addresses. Such a solution was proposed in the U.S. patent application with application number 16 / 384696 filed in the name of nChain Holdings Limited. These documents describe an alias-based payment service and an associated protocol, which is called the bsvalias payment service, where aliases are used for destination addressing instead of the public addresses of client entities. In such a system, the alias is typically associated with the domain name of the sending / receiving client entity and can be a URI or an email address. Thus, as long as the sender or entity knows or is provided with the alias, this is sufficient for the bsvalias payment system or other alias-based addressing mechanisms. For example, by using the instructions provided in the machine-readable resource, a message can be sent to the alias of the client, such as a JavaScript Object Notation (JSON) document, which is saved in a well-known URI or location for the bsvalias payment service or other payment services.

[0102] In a fourth implementation of the fourth aspect, the present disclosure provides a computer-implemented method for processing a transaction associated with a blockchain, which is implemented by one or more processors associated with a network node. The fourth implementation is similar to the first implementation and has similar advantages.

[0103] In this implementation, the network node receives a request from a payment processor to submit a transaction to the blockchain. In some embodiments, this can be similar to the second request from the payment processor discussed in the third aspect, which is for submitting a transaction on behalf of a client.

[0104] Subsequently, the method includes: generating a blockchain transaction corresponding to the request and sending a response and an output script (UTXO) associated with the blockchain transaction to the payment processor. The output script includes a transaction identifier (TxID) associated with the corresponding blockchain transaction. As described above, an access point or identifier associated with the network node can also be provided to the client together with the response.

[0105] Subsequently, access to a channel that is specific to the client for the TxID is received. This access can be provided directly by the client after creating the channel or by the payment processor on behalf of the client. As previously mentioned, the channel enables direct communication with a given client. An access token for accessing the channel to write data to the channel is also received.

[0106] Based on the access token, the network node can then obtain, access, or retrieve a messaging function or messaging API to provide data associated with a callback notification in the channel, which is related to the corresponding blockchain transaction (TxID). As mentioned above, the callback notification can be related to a double-spend notification or a Merkle proof of a given transaction, and the notification can be transmitted directly, securely, accurately, and asynchronously to the client via the channel.

[0107] Thus, in a fourth implementation, the network node can obtain a channel API or a messaging API associated with the channel and / or an access token to enable direct communication with the client. This is particularly advantageous for many applications associated with the blockchain, as the network node can then use the channel to directly send the Merkle tree including the proof or any other message specific to the transaction submitted to the blockchain to the client. This is useful because it means that there is no longer a need for the client (such as a merchant) or another entity (such as a customer or the actual payment service) to search the blockchain to find such transactions or verify their status. This is because it is advantageous that once mined, the proof can be directly sent to the client using the channel. Or, if for some reason the transaction associated with the TxID is not mined, messages such as error notifications or double-spend notifications can be sent for the transaction via the channel.

[0108] The present disclosure also provides a computer system that includes a payment processor communicatively coupled to at least one client and at least one network node via a wireless communication network. The payment processor is associated with an API converter for converting an HTTPS request from the client into an RPC request for the network node and vice versa, whereby the payment processor is implemented according to the first aspect. The computer system also includes a client communicatively coupled to the payment processor via the wireless communication network and capable of communicating with at least one customer, whereby the client is implemented according to the computing device of the second aspect. The client is also communicatively coupled to a channel processor via the wireless communication network, whereby the channel processor is implemented according to the computing device of the fourth aspect. The computer system also includes a plurality of network nodes, each network node communicatively coupled to the payment processor via the wireless communication network, whereby each network node is implemented according to the third aspect.

[0109] In some embodiments, a computing device including a processor and a memory is provided, the memory including executable instructions that, due to execution of the executable instructions by the processor, cause the device to perform the various aspects and / or embodiments discussed above.

[0110] In some embodiments, a computer-readable storage medium is provided, having stored thereon executable instructions that, due to execution of the executable instructions by a processor of a computer system, cause the computer system to perform the methods of the various aspects and / or embodiments discussed above.

[0111] Some specific embodiments are now described in a pictorial manner with reference to the accompanying drawings, in which like reference numerals represent like features.

[0112] First Aspect - Payment Processor

[0113] Figure 1 Relating to a first aspect of the present disclosure, and depicting a method for implementing a payment service for a client by a payment processor, as described above. The payment processor is communicatively coupled to a client or a plurality of clients, and is also communicatively coupled to a plurality of network nodes, which may include more than one network node network or more than one mining pool. In some embodiments, the payment processor may be part of the client or implemented in association with the client. This is the case if the client is a computationally complex merchant point-of-sale (POS) terminal. The aspects and embodiments of the present disclosure are envisioned to cover both implementations, namely, a remote payment processor, or an implementation as part of the client. Figure 4 An example system architecture is shown, which will be explained herein later.

[0114] In Figure 1 the example scenario shown, the embodiments associated with the following steps are all described as occurring in sequence and are described as Figure 1 a single process in the flowchart: obtaining a plurality of mining fee quotes, submitting a transaction based on a selected fee quote among the obtained plurality of mining fee quotes, and sending a status query related to the transaction identifier. However, the present disclosure and the first aspect should not be considered limited thereto. The steps related to obtaining a fee quote in the first request, among steps 102 to 106 described below, can be implemented separately and independently of the remaining steps. Similarly, the steps related to submitting a transaction in the second request, from steps 108 to 114, can be implemented separately and at a time different from the previous steps of obtaining a fee quote. In the same manner, the steps related to transaction status query, starting from step 116, can be implemented at any time after the client already knows the identifier of the transaction and do not need to follow Figure 1The order. All steps are shown in order in this document, which is only for ease of explanation and understanding, and in any case, the present disclosure should not be considered limited to such order or scenario.

[0115] Step 102 depicts receiving a first request from a client, the first request being for a mining fee quote associated with mining a transaction in a blockchain. The first request may also relate to multiple transactions. For ease of explanation and understanding, it will be explained in connection with a single transaction in the first request associated with the client Figure 1 , but the present disclosure is not limited in any way thereto. This step represents collecting mining fee quotes for mining a transaction on behalf of the client from multiple network nodes. A transaction typically involves a digital asset payment occurring between a client (i.e., a merchant computing resource or entity) and a customer entity. As described above, the first request is received from the client via the HTTPS protocol or using the HTTPS protocol and in JSON format. The payment processor implements a payment interface as an application programming interface (API) for the client, and thus since the API is implemented as a web service, the payment processor can accept and process HTTPS. API endpoints are available to the client. In the case where there are multiple transactions in the first request, the same API endpoint of the payment processor or separate API endpoints may be used.

[0116] For example, in some embodiments, the payment processor may implement payment services using a standards-based interface design such as a REST interface. REST (Representational State Transfer) is an architectural style used for developing web services and web-based interactions. The REST API design standard can use the following commands to handle HTTPS requests and communications:

[0117] Command GET POST PUT DELETE Resource Read Create Update Delete

[0118] This document will mainly discuss GET HTTPS requests and POST HTTPS requests, but the application is not limited to these commands. In step 102, the first request received by the payment processor may be an HTTPS request in the GET getFeeQuote format.

[0119] A resource in a REST API environment is an object that has a type, associated data, relationships with other resources, and a set of methods for operating on it. In some embodiments, a payment service is provided as an API implementation by a payment processor for accessing the state of a blockchain or distributed ledger, triggering operations that can change that state via an application interface, and disclosing that application interface as a REST API. Thus, the payment processor can be regarded as a REST endpoint for one or more clients. For ease of explanation only, one client (or merchant) and one payment processor will always be discussed, but the present disclosure is not limited thereto. Thus, the client can communicate with the payment service via HTTPS, and in addition, the client can advantageously access the payment processor or the payment service implemented by the payment processor anonymously. When there are more than one client and more than one payment processor, in some embodiments the client will be responsible for targeting or contacting the correct or intended payment processor or REST endpoint based on, for example, any agreements the client may have reached with one or more third parties running the payment processor.

[0120] Step 104 describes obtaining a fee quote for mining a transaction from each of a plurality of network nodes. In this step, the payment processor can poll or contact all the network nodes connected to the payment processor and request that these network nodes return the current fee quote for mining the transaction, i.e., writing the transaction to the blockchain after validating the locking script and unlocking script. Currently, some blockchain networks support communication via remote procedure call (RPC). Thus, in this case, an API converter associated with the payment processor is used to convert an HTTPS first request (i.e., GET getFeeQuote) into an RPC first request (i.e., RPC getFeeQuote()), and vice versa. This conversion is necessary in embodiments that support only RPC. As described above, the API converter can be part of a gateway processor or API gateway associated with the payment processor, where HTTP / RPC conversion is only one of the functions provided by the API gateway. The purpose of getFeeQuote() sent to the network nodes in RPC format is to notify the client of the fees charged by each network node. Although no input parameters are required, the RPC interface may need to be implemented in relation to RPC getFeeQuote() so that the command returns data of a data type in the form of a JavaScript Object Notation (JSON) object, i.e., NetworkNodeFeeQuote (network node fee quote), from each network node, which data type includes fee-related data collected from each network node.

[0121] Data collected from each network node and related to the obtained fee quotes can be defined as a JSON object, as shown in the following example.

[0122] The JSON object FeeQuotes returned from each network node is as follows. Although an example involving a single transaction is shown, the present disclosure is not limited thereto, and the present disclosure applies to fee quotes for mining fees representing multiple transactions:

[0123]

[0124]

[0125]

[0126] For ease of understanding, another example of the above JSON object FeeQuotes filled with data items is also given below:

[0127]

[0128]

[0129] In some embodiments, the JSON FeeQuotes object includes an array of network node details and the fees charged, and NetworkNodeFeeQuote is a JSON structure that includes network node data and fee data received from a single network node. Explanations of some terms in the above JSON object are as follows.

[0130] CurrentHighestBlockHash can be used as a marker to identify the block hash at the point where the blockchain has grown to at the time of calling getFeeQuote().

[0131] NetworkNodeSignature may include the signature of the network node that agrees to provide a guarantee for the transaction, as described above. This signature is different from the digital signature used to authenticate the identity of the network node. By doing so, the network node can guarantee that the network node will soon include the transaction in a block and will optionally not include any conflicting transactions. If the network node is not willing to provide a guarantee for the transaction, NetworkNodeSignature can be set to NULL (empty).

[0132] SignatureTimestamp refers to the time at which the network node guarantees to mine the transaction at the claimed current fee, that is, guarantees that the fee is from that point until it is revoked. If the client subsequently calls getFeeQuote(), this time is revoked.

[0133] NetworkNodeReputation is related to the measurement of network node performance, that is, the situation where a network node executes a transaction at the current fee of a commitment or quote. The reputation score / metric can be calculated, maintained, and managed by each payment processor.

[0134] The NetworkNode ID can be a two-part datum that is added to a transaction when a block is mined. If the NetworkNode ID does not exist, the payment processor may mark the network node with the NetworkNode ID as "NULL" or simply leave it blank.

[0135] In each NetworkNodeFeeQuote, an array of FeeTypes objects can be used to capture the various fee types currently available. Fee types can be introduced in the future without any changes to the getFeeQuote() interface provided by the payment processor. All transactions can have an array of FeeTypes.

[0136] Step 106 describes the payment processor providing the obtained fee quote to the client. In some embodiments, this can include a recommended fee quote determined by the payment processor. As described above in connection with the first aspect, this step can include the conversion from RPC to HTTPS via an API converter, enabling the client to access details using a web-based API.

[0137] In step 108, a second request is received from the client, which is a request to submit a given transaction related to the selected fee quote in the obtained fee quote. In some embodiments, the given transaction is a digital asset payment made by a customer in response to a payment request from the client to the client. For example, if the client is a merchant terminal in a coffee shop, this may be a digital asset payment in exchange for coffee. In this step, the client requests to write the digital asset payment to the blockchain via the payment service API implemented by the payment processor.

[0138] As described above, in some embodiments, the second request from the client can be a request to submit multiple transactions.

[0139] The selected fee quote in the second transaction can be based on a recommendation made by the payment processor or selected by the client for one or more transactions.

[0140] As described above, the selected quote can be based on the average or maximum of all the obtained fee quotes.

[0141] In some embodiments, the second request is an HTTPS request in the form of POST submitTransaction(Tx), where, in some embodiments, Tx is an object in JSON format associated with a given transaction for payment between a client and a customer. Thus, Tx (the JSON object) includes the data required to create a transaction on the blockchain, which the client can provide or construct as a JSON structure before submitting the second request to the payment processor for passing to the network nodes.

[0142] Step 110 describes the following steps: sending a request to one or more of a plurality of network nodes to generate a blockchain transaction corresponding to the given transaction in step 108. In this step, in some embodiments, the payment processor converts the HTTPS POST request in the previous step into an RPC request for submission to the network nodes. This can be done via RPC createRawTransaction(Tx), where Tx includes the data associated with the given transaction, given as a JSON object as discussed in step 108. RPC createRawTransaction(Tx) is an RPC call for creating a transaction by spending given inputs and creating new outputs, where the outputs can be addresses or data. The RPC request can be sent to multiple network nodes, or to the network nodes that meet or satisfy the selected fee quote from the client in step 108. As described above, the network nodes that have provided the current fee quote at or below the selected fee quote are considered to meet the requirements of the selected fee quote because these network nodes can mine the transaction at their respective current quoted fees. In response, the network nodes that meet the selected fee quote create a blockchain transaction corresponding to the given transaction. In some embodiments, the hexadecimal-encoded source transaction corresponding to the given transaction is returned to the payment processor.

[0143] In step 112, the output or output script associated with the corresponding blockchain transaction has been created by at least one of the network nodes that meet the selected fee quote among the plurality of network nodes, and the output or output script is received at the payment processor. The output script can be a UTXO, which is associated with the corresponding blockchain transaction created by the respective network node. In some embodiments, the UTXO can also be stored in the memory pool of the respective network node that meets the selected fee quote. The output in this step will include the transaction identifier (TxID) of the corresponding blockchain transaction created by the respective network node. The TxID is a reference to the hexadecimal-encoded transaction submitted to the network node memory pool, which is subsequently mapped by the payment processor to the blockchain transaction accordingly.

[0144] Subsequently, the blockchain transaction can be mined either immediately or later to complete the mining process according to the current fee quote. In some cases, the created transaction may not be mined because another network node has written the transaction to the blockchain, or the created transaction may be suspended or rejected for some reason (such as double spending, latency, or invalidity).

[0145] Step 114 describes sending a transaction result TxResult to the client, which includes a transaction identifier TxID of the blockchain transaction created by the corresponding network node corresponding to the given transaction in step 108. In some embodiments, the transaction result TxResult is a JSON object that is sent from the payment processor to the client using the HTTPS protocol based on the details of the corresponding blockchain transaction created by the corresponding network node that meets the selected fee quote in steps 110 and 112.

[0146] Examples of the details present in the TxResult object for the client are given below:

[0147] The JSON object TxResult shown below is for the corresponding network node and includes some terms and objects that were discussed as part of the FeeQuotes JSON object in step 104.

[0148]

[0149]

[0150] The ReturnResult described above can include one of the following possible values, which are shown below:

[0151] · Submitted - There are no problems and the transaction is submitted to the mempool

[0152] · Rejected_DS - Rejected due to double spending - DoubleSpendTxID cannot be null

[0153] · Rejected_Policy - Rejected due to violation of policy

[0154] · Rejected_Invalid - Rejected due to invalid transaction

[0155] · Rejected_FeeTooLow - The fee is too low, so the network node will not include the Tx in the block

[0156] Rejected_KeepInMemPool – The tx was rejected but kept in the mempool to be used for double spend checks.

[0157] Step 116 describes the step of receiving a status query associated with a transaction identifier TxID from a client to send the status query to a plurality of network nodes. After selecting a fee quote from a plurality of mining fee quotes, starting from step 116 can occur asynchronously with the aforementioned step of arranging for submission of the transaction, and step 116 is not considered necessary for the operation of the first aspect. The embodiment starting from step 116 relates to a scenario in which the client desires to know the status of one or more second requests made in step 108.

[0158] Step 116 enables the client to query the status of a transaction that the client has submitted to the payment processor via the HTTPS POST submitTransaction(Tx) discussed in step 108. Thus, the TxID in this step may correspond to any second request made for any given transaction related to digital asset payments between the client and its customers. As discussed in the above steps, the status query is received from the client using HTTPS as a transport protocol, the query being sent in JSON format (such as GET queryTransactionStatus(TxID)), which is then converted to an RPC request, RPC getRawTransaction(TxID), for transmission to one or more of the plurality of network nodes.

[0159] In step 118, the payment processor receives responses from the respective network nodes among the plurality of network nodes associated with creating and / or processing blockchain transactions associated with a TxID. In some embodiments, the above RPC getRawTransaction(TxID) may include a Verbose parameter, which may be associated with an argument set to 1. In this case, if a result is successfully returned from the respective network node, then in some embodiments, the result returned from the respective network node will be in JSON format, which includes the corresponding blockchain transactions decoded in steps 110 and 112. This advantageously provides flexibility in capturing and processing the data in the returned result. If the Verbose parameter is set to 0, a hexadecimal-encoded transaction, rather than a JSON data type or document format, will be returned to the payment processor. If no such transaction associated with the TxID is found, Null (empty value) may be returned, which in turn causes the ReturnResult object to be set to "Unknown". Any other returned error can also be reported by the network node to the payment processor via the ReturnResult and ResultDescription objects. These objects were represented in step 114.

[0160] In step 120, the TxResult related to the TxID is returned to the client, and the response is sent using HTTPS. This represents a mining result associated with the given TxID sent by the client in the status query in step 116. An example of the TxResult sent from the payment processor to the client is given below.

[0161] The JSON object TxStatus is as follows:

[0162]

[0163]

[0164] If the transaction has been successfully mined and marked as Confirmed (i.e., added to the block) by the respective network node, then the BlockHash and NetworkNodeID can be populated. If the network node does not set its NetworkNodeID, then the network node will be set to "NULL (empty)".

[0165] Subsequently, the ReturnResult object may include one of the following mining results:

[0166] · Submitted – No problem, the transaction was submitted to the memory pool

[0167] ·Confirmed – The transaction has been confirmed – The confirmation cannot be 0 or Null (empty)

[0168] ·Rejected_DS – Rejected due to double spending – DoubleSpendTxID cannot be Null (empty)

[0169] ·Rejected_Policy – Rejected due to violation of policy

[0170] ·Rejected_Invalid – Rejected due to the transaction being invalid

[0171] ·Rejected_FeeTooLow – The fee is too low, so the network nodes will not include the Tx in the block

[0172] ·Rejected_KeepInMemPool – The Tx is rejected but kept in the memory pool for double spend checking

[0173] ·Unknown – The transaction has not been seen or does not exist – The transaction with the provided TxID may not exist in the memory pool or the blockchain. If it does not exist, this should be stated in the ResultDescription.

[0174] Second Aspect - Client

[0175] Figure 2 Relates to a second aspect of the present disclosure and describes a method executed by one or more processors associated with a client, wherein the client is communicatively coupled to at least one payment processor that implements the method as discussed in connection with the first aspect. The payment processor implements for the client the payment service or payment API as discussed Figure 1 above, as discussed above.

[0176] In Figure 2 the example scenario shown, the embodiments associated with the following steps are described as occurring in sequence, i.e., are described as Figure 2The individual processes in the flowchart: obtaining multiple mining fee quotes, submitting a transaction based on a selected fee quote among the obtained multiple mining fee quotes, and sending a status query related to a transaction identifier. However, the present disclosure and the second aspect should not be considered limited thereto. The steps related to obtaining a fee quote in the first request among steps 202 to 206 described below can be implemented separately and independently of the remaining steps. Similarly, the steps related to submitting a transaction in the second request from steps 208 to 212 can be implemented separately and at a time different from the previous steps related to obtaining a fee quote. In the same way, the steps related to a transaction status query starting from step 214 can be implemented at any time after the client already knows the identifier of the transaction and do not need to follow Figure 2 the order. All the steps shown in sequence herein are only for ease of explanation and understanding, and in any case, the present disclosure should not be considered limited to such order or scenario. In addition, as discussed above in connection with Figure 1 it is possible to request and / or obtain and / or submit and / or query a fee quote separately for each individual transaction, or for a group or batch of multiple transactions submitted (i.e., submitted simultaneously) by the client in a single request each time. For ease of explanation and understanding, Figure 2 the explanation will be made in connection with a single transaction in the first request / second request and a status query associated with the client, but the present disclosure is not limited in any way thereto.

[0177] Step 202 describes sending a first request to a payment processor among at least one payment processor associated with the client for providing a corresponding payment service. As discussed in connection with Figure 1 step 102 of, this request is related to obtaining one or more fee quotes for mining a transaction for the client. The first request involves the HTTPS GET-FeeQuote discussed in step 102 above. As discussed above, this request can be a request for mining any transaction for the client or a request for obtaining a fee quote for mining a transaction related to a digital asset payment from a customer associated with the client.

[0178] In step 204, multiple mining fee quotes are received from the payment processor, and these fee quotes are related to the mining fees of each of the multiple network nodes communicatively coupled to the payment processor serving the client. The structure and details of the received fee quotes have been discussed in connection with Figure 1 step 104 of.

[0179] Step 206 describes selecting a fee offer from one or more fee offers received in step 204. In some embodiments, the selected fee offer can be based on a proposed recommended fee offer by the payment processor. In some embodiments, the selection is made by one or more processors associated with the client. As discussed above, the selected fee offer can be the average or median of the obtained fee offers, or the maximum of the fee offers obtained from multiple network nodes, or the highest fee offer in the secondary memory pool. Thus, the client can select the highest fee value obtained from multiple network nodes in response to the first request. In this way, all network nodes are provided with an equal opportunity to mine the transaction at their respective currently offered fees. However, the client can alternatively select a fee offer equal to or higher than the median or average of all received fee offers, such that network nodes with higher offers can simply retain the transaction in the secondary memory pool and use the transaction to check for and / or reject any double-spending of the transaction.

[0180] Step 208 describes the steps of requesting and / or processing a digital asset payment from a customer associated with the client. This can be a payment request or a document for a digital asset payment sent by the client to the customer using known methods applicable to the respective digital wallet implementations of both parties. Since the selected fee offer for mining any transaction is known for the blockchain, the request can include the selected fee offer or be associated with the selected fee offer.

[0181] Step 210 describes the steps of: sending a second request to submit a given transaction associated with the digital asset payment from the customer to the payment processor to the blockchain. The submission in this step is based on the selected fee offer for mining the given transaction in step 206. This step involves the client sending an HTTPS POST submitTransaction(Tx) request to the payment processor in Figure 1 step 108, where there are also relevant details for the given transaction in JSON data type format.

[0182] Step 212 describes the steps of: receiving a transaction identifier (TxID) of the blockchain transaction corresponding to the submitted transaction. As Figure 1 discussed in steps 110 and 112, the TxID is created by at least one network node that meets the selected fee offer. In some embodiments, the TxID can be sent associated with the transaction result or as part of the transaction result, i.e., TxResult shows the current mining status of the corresponding blockchain transaction of the respective network node. This is described in conjunction with Figure 1 step 114.

[0183] Step 214 involves the client sending a status query when the client desires to query the mining status of a previously submitted transaction (which involves a payment between the client and a customer) in step 210. Since the client has received the TxID of the submitted transaction in step 212, this request can be based on the TxID and in the format of HTTPS GET queryTransactionStatus(TxID), as Figure 1 discussed in step 116 of

[0184] Step 216 describes obtaining the mining status result of a blockchain transaction corresponding to the transaction identifier TxID queried in step 214. This mining status result can be in JSON format, and after the payment processor receives the details of the corresponding transaction, the payment processor sends this mining status result to the client using HTTPS. The status result can be in the form of a TxResult JSON object, as Figure 1 shown in step 120 of

[0185] Third Aspect - Network Node Implementation

[0186] Figure 3 Relates to a second aspect of the present disclosure and describes a method performed by a network node among a plurality of network nodes, where the plurality of network nodes are communicatively coupled to at least one payment processor that implements the method discussed with respect to the first aspect. The payment processor implements a payment service or payment API for the client as discussed with respect to Figure 1 The client is configured to implement the method combined with Figure 2 discussed.

[0187] In Figure 3 the example scenario shown, the embodiments related to the following steps are described as occurring in sequence, that is, as a single process in the flowchart described as Figure 3 : providing a plurality of mining fee quotes, generating / creating a blockchain transaction based on a selected fee quote among the obtained plurality of mining fee quotes, and providing a mining status related to the transaction identifier. However, the present disclosure and the third aspect should not be considered limited thereto. The steps related to providing a current fee quote in response to a first request in steps 302 and 304 described below can be implemented separately and independently of the remaining steps. Similarly, the steps related to generating a corresponding blockchain transaction in response to a second request from steps 208 to 212 can be implemented separately and at a different time from the previous step of obtaining the fee quote. In the same way, the steps related to providing a transaction status in step 316 can be implemented at any time after the client already knows the identifier of the transaction and do not need to follow Figure 3The order. All steps presented in sequence herein are for ease of explanation and understanding only, and in no case shall the present disclosure be considered limited to such order or scenario. Additionally, as discussed above in connection with Figure 1 and Figure 2 , a fee quote can be requested and / or obtained and / or submitted and / or queried individually for each single transaction, or for a group or batch of multiple transactions submitted by the client in a single request (i.e., submitted simultaneously) each time. For ease of explanation and understanding, Figure 3 it will be explained in connection with a single transaction in the first request / second request and a status query associated with the client, but the present disclosure is not limited in any way thereto.

[0188] Step 302 describes receiving a first request from a payment processor that requests a fee quote for mining a transaction on behalf of the client. This request pertains to an RPC getFeeQuote() request sent from the payment processor, as described in Figure 1 step 104 thereof.

[0189] Step 304 describes providing a current fee quote for mining the transaction in the blockchain for each of the multiple network nodes. The fee quote can be provided in the format of a JSON object FeeQuotes, as described in Figure 1 step 104 thereof.

[0190] Step 306 describes the steps of: a network node among the multiple network nodes receiving a second request that pertains to submitting a given transaction associated with the client to the blockchain, wherein the given transaction is based on a selected fee quote from the client. The given transaction is related to the Tx in Figure 2 POSTsubmitTransaction(Tx) in step 210 (i.e., a given digital asset payment transaction between the client and the customer). The RPC version of the given transaction received from the payment processor is the RPC createRawTransaction(Tx) of the given transaction, as described in Figure 1 step 110 thereof.

[0191] Step 308 describes checking whether the network node meets or satisfies the selected fee quote from the client. This can include determining whether the current fee quote provided by the corresponding network node to the payment processor in step 304 is equal to or lower than the selected fee quote, which is the fee quote that the client is willing to pay for mining the given transaction.

[0192] If the current fee quote meets the selected fee quote, then in step 310, a blockchain transaction corresponding to the given transaction is created. This will be discussed in conjunction with Figure 1 step 110. In some embodiments, the hexadecimal-encoded source transaction corresponding to the given transaction is returned to the payment processor. As Figure 1 discussed in step 112, the output script or UTXO is also provided to the payment processor, where the output script includes a transaction identifier (TxID) associated with the corresponding blockchain transaction created by the respective network node. Subsequently, the output script (UTXO) of the blockchain transaction can be added to the memory pool associated with the network node for immediate or later mining.

[0193] If the current fee quote does not meet the selected fee quote, i.e., if the current fee quote of the respective network node is higher than the fee quote allowed or selected by the client, then in some embodiments, the respective network node can choose to mine at a fee lower than the current fee quote, or can choose not to mine the given transaction because the selected fee is lower than their respective currently quoted fees. In embodiments where the respective network node does not choose to mine the transaction at the lower selected fee quote, in step 312, the respective network node can alternatively add details to an auxiliary memory pool associated with the respective network node, where the details are related to the blockchain transaction constructed for the given transaction. In some embodiments, the transaction can be retained in the auxiliary memory pool and used to check for double-spending. All transactions stored in the auxiliary memory pool can have an expiration time after which they can be purged.

[0194] Assuming that the blockchain transaction has been created, i.e., the respective network node meets the requirements of the selected fee quote set by the client, then step 316 involves the respective network node receiving a status query associated with the TxID of the blockchain transaction created for the client. The status query is based on the RPC getRawTransaction(TxID) received via the API converter, as discussed in conjunction with Figure 1 steps 116 and 118.

[0195] In step 318, a result based on the current mining status of the corresponding blockchain transaction related to the respective network node is provided to the payment processor. The result can be based on the JSON object structure of TxStatus, as discussed in conjunction with Figure 1 step 120.

[0196] Figure 4It is a schematic diagram of the deployment architecture of a payment service, which is provided to the client 402 as an API by the payment processor 404. There can be more than one such payment processor 404, and one or more payment processors 404 can also be implemented as part of the client, or can be associated with the client, or can be implemented independently of the client and communicate with the client through a communication network such as the Internet. As discussed in the above aspects, the communication between the client 402 and the payment processor 404 uses the HTTPS protocol. The API converter 406 is also shown separately in this schematic diagram, but in some embodiments, the API converter 406 can be implemented as part of the payment processor 404. In some embodiments, the API converter 406 can be operated by or associated with multiple network nodes 412-1 to 412-n. The API converter 406 allows the HTTPS request to be converted into an RPC request before sending the HTTPS request to one or more network nodes 412-1 to 412-n (which are connected to the payment processor 404 for providing services to the client 402). The API converter 406 is shown connected to the network nodes 412-1 to 412-n via the firewall 408. All communications associated with the network nodes 412-1 to 412-n use RPC. The node connector 410 is also shown, which is used to connect the multiple network nodes 412-1 to 412-n to the payment processor 404 via the firewall 408. In some embodiments, the node connector can ensure or process the RPC call, which is associated with one or more payment processors implementing the corresponding payment service, as described in connection with Figure 1 discussed. The node connector 410 provides a secure communication channel between the API converter 406 and one or more network nodes 412-1 to 412-n.

[0197] There can be one or more payment processors 404, which are connected to the network nodes 412-1 to 412-n via the API converter 406. The client 402 will most likely include a digital wallet application for obtaining a quote for the network node fee (getFeeQuote), submitting a transaction (submitTransaction), and querying the status of a transaction (queryTransactionStatus), as described for single or multiple transactions in connection with the first to third aspects. The payment processor 404 acts as a REST endpoint to the client 402, and the client can access the service anonymously.

[0198] Figure 5 is a schematic diagram that depicts Figure 4The data flow between the architecture components shown for implementing the getFeeQuote command or template from the client. This data flow has been discussed in detail in conjunction with Figures 1 to 3 above. Figure 4 Only the interactions for obtaining a mining fee quote between the client, the payment processor, and the network nodes are shown schematically. When the HTTPS GET getFeeQuote command is sent in step 501, the data flow originates from the client 402 and goes to the payment processor 404. In step 502, the GET command is sent to the API converter 406, which converts the GET command into an RPC command RPC getFeeQuote() in step 503. In step 504, NetworkNodeFeeQuote is returned from each of the network nodes 412-1 to 412-n to the API converter 406 in JSON object format, and NetworkNodeFeeQuote is then provided to the payment processor 404 in step 505. Steps 502 to 505 are repeated for each of the network nodes 412-1 to 412-n, and in step 506, the result (the fee quote) is sent to the client 402 in an HTTPS transmission.

[0199] Figure 6 is a schematic diagram that depicts Figure 4 The data flow between the architecture components shown for implementing the submitTransaction command or template from the client. This data flow has been discussed in detail in conjunction with Figures 1 to 3 above. Figure 4Only schematically shows the interaction between a client, a payment processor, and network nodes for providing a blockchain transaction associated with a payment of the client. When the HTTPS POST submitTransaction(Tx) command is sent in step 601, the data flow originates from the client 402 and goes to the payment processor 404 for a given transaction Tx between the client 402 and the customer. As described in connection with the above aspects, Tx may be associated with a selected fee quote (not shown in this figure). In step 602, the POST command is sent to the API converter 406, and the API converter 406 converts the POST command into an RPC command RPC createRawTransaction(Tx) in step 603. Subsequently, a blockchain transaction is constructed for each network node 412 that meets the selected fee quote. In step 604, the hexadecimal-encoded blockchain transaction is returned to the API converter 406. The transaction includes a specific identifier TxID, as described in the above aspects. In step 605, the output associated with the blockchain transaction is sent to the payment processor 404. Subsequently, in step 606, the result related to the blockchain transaction is returned to the client as a JSONTxResult object including TxID.

[0200] Figure 7 is a schematic diagram that depicts Figure 4 the data flow between the architecture components shown for implementing the queryTransactionStatus command or template from the client. The data flow has been described in detail in connection with Figures 1 to 3 the above. Figure 4 Only schematically lists the interaction between a client, a payment processor, and network nodes for providing a blockchain transaction associated with a payment associated with the client. When the HTTPS GET queryTransactionStatus(TxID) command is sent in step 701, the data flow originates from the client 402 and goes to the payment processor 404 for a given transaction TxID related to the blockchain transaction, and the given transaction TxID is used as Figure 6Part of the submitTransaction flow in [reference] was previously returned to the client. In step 702, a GET command is sent to the API converter 406, which in step 703 converts the GET command into an RPC command RPCgetRawTransaction(TxID). Subsequently, a blockchain transaction related to the TxID associated with the given network node 412 is identified. In step 704, the identified hexadecimal-encoded blockchain transaction and its associated status are returned to the API converter 406. In step 705, the status result associated with the blockchain transaction related to the TxID is sent to the payment processor 404. Subsequently, in step 706, the status result related to the blockchain transaction of the TxID is returned to the client as a JSON TxStatus object.

[0201] In addition, as discussed above in connection with Figure 1 and Figure 3 it is possible to separately request and / or obtain and / or submit and / or query a fee quote for each individual transaction, or for a group or batch of multiple transactions submitted (i.e., submitted simultaneously) by the client in a single request. For ease of explanation and understanding, Figures 4 to 7 it has been explained above in connection with a single transaction of the first request and / or second request associated with the client and / or status query, but it will be understood that the present disclosure is not limited in any way thereto.

[0202] Fourth Aspect - Callback Identifier

[0203] Figure 8 is a flowchart that depicts a method for facilitating a callback mechanism for transactions according to a fourth aspect. This figure relates to a method implemented by one or more processors associated with a payment service, as discussed above in connection with the first aspect.

[0204] Step 802 includes receiving a request from a given client among one or more clients. The request relates to submitting a transaction associated with a digital asset. For example, the request may be Figure 1 the second request for submitting a transaction as explained in step 108 of [reference]. The request is also associated with a callback identifier. In some embodiments, the callback identifier may be a callback identifier provided by the client, or a callback identifier associated with the client. For example, the callback identifier may be a URL or API endpoint through which the client can be contacted. In some cases, the callback identifier may also point to a location associated with the client. In some cases, the callback identifier may be a location or an identifier communication channel. Such a channel will be described below in Figures 9 to 11For further explanation. The purpose of the callback identifier is to enable or allow a measure to establish direct communication between a client and another entity. The callback identifier is specific to the client and, in some cases, specific to a particular topic, such as a transaction associated with the request in this step.

[0205] Step 804 includes submitting a transaction associated with the request to a given network node among a plurality of network nodes to include the transaction in the blockchain. This is similar to Figure 1 the process performed for the second request in step 110 of

[0206] Step 806 includes identifying the given network node to the client. This can be performed by many techniques, such as providing the client with an endpoint or URL associated with the given network node. This can be sent to the client using the HTTPS transport protocol. In some cases, if the network node is associated with an alias used for addressing (such as using the bsvalias addressing service mentioned above), the alias can be provided to the client. In some cases, if the network node is associated with the above-mentioned NetworkNode ID (network node ID) and / or reputation, such information can also be provided to the client. In some cases, this identification step can be completed together with or after step 812 described below.

[0207] Step 808 includes providing the callback identifier described in step 802 to the network node so that the network node can directly contact the client using the callback identifier. In some cases, if a payment processor processes the communication on behalf of the client, the callback identifier can point to the payment processor. This figure relates to the scenario where the callback identifier is used for the client, but the present disclosure is not limited thereto. For example, the callback identifier can be an encrypted identifier (endpoint) that uniquely identifies the client or the payment processor.

[0208] In step 810, a response is received from the given network node, where the response has details related to the corresponding blockchain transaction that was generated in step 802 for the transaction request. The response will include the transaction identifier (TxID) of the transaction, and the transaction identifier (TxID) can be provided to the customer. In some cases, the identity of the network node in step 806 can be provided to the client when or after receiving the TxID. In some embodiments, the response in this step includes an output script, such as an unspent transaction output (UTXO), which is associated with the corresponding blockchain transaction mentioned in the first aspect above. Subsequently, the transaction identifier (TxID) of the corresponding blockchain transaction is sent to the client.

[0209] Step 812 includes enabling or processing at least one callback notification for the client based on the callback identifier mentioned in step 802, where the at least one callback notification is related to a corresponding blockchain transaction (TxID) provided by the network node. If the callback identifier is the callback endpoint URL or URI of the client, the message can be directly provided to such location as an HTTP POST message. The message can be encrypted based on one or more known techniques.

[0210] Figure 9 Relating to a second implementation of the fourth aspect of the present disclosure, where the callback identifier associated with the request is related to the channel provided by the channel processor to the client. As described above, the channel processor can be a separate entity that provides channel services to the client, or can be the same entity as the payment processor. The following steps in this figure describe an embodiment implemented by the channel processor.

[0211] Step 902 describes receiving a request associated with the channel from a given client that has subscribed to the channel service, such as discussed in the UK patent application with application number 2007597.4 filed in the name of nChain Holdings Limited. This request in this embodiment is related to creating a channel. However, the channel service can implement other functions, such as updating the API associated with an existing channel. In most cases, the identity of the client can be checked to see if the client has registered to use the channel service and its provided functions. In some embodiments, this can be based on known authentication methods during registration, such as password-protected login authentication, etc. The verification can be based on the received password that matches the password in the stored record. In other embodiments, standard PKI techniques based on encrypted or addressed private / public key pairs can also be used to verify the digital signature that may exist in the request received from the client in step 902. In this case, the identity of the client can be verified by checking if the request signed by the private key can be successfully recovered or verified using the public key. If the client is invalid or not registered, either the request in step 902 is not further processed, or the registration step may be initiated by the channel service.

[0212] In step 904, the requested channel function and / or message function is provided to the client.

[0213] Some examples of the patterns and / or formats associated with requests for creating channel functions and / or message functions / APIs are shown below, as well as an example pattern of the response provided by the channel processor.

[0214] Channel API: The channel API can be a JSON client account based on an HTTP API provided by the channel service for creating and / or managing channels for peer-to-peer communication.

[0215] In some embodiments, all API endpoints may require authentication. The specific authentication scheme can be determined for the implementation. Common forms include schemes such as OAuth, basic authentication, and bearer token method. As mentioned above, the channel API can optionally be protected by API tokens, which are provided or generated by the client.

[0216] Create Channel: Create a new channel owned by the client (i.e., the account holder of the channel service)

[0217] Request Format:

[0218]

[0219] Response Format:

[0220] The response for successful creation includes an initial access token. Account credentials can be used to access the channel API, but the token may be required to access the Messaging API. This initial access token for this purpose belongs to the account holder for the purpose of these account holders to read and write to the channel.

[0221]

[0222] The Message API allows account holders and related counterparties (another entity of the channel) to read messages from a given channel or write messages to a given channel. The following Message API can be provided as a JSON-over-HTTP API based on the HTTP API for account holders and their trading counterparts to exchange messages.

[0223] 2.1 Test Channel for New Messages

[0224] Request Format:

[0225] HEAD / api / channel / <id>

[0226] Authorization: <api-token>

[0227] Response format:

[0228] 201OK

[0229] ETag: <max-sequence>

[0230] 2.2 Write the message to the channel

[0231] Request format:

[0232] POST / api / channel / <id>

[0233] Authorization: <api-token>

[0234] Content-type:...

[0235] Content-length:...

[0236] Response format:

[0237] a) Accepted (Accepted)

[0238] The information is written to the channel

[0239] 201 Created (Created)

[0240] b) Queuing failed

[0241] The channels are created sequentially and the API token associated with the request has not been marked as having read the latest message in the channel. If it is still appropriate, the client may need to retry the write attempt.

[0242] 409 Conflict

[0243] c) Message too large

[0244] In embodiments where all messages are protected by end-to-end encryption, such as based on the Noise protocol, the maximum size of any single message is set to 65536 bytes. Since there should be no messages larger than this byte, in some embodiments, it may be useful to limit the maximum size of any message written to the channel. Messages larger than this byte may be rejected by the channel.

[0245] 413 Payload Too Large

[0246] d) Exceeded storage quota

[0247] In some embodiments, the quota set by the service operator may have been exceeded. The client request may be valid, but the storage service cannot satisfy the request at this time.

[0248] 507 Insufficient Storage

[0249] 2.3 Get messages in the channel

[0250] Returns all messages from the channel, which are optionally filtered to be unread.

[0251] Request format:

[0252] GET / api / channel / <id>[?unread=true]

[0253] Authorization: <api-token>

[0254] The unread query string parameter is optional. Response format:

[0255]

[0256] 2.4 Mark the message as read or unread: Mark the message as read or unread

[0257] Request format:

[0258] POST / api / channel / <id> / <sequence>[? older=true]

[0259] Authorization: <api-token>

[0260] Content-type:application / json

[0261] Content-length:...

[0262] {"read":true|false}

[0263] The optional order parameter allows the client to include in a single call orders lower than or equal to the provided <sequence>All message tags of the path variable are marked as read.

[0264] Response format:

[0265] 201OK

[0266] In step 906, the access token or API token associated with the requested channel is provided to the client. If necessary, in some embodiments, the access token can also be invalidated or revoked, for example if the permission has been modified or the client no longer requests permission for a given channel.

[0267] An example pattern for this case is as follows:

[0268] 3.1 Generate channel API token

[0269] Request format:

[0270]

[0271] Response format:

[0272] This is just an API call that returns the token value. If lost, the token should be deleted or replaced with a new one.

[0273] 201Created

[0274]

[0275] 1.6 Revoke channel API token

[0276] Request format:

[0277] DELETE / api / account / <account-id> / channel / <channel-id> / api-token / <token-id>Authorization:...

[0278] Response format:

[0279] 204 No Content

[0280] Step 908 shows providing notifications or alerts or any other information that is securely sent to the client from another entity (such as a client) regarding a particular subject (such as a transaction). Figure 8 In the embodiment shown, the entity is a network node). Therefore, this is called a callback notification related to a specific transaction, which may have Figure 8 The callback notification can be a notification of a state change or can be any other notification in case of an exception in a given transaction or topic (for which a channel was created).

[0281] Since notifications are received via channels, the client does not need to be online all the time, and notifications can be delivered asynchronously whenever the client connects or reconnects (comes online) to the channel processor. In some cases, settings can be provided that can enforce a minimum time that a client should remain connected, or settings can ensure that the client remains connected until all "unread" alerts or notifications in the channel are consumed by the client or a wallet associated with the client. Therefore, in some embodiments, once a notification is consumed or received by the client from a channel, the client may be allowed to disconnect. Many such channels may be provided for a given client - one for each topic or transaction.

[0282] In some embodiments, there may be an additional step to detect whether the client is connected to the channel processor, i.e., whether it is online or offline. This detection can be done by known techniques to check whether there is a network connection with the client when one or more notifications or messages arrive in the channel.

[0283] When a client is online, callback notifications or messages for the client are "pulled" by the client once they enter the channel to ensure synchronization, that is, synchronization with the messages in the channel and the messages transmitted to the client.

[0284] If the client is not connected or offline when channel notifications arrive, these notifications are stored in a memory or cache associated with the channel processor. In some embodiments, this can be specific to a given client. Once the client is online or it is detected that the client is connected, these notifications are pushed or provided to the client entity. Push notifications can be sent to the client so that the client can obtain data or unread messages in the channel. Therefore, when the client is offline, the messages or notifications are stored by the channel service or channel processor. Once the client is online, these messages or notifications will be provided to the client.

[0285] Although any type of message can be sent in the channel when another entity is a network node that mines transactions from the client, in most cases, the scenarios of direct communication between the network node and the client are as follows:

[0286] 1. When the transaction status is updated or changed

[0287] 2. When a special request for information is received from the network node

[0288] In the first scenario, a callback notification is issued whenever the client needs to be notified of a status change or an anomaly (such as a double spend of a transaction), or to confirm mining, or to confirm the validity or invalidity of a transaction, etc.

[0289] In the second scenario, the client can directly request a status update from the network node at a certain time (which may be periodic or arbitrary) using the same channel.

[0290] Figure 10 A third implementation related to the fourth aspect of the present disclosure, in which the client is associated with a channel service implemented by a channel processor, as Figure 9 shown. The third implementation is applicable to such embodiments, in which Figure 8 the callback identifier in is a channel created by the client by using the channel service. The following steps in the figure describe an embodiment implemented by the client.

[0291] In step 1002, the client prepares a request for the channel service and sends the request to the channel service (channel processor). The prepared request can be sent by the client in a format using the Hypertext Transfer Protocol (HTTP) or a similar transport protocol. In some embodiments, the prepared request is sent to a channel processor implemented as an HTTP or REST API, and the response can also be provided to the client in the HTTP transport protocol format. As described above, the channel processor can be the same entity as the payment processor or can be a separate entity.

[0292] The request in this embodiment relates to creating a channel that can enable, allow, or provide a mechanism for direct communication with another entity (such as a network node).

[0293] In step 1004, one or more functions (such as channel functions or message functions / APIs) are received from the channel processor to enable the client to create a channel to ensure direct communication with another entity. These channel functions and message functions are shown in Figure 9 step 904 and are received from the channel processor. A message API for the channel and an access token for the request are also received (as shown in step 906).

[0294] Step 1006 describes sending a request to a payment processor to request submission of a transaction associated with a digital asset. The transaction can be a payment transaction or a similar transaction associated with a customer of the client. This step is similar to Figure 2 step 208 of Figure 8 and is also as described in step 802 above in connection with

[0295] In step 1008, a transaction identifier (TXID) is received from the payment processor. This is based on a response from a given network node, as described in Figure 8 step 810 of

[0296] In step 1010, the client identifies or learns of the network node that has sent the TxID to the payment processor in the previous step. This can be based on an API or location or NetworkNode ID (network node ID) associated with the network node and / or reputation, as discussed in Figure 8

[0297] In step 1012, the API received from the channel processor in step 1004 is then used to create a channel that is associated with the network node identified in the previous step 1010. The received access token can be used to authenticate other entities and provide access to various functions associated with the channel. In some embodiments, the message API as well as the access token can be sent to another entity for communication via the channel. In some embodiments, after the channel is created, a handshake protocol can occur between the client and the network node to establish a key that is used to secure communication via the channel. Any known method, such as the Noise Protocol Framework or the Libsodium key exchange mechanism, can be used for this purpose.

[0298] In step 1014, a response is received from the network node via the channel. This is possible because the other party (i.e., the network node) has received all the required message APIs and access tokens in the previous step to communicate directly with the client at that time. The response from the network node will be associated with the specific TxID in step 1008, so the communication in the corresponding channel will be specific to that transaction identifier. The message can relate to any matter associated with the TxID. For example, a notification can be sent via the channel to inform the client that the TxID is a double spend of a previous transaction. This can occur if the transaction already exists in the temporary memory pool. Or, once the transaction is included in a block, the message can be associated with the Merkle mining proof of the transaction.

[0299] Figure 11 ​Relates to a fourth implementation of the fourth aspect of the present disclosure, where the client is associated with a channel service implemented by a channel processor, as Figure 9 shown. The fourth aspect is applicable to such embodiments, where Figure 8 the callback identifier in is a channel created by the client by using the channel service. The following steps in the figure describe an embodiment implemented by a network node.

[0300] In step 1102, the network node receives a request for a mining transaction from a payment processor, as Figure 8 shown in step 804 of.

[0301] In step 1104, the network node generates a blockchain transaction. This step is similar to Figure 3 step 310 of, where in some embodiments, a hexadecimal-encoded source transaction corresponding to the submitted transaction is generated. Thus, an output script or UTXO is provided, which includes a transaction identifier (TxID) associated with the corresponding blockchain transaction that has been created by the corresponding network node. Then, the output script (UTXO) of the blockchain transaction can be added to the memory pool associated with the network node for immediate or later mining.

[0302] In step 1106, the transaction identifier (TxID) of the corresponding blockchain transaction is then sent to the client via the payment processor, so that the client can access the TxID and also identify the network node.

[0303] In step 1110, once the client creates a channel to communicate directly with the network node by using the channel service, the network node receives access to the channel from the client via any associated message API and access token.

[0304] In step 1112, the network node checks whether the transaction submitted in step 1102 is a double spend of a previous transaction. As described above, this can be achieved by checking whether the same transaction exists in the auxiliary or temporary memory pool associated with the network node, or by checking whether the same transaction has already been mined in the blockchain.

[0305] If this is the case, the network node then generates a double spend notification or alert to send back to the client using the channel. A double spend notification is issued when a network node, incentivized to maintain its reputation (which can be tracked by the NetworkNode ID of the network node), notifies the client that there is an attempt to spend a digital asset that has previously been spent by the same client (i.e., the merchant wallet).

[0306] One version of the example pattern can be:

[0307] Request:

[0308] {

[0309] "txId":"tx_Id"

[0310] "callbackURL":" / api / v1 / account / 1 / channel / <channel-id>,

[0311] "type":"doubleSpend"

[0312] }

[0313] Response:

[0314] {

[0315] "apiVersion":"0.1.1",

[0316] "timestamp":"2020-07-15T11:40:29.826Z",

[0317] "networknodeId":

[0318] "03fcfcfcd0841b0a6ed2057fa8ed404788de47ceb3390c53e79c4ecd1e05819031","BlockHash":"986544449afaec80fcabbbf08dcd82d392cf68c9a13fe29da1a0ccfnrhr",

[0319] "BlockHeight":207,

[0320] "callbackTxId":"6bdbcfab0526d30e8d68279f79dff61fb4026ace8b7b32789af016336e54f2f0",

[0321] "callbackReason":"doubleSpend"

[0322] }

[0323] Another version of the example pattern for the double spend notification is given below:

[0324] Request:

[0325]

[0326] In step 1116, the double - spend callback notification or "callbackpayload" as described above is sent to the callbackURL, which in this embodiment is the channel to which the network node has received access rights. The channel can be identified by an API or a location or an identifier. The notification is added to the channel by using a message API and an access token, which are associated with the channel that has provided access rights to the network node.

[0327] If the transaction submitted in step 1102 is not a double - spend, then in step 1118, the network node continues to mine the transaction in a block associated with the blockchain by using known mining techniques, some of which are discussed in the background of the present application.

[0328] In step 1120, the network node then generates a proof that the transaction is included in the block.

[0329] In some embodiments, the proof can be a Merkle tree proof. This is a known and verifiable data structure that is organized as a tree. The hash of each data block is stored in a node at the base layer or leaf, and each internal node of the tree or branch includes an encrypted hash that is calculated based on the hashes of its two child / sibling nodes. The top node of the tree (i.e., the Merkle root) uniquely identifies the data set from which the tree is constructed. Thus, the Merkle tree enables an efficient inclusion proof, where the network node or the proving node shows a submitting or verifying node that a certain data block is part of a verified data set by sending a proof with an audit path to the submitting or verifying node. The audit path includes the node hashes required to recalculate the Merkle root without the submitter disclosing the entire data set.

[0330] An example pattern can be:

[0331] Request:

[0332] {

[0333] "txId":"tx_Id"

[0334] "callbackURL":" / api / v1 / account / 1 / channel / <channel-id>,

[0335] "type":"merkleproof"}

[0336] Response:

[0337] {

[0338] "apiVersion":"0.1.1",

[0339] "timestamp":"2020-07-15T11:40:29.826Z",

[0340] "networknodeId":

[0341] "03fcfcfcd0841b0a6ed2057fa8ed404788de47ceb3390c53e79c4ecd1e05819031","BlockHash":"986544449afaec80fcabbbf08dcd82d392cf68c9a13fe29da1a0ccfnrhr",

[0342] "BlockHeight":207,

[0343] "callbackTxId":"6bdbcfab0526d30e8d68279f79dff61fb4026ace8b7b32789af016336e54f2f0",

[0344] "callbackReason":""

[0345] }

[0346] Another version of the example pattern of the Merkle proof notification is given below:

[0347] Request:

[0348]

[0349]

[0350] Response:

[0351]

[0352] In step 1122, the network node directly sends the proof including the transaction in the blockchain to the client through the channel to which it has access rights. Therefore, the client or payment processor does not need to run a copy of the blockchain or search the blockchain to find the transaction.

[0353] Turning now to Figure 12 , which provides an illustrative simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems shown and described above. For example, the computing device 2600 may be configured to serve as one or more components of a DBMS in the figures, or the computing device 2600 may be configured to be a client entity associated with a given user that issues database requests to a database managed by the Figure 12 DBMS. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As Figure 12 shown, the computing device 2600 may include one or more processors that have one or more levels of cache memory and a memory controller (collectively labeled 2602), which may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and a persistent memory 2610. As shown, the main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used to store information, such as details associated with the transactions and blocks described in the present disclosure. The one or more processors 2602 may be used to provide the steps or functions of any of the embodiments described in the present disclosure.

[0354] The one or more processors 2602 may also communicate with one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616.

[0355] The bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as expected. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may employ multiple buses.

[0356] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface for receiving data from other systems of the computing device 2600 and sending data to other systems of the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network such that the data technician can transfer data to and receive data from the device when at a remote location, such as a data center.

[0357] The user interface input device 2612 may include one or more user input devices such as a keyboard; pointing devices such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touchscreen incorporated into a display; audio input devices such as a speech recognition system, a microphone; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0358] One or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display (such as an audio output device, etc.). The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projector, or other display devices. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate interaction between a user and an application that performs the processes and variations described herein.

[0359] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) may provide the functionality of one or more embodiments of the present disclosure when executed by one or more processors and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent memory 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM or DVD or Blu-ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in the present disclosure and data associated with the transactions and blocks described in the present disclosure.

[0360] The computing device 2600 can be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 can include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that can be connected to the computing device 2600 can include multiple ports configured to accept fiber optic connectors. Thus, the device can be configured to convert optical signals into electrical signals, which can be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 depicted in Figure 12 is only intended for the purpose of being a specific example for illustrating a preferred embodiment of the device. Many other configurations with more or fewer components are possible compared to the Figure 12 system shown.

[0361] The exemplified embodiments listed

[0362] This disclosure hereby discusses based on the following terms related to the above aspects, which are provided herein as exemplary embodiments to better explain, describe, and understand the claimed aspects and embodiments.

[0363] 1. A computer-implemented method for providing payment services for transactions associated with a blockchain to one or more clients, the method being implemented by a payment processor and comprising the following steps:

[0364] Receiving, from a given client among the one or more clients, a request that is a request to submit a transaction associated with a digital asset to the blockchain, the request being associated with a callback identifier for enabling direct communication between the given client and another entity of the transaction;

[0365] Submitting the transaction associated with the request to a given network node among the plurality of network nodes to include the transaction in the blockchain;

[0366] Identifying the given network node to the client;

[0367] Providing the callback identifier to the network node;

[0368] In response to receiving, from the given network node, a response related to the request and corresponding to a blockchain transaction, the method further comprises:

[0369] Enable or process, for the client, at least one callback notification related to a corresponding blockchain transaction provided by the network node, the callback notification being based on a callback identifier associated with the request.

[0370] 3. The method according to clause 1, wherein the response received from the network node is associated with a transaction identifier (TxID), and the method further includes: sending the transaction identifier (TxID) of the corresponding blockchain transaction to the client.

[0371] 6. The method according to any of the preceding clauses, wherein the received response is an output script associated with the blockchain transaction, the output script including an unspent transaction output (UTXO) associated with the memory pool of the network node, the UTXO including the transaction identifier (TxID) of the blockchain transaction.

[0372] 9. The method according to any of the preceding clauses, wherein the payment processor is implemented as a Representational State Transfer (REST) endpoint of the one or more clients, and wherein the method further includes the step of providing an Application Programming Interface (API) gateway associated with the payment processor to perform the following steps:

[0373] Receive a request from the client in a Hypertext Transfer Protocol Secure (HTTPS) transport protocol format;

[0374] Convert the corresponding request into a Remote Procedure Call (RPC) format and submit the RPC to the network node;

[0375] Receive a response in RPC format from the network node, associated with a corresponding blockchain transaction; and

[0376] Convert the corresponding response for sending to the client using the HTTPS transport protocol.

[0377] 24. The method according to any of the preceding clauses, including the step of verifying the identity of the given network node, wherein the verification is based on a digital signature associated with the given network node, or on an identifier related to the given network node, the identifier optionally being associated with a reputation metric of the given network node.

[0378] 27. The method according to any of the preceding clauses, wherein the callback notification is related to a notification of double spending of a transaction submitted by the given client, or wherein the callback notification is related to a proof that a transaction submitted by the given client is included in the blockchain.

[0379] 7. The method according to any of the preceding clauses, wherein the callback identifier is the location of a channel associated with the client, or wherein the callback identifier is a Universal Resource Identifier (URI) for the client.

[0380] 8. The method according to any of the preceding clauses, further comprising: providing access to the channel for the given network node, wherein the providing step comprises: providing the network node with a channel identifier or location of the channel associated with the request, and one or more access tokens associated with the channel.

[0381] 9. A computer-implemented method for implementing a channel service for one or more clients, the method being implemented by a channel processor and comprising the following steps:

[0382] Receiving a request from a given client among the one or more clients, the request being related to creating a channel;

[0383] Providing the given client with access to one or more functions that enable direct communication between the given client and another entity via the channel, wherein the one or more functions comprise:

[0384] Channel functions or programs related to the channel for data transmission; and / or

[0385] Message functions or programs related to the data transmitted using the channel;

[0386] Issuing one or more access tokens for the channel, the one or more access tokens being configured for secure communication with another entity via the channel; and

[0387] Storing and / or providing one or more notifications associated with the channel for the given client. 10. The method according to clause 9, wherein the one or more functions are application programming interfaces (APIs) published for or provided to the given client, the API comprising a channel API for the channel and a message API for data associated with the channel; and wherein the access token is an API token specific to the channel or a given message.

[0388] 11. The method according to clause 9 or 10, wherein the step of providing access to one or more functions comprises: providing a JavaScript Object Notation (JSON) API based on the Hypertext Transfer Protocol (HTTP) to enable creation and / or management of one or more channels.

[0389] 12. The method according to any one of clauses 9 to 11, wherein the one or more notifications associated with the channel are callback notifications from a network node, which is the other entity that communicates directly with the given client via the channel.

[0390] 13. The method according to clause 12, wherein the callback notification is related to a notification of double spending of a transaction submitted by the given client.

[0391] 14. The method according to clause 13, wherein the callback notification is associated with a return payload in the channel, the return payload provided by the network node, and the return payload includes the following data:

[0392] - The transaction identifier (TxID) of the blockchain transaction that is a double spend; and optionally

[0393] - The service endpoint of the payment processor that submitted the blockchain transaction.

[0394] 15. The method according to clause 12, wherein the callback notification is related to a proof that a transaction submitted by the given client is included in the blockchain.

[0395] 16. The method according to clause 15, wherein the callback notification is associated with a return Merkle proof in the channel, the return Merkle proof provided by the network node, and the return Merkle proof includes the following data:

[0396] - The transaction identifier (TxID) of the blockchain transaction related to the Merkle proof;

[0397] - The block header of the block that includes the blockchain transaction; and

[0398] - An array of sibling hashes of the transaction identifier (TxID).

[0399] 17. The method according to any one of clauses 9 to 16, when the client is offline or not communicatively connected to the channel processor, the one or more callback notifications are push notifications of data that is stored or queued in the channel for the given client.

[0400] 18. The method according to any one of clauses 9 to 17, when the client is online or communicatively connected to the channel processor, the data associated with the one or more callback notifications is provided or extracted from the channel.

[0401] 19. The method according to any one of clauses 9 to 18, wherein the channel processor is a payment processor or includes a payment processor, and wherein the method includes: the method implemented by the payment processor according to any one of clauses 1 to 8.

[0402] 20. A computer-implemented method for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a client and including the following steps:

[0403] Sending a channel request related to a channel service implemented by a channel processor, the request being related to creating a channel for communicating with another entity;

[0404] Obtaining access to one or more functions from the channel service, the one or more functions enabling direct communication between the given client and the other entity, the one or more functions including:

[0405] Channel functions or programs related to a channel for data transmission; and / or

[0406] Message functions or programs related to data transmitted using the channel;

[0407] Obtaining one or more access tokens from the channel service, the access tokens enabling secure communication with the other entity;

[0408] Sending a request to a payment processor implementing a payment service, the request being a request to submit a transaction related to a digital asset to the blockchain;

[0409] Obtaining a transaction identifier (TxID) of a blockchain transaction corresponding to the submitted transaction from the payment processor;

[0410] Based on a response from the payment processor, identifying a network node associated with the corresponding blockchain transaction;

[0411] Using one or more channel functions received from the channel processor to create a given channel for communicating with the identified network node;

[0412] Sending the one or more access tokens associated with the given channel to the network node; receiving at least one callback notification associated with the given channel, the notification being related to data associated with the blockchain transaction in the given channel and provided by the network node. 21. The method according to clause 20, wherein when the client is offline or not communicatively connected to the channel processor, the callback notification is obtained as a push notification of data or a message queued in the given channel.

[0413] 22. The method according to clause 20 or 21, wherein when the client is online or communicatively connected to the channel processor, data associated with the callback notification is extracted from the given channel.

[0414] 23. The method according to any one of clauses 20 to 22, wherein the one or more functions are application programming interfaces (APIs) for the given client, the API including: a channel API for implementing the creation and / or management of one or more channels; and a message API for enabling the given client and one or more other entities to exchange messages, and / or read data from and / or write data to the given channel; and wherein the access token is an API token specific to the given channel or the given message.

[0415] 24. The method according to any one of clauses 20 to 23, wherein the channel request is a Hypertext Transfer Protocol Secure (HTTPS) transport GET request to the channel processor, and wherein the request to the payment processor is a Hypertext Transfer Protocol Secure (HTTPS) transport POST request to the payment processor.

[0416] 25. The method according to any one of clauses 20 to 24, further comprising the steps of:

[0417] Providing a client endpoint;

[0418] Providing at least one client addressing key associated with the client;

[0419] Obtaining a network node endpoint;

[0420] Obtaining at least one network node addressing key associated with the network node;

[0421] Exchanging one or more handshake messages using the given channel based on the client addressing key and the network node addressing key;

[0422] Obtaining a shared key based on the handshake result or handshake pattern;

[0423] Wherein any communication using the given channel is encrypted based on the shared key. 26. The method according to clause 25, wherein the client endpoint is a Hypertext Transfer Protocol (HTTP) application programming interface (API) endpoint, and wherein the client endpoint is implemented using HTTP Secure (HTTPS).

[0424] 27. The method according to clause 25, wherein the client endpoint is a Uniform Resource Locator (URL), and the Uniform Resource Locator (URL) is included in a message sent from the given client using the given channel.

[0425] 28. The method according to any one of clauses 25 to 27, wherein the client endpoint is an alias associated with the client, the alias being specific to the client and provided by an alias-based addressing service having a machine-readable resource accessible from a defined or known location, the machine-readable resource including one or more functions related to the client, and wherein the alias is associated with an asymmetric encryption key pair for authentication.

[0426] 29. A computer-implemented method for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a network node among a plurality of network nodes, the plurality of network nodes being communicatively coupled to at least one payment processor, the at least one payment processor implementing a payment service for a given client, the method comprising the steps of:

[0427] Receiving a request from the payment processor to submit a transaction to the blockchain;

[0428] Generating a blockchain transaction corresponding to the request;

[0429] Sending an output script (UTXO) associated with the blockchain transaction to the payment processor, wherein the output script includes a transaction identifier (TxID) associated with the corresponding blockchain transaction;

[0430] Receiving access to a channel capable of enabling direct communication with the given client;

[0431] Based on an access token associated with the channel, obtaining a message function or message API for providing or writing data associated with a callback notification in the channel, the data being related to the corresponding blockchain transaction.

[0432] 30. The method according to clause 29, wherein based on determining that the corresponding blockchain transaction is a double spend of a previous transaction submitted by the client; the method further comprises: the step of providing a return payload, the return payload including the following data:

[0433] - The transaction identifier (TxID) of the given blockchain transaction as the double spend; and optionally

[0434] - The service endpoint of the payment processor that submitted the given blockchain transaction.

[0435] 31. The method according to clause 29, wherein in response to mining the corresponding blockchain transaction in a block, the method further comprises: providing a step of returning a Merkle proof, the returned Merkle proof confirming that the transaction is included in the block, and the returned Merkle proof includes the following data:

[0436] - A transaction identifier (TxID) of the blockchain transaction associated with the Merkle proof;

[0437] - The block header of the block; and

[0438] - An array of sibling hashes of the transaction identifier.

[0439] 32. The method according to any one of clauses 29 to 31 further comprises the following steps:

[0440] Obtaining a client endpoint;

[0441] Obtaining at least one client addressing key associated with the client;

[0442] Providing a network node endpoint;

[0443] Providing at least one network node addressing key associated with a payment processor;

[0444] Exchanging one or more handshake messages using the channel based on the client addressing key and the network node addressing key;

[0445] Obtaining a shared key based on the handshake result or handshake pattern;

[0446] Wherein any communication using the channel is encrypted based on the shared key.

[0447] 33. A computing device comprising a processor and a memory, the memory including executable instructions which, when executed by the processor, cause the device to perform the computer-implemented method according to any one of clauses 1 to 8, and the computing device is related to a payment processor.

[0448] 34. A computing device comprising a processor and a memory, the memory including executable instructions which, when executed by the processor, cause the device to perform the computer-implemented method according to any one of clauses 9 to 19, and the computing device is related to a channel processor.

[0449] 35. A computing device includes a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform a computer-implemented method according to any one of clauses 20 to 28, the computing device being related to a client.

[0450] 36. A computing device includes a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform a computer-implemented method according to any one of clauses 29 to 32, the computing device being related to a network node.

[0451] 37. A computer system includes:

[0452] A payment processor communicatively coupled to at least one client and at least one network node via a wireless communication network, wherein the payment processor is implemented as the computing device according to clause 33;

[0453] A client communicatively coupled to the payment processor via a wireless communication network and capable of communicating with at least one customer; the client is implemented as the computing device according to clause 35;

[0454] The client is communicatively coupled to a channel processor via a wireless communication network, wherein the channel processor is implemented as the computing device according to clause 34; and

[0455] A plurality of network nodes communicatively coupled to the payment processor via a wireless communication network, each network node being implemented as the computing device according to clause 38.

[0456] 38. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer, cause the computer to perform the method according to any one of clauses 1 to 32.

[0457] It should be noted that the above aspects and embodiments illustrate rather than limit the present disclosure, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The words "comprising", "including" and the like do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprising" means "comprising or consisting of", and "including" means "including or consisting of". The singular representation of an element does not exclude the plural representation of such element, and vice versa. The present disclosure can be implemented by hardware including a plurality of different elements and by a suitably programmed computer. In a device claim enumerating a plurality of modules, a plurality of these modules can be implemented by the same item of hardware. That certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously. < / sequence> < / sequence> < / id> < / id> < / id> < / id>

Claims

1. A computer-implemented method for providing payment services for one or more clients for a transaction associated with a blockchain, the method being implemented by a payment processor and comprising the following steps: Receiving a request from a given client among the one or more clients, the request being a request to submit a transaction associated with a digital asset to the blockchain, the request being associated with a callback identifier for enabling direct communication between the given client and another entity of the transaction; Submitting the transaction associated with the request to a given network node among a plurality of network nodes to include the transaction in the blockchain; Identifying the given network node for the client; Providing the callback identifier to the network node; In response to receiving a response from the given network node regarding the corresponding blockchain transaction of the request, the method further comprises: Enabling or processing, for the client, at least one callback notification related to the corresponding blockchain transaction provided by the network node, the callback notification being based on the callback identifier associated with the request.

2. The method according to claim 1, wherein The response received from the network node is associated with a transaction identifier (TxID), and the method further comprises: sending the transaction identifier (TxID) of the corresponding blockchain transaction to the client.

3. The method according to any one of the preceding claims, wherein, The received response is an output script associated with the blockchain transaction, the output script including an unspent transaction output UTXO associated with the memory pool of the network node, the UTXO including the transaction identifier (TxID) of the blockchain transaction.

4. The method according to any one of the preceding claims, wherein, The payment processor is implemented as a Representational State Transfer REST endpoint for the one or more clients, and wherein the method further comprises: the step of providing an Application Programming Interface API gateway associated with the payment processor to perform the following steps: Receiving the request from the client in a Hypertext Transfer Protocol Secure HTTPS transfer protocol format; Converting the corresponding request into a Remote Procedure Call RPC format and submitting the RPC to the network node; Receiving, in RPC format, a response from the network node associated with the corresponding blockchain transaction; and Converting the corresponding response for sending to the client using the HTTPS transfer protocol.

5. The method according to any one of the preceding claims, comprising: The step of authenticating the identity of the given network node, wherein the authentication is based on a digital signature associated with the given network node or based on an identifier related to the given network node.

6. The method according to claim 5, wherein The identifier is associated with a reputation metric of the given network node.

7. The method according to any one of the preceding claims, wherein, The callback notification is related to a notification of double-spending of a transaction submitted by the given client, or wherein the callback notification is related to a proof that a transaction submitted by the given client is included in the blockchain.

8. The method according to any one of the preceding claims, wherein, The callback identifier is the location of a channel associated with the client, or wherein the callback identifier is a Universal Resource Identifier URI for the client.

9. The method according to claim 8 further comprises: Steps for providing access to the channel for the given network node, wherein the providing step includes: providing the network node with a channel identifier or location of the channel associated with the request, and one or more access tokens associated with the channel.

10. A computer-implemented method for implementing a channel service for one or more clients, the method being implemented by a channel processor and including the following steps: Receiving a request from a given client among the one or more clients, the request being related to the creation of a channel; Providing the given client with access to one or more functions that enable direct communication between the given client and another entity via the channel, wherein the one or more functions include: Channel functions or programs related to the channel for data transmission; and / or Message functions or programs related to the data transmitted using the channel; Issuing one or more access tokens for the channel, the one or more access tokens being configured for secure communication with another entity via the channel; and Storing and / or providing one or more notifications associated with the channel for the given client.

11. The method according to claim 10, wherein, The one or more functions are application programming interfaces (APIs) issued for or provided to the given client, the API including a channel API for the channel and a message API for the data associated with the channel; and wherein the access token is an API token specific to the channel or a given message.

12. The method according to claim 10 or 11, wherein, The step of providing access to one or more functions includes: providing a JavaScript Object Notation (JSON) API based on the Hypertext Transfer Protocol (HTTP) to implement the creation and / or management of one or more channels.

13. The method according to any one of claims 10 to 12, wherein The one or more notifications associated with the channel are callback notifications from a network node, which is the other entity that communicates directly with the given client via the channel.

14. The method according to claim 13, wherein, The callback notification is related to the notification of double spending of a transaction submitted by the given client.

15. The method according to claim 14, wherein, The callback notification is associated with a return payload in the channel, the return payload being provided by the network node, and the return payload includes the following data: - A transaction identifier (TxID) of a blockchain transaction as a double spend.

16. The method according to claim 15, wherein, The return payload further includes: - A service endpoint of a payment processor that submitted the blockchain transaction.

17. The method according to claim 13, wherein, The callback notification is related to the proof that a transaction submitted by the given client is included in the blockchain.

18. The method according to claim 17, wherein, The callback notification is associated with a return Merkle proof in the channel, the return Merkle proof being provided by the network node, and the return Merkle proof includes the following data: - A transaction identifier (TxID) of a blockchain transaction related to the Merkle proof; - A block header of the block that includes the blockchain transaction; And - An array of sibling hashes of the transaction identifier (TxID).

19. The method according to any one of claims 10 to 18, wherein when the client is offline or not communicatively connected to the channel processor, the one or more callback notifications are push notifications for data stored or queued in the channel for the given client.

20. The method according to any one of claims 10 to 19, wherein when the client is online or communicatively connected to the channel processor, data associated with the one or more callback notifications is provided or extracted from the channel.

21. The method according to any one of claims 10 to 20, wherein, The channel processor is a payment processor or includes a payment processor, and wherein the method includes the method implemented by the payment processor according to any one of claims 1 to 9.

22. A computer-implemented method for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a client and including the following steps: Sending a channel request related to a channel service implemented by a channel processor, the request being related to creating a channel for communicating with another entity; Obtaining access to one or more functions from the channel service, the one or more functions enabling direct communication between a given client and the other entity, the one or more functions including: Channel functions or programs related to a channel for data transmission; and / or Message functions or programs related to data transmitted using the channel; Obtaining one or more access tokens from the channel service, the access tokens enabling secure communication with the other entity; Sending a request to a payment processor implementing a payment service, the request being a request to submit a transaction associated with a digital asset to the blockchain; Obtaining a transaction identifier (TxID) of a blockchain transaction corresponding to the submitted transaction from the payment processor; Identifying a network node associated with the corresponding blockchain transaction based on a response from the payment processor; Using one or more channel functions received from the channel processor to create a given channel for communicating with the identified network node; Sending the one or more access tokens associated with the given channel to the network node; Receiving at least one callback notification associated with the given channel, the notification being related to data associated with the blockchain transaction in the given channel and provided by the network node.

23. The method according to claim 22, wherein, When the client is offline or not communicatively connected to the channel processor, obtaining the callback notification as a push notification for data or messages queued in the given channel.

24. The method according to claim 22 or 23, wherein When the client is online or communicatively connected to the channel processor, extracting data associated with the callback notification from the given channel.

25. The method according to any one of claims 22 to 24, wherein, The one or more functions are application programming interfaces (APIs) for the given client, and the API includes: a channel API for implementing the creation and / or management of one or more channels; and a message API for enabling the given client and one or more other entities to exchange messages, and / or read data from and / or write data to the given channel; and wherein, the access token is an API token specific to a given channel or a given message.

26. The method according to any one of claims 22 to 25, wherein, The channel request is a Hypertext Transfer Protocol Secure (HTTPS) transport GET request to the channel processor, and wherein the request to the payment processor is a Hypertext Transfer Protocol Secure (HTTPS) transport POST request to the payment processor.

27. The method according to any one of claims 22 to 26, further comprising the steps of: Providing a client endpoint; Providing at least one client addressing key associated with the client; Obtaining a network node endpoint; Obtaining at least one network node addressing key associated with the network node; Exchanging one or more handshake messages using the given channel based on the client addressing key and the network node addressing key; Obtaining a shared key based on the handshake result or handshake pattern; Wherein any communication using the given channel is encrypted based on the shared key.

28. The method according to claim 27, wherein, The client endpoint is a Hypertext Transfer Protocol (HTTP) application programming interface (API) endpoint, and wherein the client endpoint is implemented using Hypertext Transfer Protocol Secure (HTTPS).

29. The method according to claim 27, wherein, The client endpoint is a Uniform Resource Locator (URL) included in a message sent from the given client using the given channel.

30. The method according to any one of claims 27 to 29, wherein, The client endpoint is an alias associated with the client, the alias being specific to the client and provided by an alias-based addressing service having a machine-readable resource accessible from a defined or known location, the machine-readable resource including one or more functions related to the client, and wherein the alias is associated with an asymmetric encryption key pair for authentication.

31. A computer-implemented method for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a network node among a plurality of network nodes, the plurality of network nodes being communicatively coupled to at least one payment processor, the at least one payment processor implementing a payment service for a given client, the method comprising the steps of: Receiving from the payment processor a request to submit a transaction to the blockchain; Generating a blockchain transaction corresponding to the request; Sending to the payment processor an output script (UTXO) associated with the blockchain transaction, wherein the output script includes a transaction identifier (TxID) associated with the corresponding blockchain transaction; Receiving access to a channel that enables direct communication with the given client; Obtain a messaging function or messaging API based on an access token associated with the channel for providing or writing data associated with a callback notification in the channel, the data being related to the corresponding blockchain transaction.

32. The method according to claim 31, wherein, Based on determining that the corresponding blockchain transaction is a double spend of a previous transaction submitted by the client, the method further includes: providing a step of returning a payload, the returned payload including the following data: - The transaction identifier (TxID) of a given blockchain transaction as a double spend.

33. The method according to claim 32, wherein The returned payload further includes: - The service endpoint of the payment processor that submitted the given blockchain transaction.

34. The method according to claim 31, wherein, In response to mining the corresponding blockchain transaction in a block, the method further includes: providing a step of returning a Merkle proof, the returned Merkle proof confirming that the transaction is included in the block, the returned Merkle proof including the following data: - The transaction identifier (TxID) of the blockchain transaction related to the Merkle proof; - The block header of the block; and - An array of sibling hashes of the transaction identifier.

35. The method according to any one of claims 31 to 34, further comprising the following steps: Obtain a client endpoint; Obtain at least one client addressing key associated with the client; Provide a network node endpoint; Provide at least one network node addressing key associated with the payment processor; Based on the client addressing key and the network node addressing key, exchange one or more handshake messages using the channel; Obtain a shared key based on the handshake result or handshake pattern; Wherein any communication using the channel is encrypted based on the shared key.

36. A computing device, comprising a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform the computer-implemented method according to any one of claims 1 to 9, the computing device being related to a payment processor.

37. A computing device, comprising a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform the computer-implemented method according to any one of claims 10 to 21, the computing device being related to a channel processor.

38. A computing device, comprising a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform the computer-implemented method according to any one of claims 22 to 30, the computing device being related to a client.

39. A computing device, comprising a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the device to perform the computer-implemented method according to any one of claims 31 to 35, the computing device being related to a network node.

40. A computer system, comprising: A payment processor communicatively coupled to at least one client and at least one network node via a wireless communication network, wherein the payment processor is implemented as the computing device according to claim 36; A client communicatively coupled to the payment processor via the wireless communication network and capable of communicating with at least one customer; the client is implemented as the computing device according to claim 38; the client is communicatively coupled to a channel processor via the wireless communication network, wherein the channel processor is implemented as the computing device according to claim 37; and A plurality of network nodes communicatively coupled to the payment processor via the wireless communication network, each network node being implemented as the computing device according to claim 39.

41. A computer-readable storage medium having executable instructions stored thereon, which when executed by a processor of a computer cause the computer to perform the method according to any one of claims 1 to 35.

Images