Blockchain transaction callback mechanism

Abstract

To provide a method, apparatus, and system for processing a blockchain transaction associated with a client.SOLUTION: A settlement service is implemented as a gateway or API endpoint to which one or more clients have access. A request to submit a transaction received from a given client is associated with a callback identifier. The callback identifier allows direct communication between a given client and another entity, such as a minor or other trading partner. A settlement processor submits transactions to the minor, and this submission is associated with a callback identifier. Then, when a corresponding blockchain transaction is created by the miner, a callback notification therefor can be provided by the miner directly to the client using the callback identifier.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] This disclosure relates generally to methods and systems for implementing a payment service or interface for one or more clients. In particular, but not by way of limitation, this disclosure relates to enabling secure and reliable payment transactions involving blockchain or distributed ledger related digital asset settlements associated with a customer or payment entity to or for one or more clients. [Background technology]

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

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

[0004] For a transaction to be written to the blockchain, it must be “verified”. Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. A software client installed on the node performs the validation work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and is then written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction (if the transaction is verified, the node relays it to other nodes in the network), ii) be added to a new block constructed by a miner, and iii) be mined, i.e., added to the public ledger of past transactions.

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

[0006] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are exploring the use of both the cryptographic security system on which Bitcoin is based, and the data that can be stored on the blockchain, to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency realm. Such solutions could be more versatile in their use while still leveraging the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.). One area of ​​current research is the use of blockchain for the implementation of “smart contracts”. These are computer programs designed to automate the fulfillment of the terms of a machine-readable contract or agreement. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs with rules that can process inputs to generate results, and can cause actions to be taken depending on those results. Another area of ​​interest related to blockchain is the use of “tokens” (or “colored coins”) to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value, and thus act as identifiers that allow the real-world items to be referenced from the blockchain.

[0007] The above examples or scenarios concern the transfer of any asset, i.e., digital assets, or control of digital assets, between users or entities. Thus, it is desired to implement a secure and robust system similar to existing payment or e-commerce systems for the exchange of funds between two entities, particularly for digital asset payments between merchants and customers that may respect assets in the real world, with a better user experience, at a lower merchant or payer cost, and at a safer security level. More specifically, it is desired to provide a common platform or interface that allows any merchant or multiple merchants to ensure that digital asset payments with their respective customers can be instantly and securely mined and written to the blockchain, thereby providing a persistent, tamper-proof, and auditable record of such payments, taking advantage of distributed ledger (blockchain) technology and the enhanced security, transparency, and reliability of records.

[0008] Such an improved solution is currently being devised. The present disclosure addresses these technical concerns by proposing a technique whereby transactions involving one or more clients, i.e., merchant or payee entities, that are recipients of digital assets, e.g., cryptocurrencies, can be instantly written to the blockchain by methods, techniques, and apparatus that provide an application programming interface (API) to such clients. Such a technique allows miners to dynamically or instantly mine or write transactions to the blockchain, i.e., provides a service that allows instant or zero confirmation transactions (0-conf) to clients in a secure and reliable manner. Summary of the Invention

[0009] In one aspect, the present disclosure proposes a method, apparatus, and system relating to a payment service for processing blockchain transactions related to a client. The payment service is implemented as a gateway or API endpoint to which one or more clients have access. In the 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 with the callback identifier to a miner. Then, when a corresponding blockchain transaction is created by the miner, a callback notification about it can be provided directly from the miner to the client.

[0010] In another aspect, a request from a client is associated with a channel provided by the channel service that is associated with one or more features that enable direct communication between the client and another entity. In this case, the client is also provided with one or more access tokens and application programming interfaces (APIs) for the channel. Based on these access tokens and / or APIs, another entity, such as a miner identified by the client as an entity that mines transactions for the client, can be provided with access to the channel. This allows data related to the corresponding blockchain transaction to be written directly to the channel by the other entity. A callback notification specific to the corresponding transaction can then be provided via the channel service. This allows data related to a given transaction to be accessed directly from the channel by the client whenever necessary or possible, such as when the client is online and communicating with the channel service over a 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 a separate entity from the payment processor.

[0011] Throughout this specification, the term "comprises" or variations such as "including," "has," "having," etc., are understood to mean the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of other elements, integers or steps, or other groups of elements, integers or steps. [Brief description of the drawings]

[0012] Aspects and embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1]1 is a flowchart illustrating a method of implementing a payment service or payment interface for enabling blockchain related digital asset transactions for one or more clients, the method being implemented by a payment processor according to a first aspect. [Diagram 2] 11 is a flowchart illustrating a method of requesting processing of a blockchain transaction, the blockchain transaction relating to a digital asset settlement associated with a client, the method being implemented by one or more processors associated with the client according to a second aspect. [Diagram 3] 11 is a flowchart illustrating a method for processing a blockchain transaction related to a digital asset payment for a client, the method being implemented by one or more processors associated with a miner according to a third aspect. [Figure 4] FIG. 1 is a schematic diagram illustrating a system for providing a payment service or payment interface for enabling blockchain transactions for a client. [Diagram 5] FIG. 11 is a schematic diagram showing the data flow associated with a first request to obtain fee quotes associated with multiple miners. [Figure 6] FIG. 11 is a schematic diagram showing the data flow associated with a second request to submit a transaction based on a selected fee quote. [Figure 7] FIG. 1 is a schematic diagram showing data flow associated with a status query based on a blockchain transaction identifier. [Figure 8] 11 is a flowchart illustrating a method of implementing a callback mechanism for a transaction, the method being implemented by one or more processors associated with a payment processor according to a fourth aspect. [Figure 9] 11 is a flowchart illustrating a method of implementing a channel service for one or more clients, the method being implemented by one or more processors associated with a channel processor according to a fourth aspect. [Figure 10] 11 is a flowchart illustrating a method of accessing a payment service, the method being implemented by one or more processors associated with a client according to a fourth aspect. [Figure 11] 11 is a flowchart illustrating a method for processing a message associated with a given blockchain transaction, the method being implemented by one or more processors associated with a miner according to a fourth aspect. [Figure 12] FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure can be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Although the appended claims relate to a fourth aspect of the present disclosure, which is described in detail below, a detailed description of the details of the first, second, and third aspects is provided herein in order to provide the reader with a full and complete understanding of the claimed aspects and related embodiments of the present disclosure.

[0014] According to a first aspect, the present disclosure provides a computer-implemented method of performing a payment service for one or more clients for transactions associated with a blockchain, the method being implemented by a payment processor associated with the payment service. In some embodiments, the client may be a computational resource or node, or an entity that may be associated with a digital wallet for accepting and / or processing cryptocurrency payments and associated with a public key or public address for such wallet. In some embodiments, the client may represent a merchant entity or terminal, such as, for example, a point-of-sale device, that offers goods or services in the real world and receives digital asset payment payments for such goods or services, but is not limited to such. In some embodiments, the payment processor is configured to provide a payment interface as an associated or third-party service to one or more clients. In some examples, the payment processor is referred to as a payment aggregator because it provides multiple payment services and functions related to the blockchain to clients and miners through one or more user-friendly interfaces. In some embodiments, the payment processor is implemented as an application programming interface (API) that provides web-based interaction for one or more clients, i.e., implemented as a web service, such that communication can occur over the internet using standard internet communication protocols for web-based services, e.g., HTTPS, TCP / IP, etc. This API is either known or available or transmitted / provided to one or more clients associated with the payment processor. In some embodiments, this API may be provided to clients following a registration or sign-up process to access services or functionality provided by the payment processor.In some examples, the API may be provided or published for use by clients via an API user interface, such as Swagger, a well-known API design and development tool or interface for clients or other entities wishing to access web-based services.

[0015] The method of the first aspect includes obtaining a fee quote from each miner among the miners for mining the transaction in response to a first request from a client for a mining fee quote associated with mining the transaction. In some embodiments, the miner is a node, implemented by one or more processors entrusted with validating locking and unlocking scripts and mining or writing transactions to the blockchain, as described above in the background section. For example, if Bitcoin Satoshi's Vision (BSV) is the cryptocurrency or digital asset being bought, sold, or transferred, the miner may be referred to as a BSV node. The method of the first aspect includes providing the obtained fee quote to the client. In some embodiments, the fee quote relates to a current fee collected or charged by the miner for mining a transaction into the blockchain, regardless of what the transaction relates to or the parties involved. In other embodiments, the fee quote may be adjusted to be based on a given transaction, which may be identified in the request. In some embodiments, the payment processor may provide all received fee quotes to the client, or may provide one or more recommended fee quotes to be provided to the client among the obtained fee quotes.

[0016] Advantageously, by implementing the payment services provided as an API directed to one or more clients, i.e., merchant or payee entities, that are recipients of digital assets, such as cryptocurrencies, e.g., Bitcoin SV (BSV), the method of the first aspect allows a payment transaction to be mined (written to the blockchain) almost immediately, or as soon as possible after a miner solves a proof-of-work puzzle, by allowing the client to sign or use a web service provided by the payment processor. By providing a current fee quote, a given miner theoretically agrees or promises to add the transaction to the next block mined by that given miner for that fee. Advantageously, this means that the client, i.e., the merchant entity, no longer needs to wait for confirmation from the miner. Thus, advantageously, 0-conf transactions can be performed that relate to the client and the respective miner. The identity of a client using the payment services API can advantageously remain anonymous, while all transactions related to that client can still be reliably mined by a miner among multiple miners that meets the chosen or selected fee quote for mining. Thus, individual clients or merchants can avail the benefits of transparency, reliability and provision of an immutable and verifiable record of all payments related to their respective clients by utilizing the proposed payment services API without having to implement additional processing or network resources.

[0017] In some embodiments of the first aspect, in response to a second request from the client to submit a given transaction that is related to or includes a selected fee estimate among the obtained fee estimates, the method includes sending a request to one or more miners among the plurality of miners to generate a blockchain transaction for the given transaction.

[0018] In some embodiments, a selected fee quote is received from a client and selected for a given transaction, which may be associated with a payment request or settlement transaction between the client and another node or entity, such as a customer of the client, in view of a product or service purchased from the client that requires a digital asset settlement. The method then includes receiving an output script, such as a UTXO, associated with the blockchain transaction from at least one miner among the plurality of miners that satisfies the selected fee quote. For example, in some embodiments, to satisfy the fee quote, the at least one miner should be providing or associated with a current fee quote that is higher or lower in value than the selected fee quote, and in some cases higher in value than the selected fee quote according to one or more rules or predefined criteria associated with the client. The method then includes transmitting a result to the client, the result including a transaction identifier (TxID) of the blockchain transaction associated with the given transaction, i.e., the settlement between the client and the customer.

[0019] Advantageously, the API of the present disclosure can be implemented as a Representational State Transfer (REST) ​​endpoint, thereby allowing clients to communicate using standard internet or web-based protocols such as HTTPS. Moreover, advantageously, the payment service of the first aspect allows corresponding transactions related to digital asset payments to be instantly created and written to the blockchain based on a selected fee quote. Mining a transaction based on a selected fee quote, selected or chosen by the payment processor by or for the client, advantageously allows at least one miner of a plurality of miners to mine or write the transaction to the blockchain almost immediately or as soon as possible, already provided with a guarantee that a given miner will mine the transaction at a current fee quote that matches or meets the selected fee quote from the client. Thus, the payment service API has the advantage of allowing instant or zero confirmation transactions (0-conf) to be mined in the blockchain for the client in a secure and reliable manner, without the client having to wait for confirmation from the miner that the transaction has actually been added to a block in the blockchain and will be mined. This is because a given miner has already indicated that it is available to mine by sending a current fee quote for mining the transaction in response to the first request. The method of the first aspect reduces double-spend risks associated with allowing instant transactions to be mined because mining according to the first aspect will be based on a selected fee quote chosen by or for the client.Thus, only miners who meet the selected fee estimate can mine a transaction, and once a transaction is added to a block associated with the blockchain by the first miner who meets the fee estimate, that transaction cannot be mined by other miners.

[0020] Some embodiments of the method according to the first aspect of providing a payment service implemented by a payment processor include providing a transaction mining fee estimate based on determining a recommended fee to propose to the client, where the determined fee may be an average of the obtained fee estimates from multiple miners or a maximum of the obtained fee estimates. Advantageously, in an attempt to avoid double spending, the payment processor may recommend that the transaction be submitted at the highest fee value obtained from multiple miners in response to the first request. In this way, all miners may be given an equal opportunity to mine the transaction at their respective currently quoted fee. On the other hand, if the recommendation is to submit the recommended transaction at or above the median or average fee of all received fee estimates, the miner with the higher estimate may simply keep the transaction in a memory pool, e.g., an auxiliary memory pool, and use it to check for and reject any double spending of the transaction. Similar advantages apply when the selected fee estimate is based on the recommended fee estimate or when the recommendation is part of a selection made by the client.

[0021] Advantageously, the payment processor recommends a fee quote from which the client may then choose to become the selected fee quote, which in some embodiments is the maximum the client is willing to pay to submit a transaction related to a digital asset payment to the client. This is advantageous when the client is computationally sophisticated or when the client has pre-determined that a recommendation will be provided by the payment processor rather than selecting a fee quote itself. Thus, advantageously, the client can select a fee quote based on the recommended fee quote, rather than applying new or separate rules of thumb or calculations to select a fee quote or arbitrarily select a fee quote.

[0022] In some embodiments, when a recommendation or suggested fee quote is provided from a payment service, i.e., an API provided by the payment processor, the suggested fee quote may be provided, or alternatively, the suggested fee quote may be provided including an identifier for all fee quotes obtained, including the suggested fee quote. Advantageously, by providing the recommendation and all fee quotes received, the payment processor provides the client with the option to either use the suggested fee quote to submit the transaction or to select a different fee quote from other fee quotes received. In some embodiments, the method includes verifying the identity of a given miner among the miners providing the respective fee quotes, the identity being verified based on a digital signature associated with the given miner. A cryptographic key pair including a private key and a public key (or public address) associated with each miner can be used to verify that the fee quotes are indeed originated from the given miner, i.e., data signed by a private key can only be restored or verified 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.

[0023] In other embodiments, an identifier associated with a given miner may be used either in addition or instead to verify the identity of the miner. In some embodiments, the method includes a payment processor, such as a MinerID. In some embodiments, the identifier may be associated with a reputation indicator of the given miner. In some embodiments, the MinerID may be based on the mining pool of which the given miner is a part, or may be specific to the given miner. The reputation indicator relates to a measure of the performance of the miner. For example, in some instances, the reputation may be based on how the given miner has performed or mined transactions in the past at the quoted fees. For example, if a miner regularly mines transactions at the miner's quoted fees or within the tolerance of the fees, the reputation indicator may indicate a good reputation, such as by being high in value. In some embodiments, a miner's reputation score or indicator may be calculated, maintained, and managed by at least one payment processor communicatively coupled to the miner.

[0024] In some embodiments, the method of the first aspect implemented by the payment processor may include a step of verifying a fee quote obtained from a given miner among the miners based on a miner signature, which is different from a digital signature for verifying the identity of the given miner using PKI technology. The miner signature used by the payment processor for this verification step advantageously indicates or serves as a commitment of the miner to mine a transaction for each fee quote provided to the payment processor. The presence of the miner signature may also advantageously serve to ensure that the miner rejects the conflicting transaction(s). Thus, the step of verifying based on the miner signature advantageously acts as a guarantee that the given miner will include transactions in a block for mining and that they do not include any conflicting transactions. In some embodiments, monitoring the performance of a given miner based on such guarantee(s) provided by the given miner may determine or affect a miner score or reputation associated with the given miner.

[0025] In some embodiments, the fee quotes provided by each miner in the plurality of miners are provided to the payment processor as a data type that includes a value of the fee quote, in some embodiments, in a JavaScript Object Notation (JSON) object format.

[0026] In some embodiments, the output script received at the payment processor from the at least one miner is an Unspent Transaction Output (UTXO) associated with a memory pool for the at least one miner, the UTXO including a transaction identifier (TxID) of a blockchain transaction related to a digital asset payment between a client and a customer.

[0027] In some embodiments, to allow a client to advantageously identify or track a blockchain transaction related to a given payment transaction with a customer or any transaction associated with the client, the method includes sending a request to obtain a blockchain transaction corresponding to a transaction identifier to a plurality of miners, the request being sent by the payment processor to at least one miner in response to a status query associated with the transaction identifier from the client. In response, the payment processor obtains a corresponding previously generated blockchain transaction from at least one of the plurality of miners. Based on a mining status of the blockchain transaction by the at least one miner, the method includes sending a status result related to the obtained blockchain transaction associated with the transaction identifier to the client. The result may indicate whether the blockchain transaction has been mined, i.e., completed, or has been rejected for some reason, or is invalid, as it may have already been mined by another miner of the plurality of miners before the given miner. This advantageously avoids double spending in case of mining by different miners for a particular transaction. In some embodiments, a miner may keep transactions that have not been added to a block or mined in an auxiliary memory pool, which may be or act as a separate, alternative or additional memory pool to the main memory pool associated with the miner. The auxiliary memory pool may be a temporary memory pool such that TxIDs can be checked for double spends. This advantageously ensures that even if a transaction is not mined by a given miner, it is still kept in the auxiliary memory pool and used to check for and reject future double spends.There may be a time limit for keeping transactions in a given miner's auxiliary memory pool that are not mined by or not intended to be mined by the given miner. In some embodiments, transactions stored in the auxiliary memory pool may be associated with an expiration time after which they will be removed. In some embodiments, a separate fee may be associated with miners for storing transactions not mined by a given miner in their respective auxiliary memory pools.

[0028] In some embodiments, the method of the first aspect further comprises providing an application programming interface (API) converter associated with the payment processor for receiving from the client a first request for a fee quote, a second request to submit a transaction related to a digital asset settlement for the client, and / or a status query related to the transaction in Hypertext Transfer Protocol Secure (HTTPS) format, and then converting the same into a remote procedure call (RPC) format before sending the RPC to the miners. This is advantageous because it allows the client to communicate blockchain related requests over HTTPS, using web-based APIs and seamlessly providing interoperability with miners that do not communicate using Internet Protocol communication standards for web services. For example, all current BSV miners or implementations use remote procedure calls. The API converter implemented in this embodiment is not limited to converting from HTTPS to RPC and back, or from other web-based protocols to alternative communication protocols supported by individual miners or networks for a given cryptocurrency or digital asset that may be envisioned. In the reverse flow path, the method of the first aspect also includes receiving responses related to the corresponding blockchain transactions from one or more of the miners in RPC format and converting each response for the client using HTTPS accordingly. Thus, advantageously, implementing the proposed interface by the payment processor enables seamless communication for submitting transactions to the blockchain when the client (payee) and the miner use different wireless data communication protocols and mechanisms.

[0029] In some embodiments, an API gateway associated with the payment processor may be provided. The API converter described above may be associated with the API gateway in such embodiments. Additionally, the API gateway may also, in some embodiments, provide, but is not limited to, the following: - Caching transactions; - Performing recovery functions in case of minor node failure; - Maintaining a record of one or more endpoints or URLs that may be used to send messages or notifications to / from payment processors and / or clients and / or miner nodes; - Providing recovery mechanisms including tracking of transactions that fail to submit for any reason. In some examples, this may include configurable parameters maintained at or set by the payment processor, and mechanisms for removing expired tracked transactions. The API gateway may also be associated with functionality for resubmitting transactions in failure scenarios, thereby providing functionality for error handling of non-fake transactions, as well as differentiating against double spends; The present invention may be implemented in one or more computing devices to perform / carry out functions including one or more of the following:

[0030] According to a second 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 client being communicatively coupled to at least one payment processor implementing a payment service for the client. In some embodiments, the payment processor is configured to implement the method of the first aspect and related embodiments described above. The method of the second aspect, performed by a client, i.e., a merchant, includes sending a first request to a payment processor among the at least one payment processor, the request relating to one or more fee quotes for mining a transaction or transactions to be obtained from multiple miners via the payment processor. As described above, the fee quote obtained can relate to mining any transaction or can be specific to a given transaction relating to a digital asset payment from a customer.

[0031] 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 among the received one or more fee quotes. As noted in the first aspect, the selected fee quote may or may not be based on a recommendation made by the payment processor. The method of the second aspect then includes requesting and / or processing a digital asset payment from the customer, the request being related to the selected fee quote. In some embodiments, the request is similar to a payment request or invoice issued by a client to a customer for a digital asset payment. For example, the client may be a coffee shop terminal associated with a digital wallet, and the customer may be paying, for example, 2 satoshis for a coffee in response to the request, the customer also associated with a digital wallet. As the selected fee quote is now chosen, it may be added to a request for payment from the customer. The method then includes submitting a second request to the payment processor for a given transaction related to the customer payment, the submission being based on the selected fee quote for mining the given transaction. In some embodiments, the selected fee quote is explicitly indicated in or included in the second request, such that the payment processor can advantageously identify miners that can mine the transaction at or below the selected fee quote, or, additionally or alternatively, miners can identify whether they meet the selected fee quote.

[0032] As mentioned above, in some embodiments, the client may select a fee quote based on the highest fee quote value received from the payment processors, or alternatively, may be at or near the average or median of the received fee quote values. The advantages associated with either option are the same as those mentioned above, i.e., the maximum allows all miners to have a chance to mine, while the other values ​​limit mining to the portion of miners that meet the fee quote by being able to mine the transaction at or below the selected quote, while miners that are unable to mine the transaction (e.g., because their quote was too high) can still maintain a record of the blockchain transaction in temporary storage, such as an auxiliary memory pool, so that it can be used to validate against double-spending for a given transaction.

[0033] In some embodiments of the second aspect, the method also includes receiving a transaction identifier of a blockchain transaction corresponding to a submitted transaction generated by the at least one miner, that is, a transaction between a client and a 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.

[0034] Advantages related to the second aspect relate to those discussed above with respect to the first aspect. The second aspect is complementary to the first aspect and illustrates a method implemented by a client requesting that a transaction be written to a blockchain. A client implementing the method of the second aspect may, in some embodiments, communicate with at least one payment processor configured to implement a payment service as a payment API according to the method of the first aspect.

[0035] Additionally, the methods of the present aspect advantageously provide a payment service that allows clients to select fee quotes, providing client or merchant control, or the certainty that their transactions will be mined in a timely manner at a given mining fee, thereby providing increased security, interoperability, reliability, efficiency and timeliness for transactions mined for clients using the proposed payment service or payment API.

[0036] As mentioned 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, standard internet and web-based communication protocols can be advantageously used by the client to request that the transaction be mined into the blockchain. In some embodiments, data associated with the first request and / or the second request and / or the status query from the client is provided in JavaScript Object Notation (JSON) object format.

[0037] According to a third aspect, a computer-implemented method for processing transactions associated with a blockchain is provided, the method being executed by one or more processors associated with a miner among a plurality of miners, the plurality of miners being communicatively coupled to at least one payment processor implementing a payment service for a client. In some embodiments, the payment service is implemented by the payment processor according to the method described above in relation to the first aspect. In some embodiments, the client is configured to implement the method related to the second aspect described above. The method of the third aspect implemented by a miner among the plurality of miners includes providing a current fee quote for the miner for mining transactions in the blockchain in response to a first 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 the 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 transactions, or may be specific to a particular transaction between the client and the customer.

[0038] In some embodiments of the third aspect, in response to a second request from a payment processor on behalf of the client for submitting a given transaction associated with the client to the blockchain based on a selected fee quote (which selection can be made by the client as described in the first and second aspects), the method includes the following steps: Based on a determination that the selected fee quote associated with the given transaction meets the current fee quote of the miner, i.e., the selected fee quote is at or within the current fee quote, the given miner generates a corresponding blockchain transaction associated with the given transaction. The method also includes generating an output script (UTXO) of the created blockchain transaction, adding the generated output script to a memory pool associated with the miner, and sending the output script to the payment processor, the output script including 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 miner returns a result based on a current mining status of the corresponding blockchain transaction.

[0039] Advantages related to the third aspect relate to those discussed above with respect to the first and second aspects. The third aspect is complementary to the first and second aspects and describes a method implemented by a miner of a plurality of miners coupled to a payment processor for structuring transactions relating to a client that can be written to a blockchain. A miner implementing the method of the third aspect may, in some embodiments, communicate with at least one payment processor configured to implement a payment service as a payment API according to the method of the first aspect.

[0040] In some embodiments, the steps of providing a current fee quote and / or sending an output script and / or returning a result are implemented as remote procedure calls (RPCs). This is advantageous when miners are configured to communicate wirelessly via RPCs, such as in the BSV Bitcoin network. In some embodiments, the method of the third aspect may include sending the RPC from the miner to a node connector, and optionally a firewall for the miners, before propagating it to the payment processor for the client over a wireless communication network, for further security and streamlining of data flow within a miner pool or network, i.e., among multiple miners associated with a payment processor. Also, advantageously, the node connector may provide a secure communication channel between an API converter associated with the payment processor and one or more miners in the pool.

[0041] In some embodiments, based on a determination that the selected fee quote associated with a given transaction does not meet the miner's current fee quote, e.g., the current fee quote is higher than the selected fee quote, the method includes adding the output associated with the blockchain transaction to an auxiliary memory pool, which may be an additional temporary memory pool associated with the miner, which, as described above, may be stored there for a predetermined period of time so that a miner node may use such temporary entries to check and advantageously ensure that there are no double spends associated with a given transaction.

[0042] With the growing use of distributed ledger (blockchain) technology for numerous applications requiring secure, auditable, tamper-proof, and trustworthy records of events or transactions associated therewith, solutions for participating entities, such as clients or merchant entities, have traditionally relied on synchronizing a full copy of the blockchain in real time and identifying both transactions and embedded data related to their applications and associated digital wallets directly from the blockchain. However, as the scope, capabilities, and security of clients, i.e., commercial applications, evolve, and as blockchain expands, it has become apparent that there is a need for a technical solution that allows participants to directly communicate with each other and exchange messages directly with such applications in order to expand and fully realize the potential of the benefits associated with blockchain, and that it is desirable to make such a solution available to any type of client or entity, whether computationally advanced or not. A fourth aspect of the present disclosure provides such a solution to clients associated with payment services as described above in the first aspect.

[0043] According to a first implementation of the fourth aspect, the present disclosure provides a computer-implemented method of providing payment services to one or more clients for transactions associated with a blockchain, the method being performed by a payment processor. In some embodiments, the payment processor may be a payment processor as described in relation to the first aspect. The method includes receiving a request from a given client of the one or more clients to submit a transaction related to a digital asset to the blockchain. As described above in the previous aspect, the request is sent to the payment processor using an HTTP transmission format. In some examples, the request is the second request received from the client to submit the transaction.

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

[0045] The method of the fourth aspect then includes submitting the transaction associated with the request to a miner for inclusion in the blockchain. In some embodiments, this step is similar to submitting the transaction according to a second request received from the client as described in connection with the first aspect. The payment processor submits the transaction associated with the request and the callback identifier to a given miner among the multiple miners.

[0046] In some embodiments, upon receipt by a given miner of a transaction submitted via a payment processor, a transaction identifier associated with a corresponding blockchain transaction (corresponding to the submitted request) is received as a response from the miner, as described above in the first and / or second and / or third aspects. In some embodiments, this includes receiving an output script, e.g., unspent transaction outputs (UTXOs), associated with the corresponding blockchain transaction, as described above in the first aspect. This transaction identifier (TxID) of the corresponding blockchain transaction is then sent to the client.

[0047] The payment processor also identifies a given miner to the client by providing either an access endpoint, a miner identifier (Miner ID), or a location associated with the miner. In some cases, the miner may be identified to the client as part of the response described above with a TxID. The TxID is advantageous for the client to have so that any further communications or messages related to that TxID can be tracked. As described above, the TxID can also be used to check the status of the corresponding transaction (if the client chooses to initiate such a check).

[0048] The method then includes enabling or processing at least one callback notification for the client regarding the corresponding blockchain transaction provided by the miner. In an embodiment, the callback identification is such that it can be directly used by the miner to contact the client regarding the corresponding transaction, i.e., via a location or URL for the client, and the payment processor enables the callback notification. If the identified callback is such that it requires further steps, such as providing an access token or exchanging keys, to initiate such direct communication, the payment process must process such further access to allow the miner to communicate with the client using the callback identifier.

[0049] A second implementation of the fourth aspect of the present disclosure relates to an embodiment in which a request from a client to submit a transaction is associated with a channel. In this case, the channel identifier described above in the first implementation is in the form of a channel configured to enable direct communication between a given client and another entity. The channel in this implementation is supported or provided by a channel service associated with a given client and is specific to a given topic or transaction for a given client. The channel may be identified by a location, a URL, or a channel identifier associated with the client.

[0050] Channel services may be provided by a separate channel processor, by a payment processor as described above, or may be integrated with the client. In some embodiments, the channel is associated with one or more functions, including channel functions or procedures related to the transmission of data and / or message functions or procedures related to the data transmitted using the channel. Thus, the channel enables a direct or peer-to-peer communication path or session between entities for the transfer of messages or data. In most embodiments, there are only two entities for each channel.

[0051] An example of a Channel Service and / or Channel Processor is described in detail in UK Patent Application No. 2007597.4, filed in the name of N-Chain Holdings Limited, the subject matter of which is incorporated herein by reference.

[0052] In some embodiments, the one or more functions are in the form of an interface or access point provided for the client and in most cases are specific to a given channel of multiple channels that may be associated with the client, e.g., one for each transaction. In most embodiments, the channel allows full-duplex, i.e., bidirectional, communication between the client and another entity. In some embodiments, communication may be enabled in only one direction, i.e., the client may only wish to send messages to another entity or may only wish to receive messages from another entity.

[0053] In some embodiments, a client may be an owner of or associated with multiple channels, the channel being one of multiple channels based on one or more features provided by the channel service. In some embodiments, the one or more features are application programming interfaces (APIs) published or provided to a given client, including a channel API for one or more channels and a message API for data, i.e. messages on each channel or topic related to the given channel. An API can be understood as an endpoint, interface, or set of functions and procedures that allow the creation or management of an application for an entity, here for example a client, to access features or data of the application or other services. In this case, it is the one that implements the channel and message functions.

[0054] In a second implementation, the request from the client is further associated with one or more access tokens for the channel. These tokens are provided by the channel processor. In some embodiments, the token(s) are configured for secure communication with another entity, and the one or more access tokens relate 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 that is unique to a given channel or a given message. The access token, specifically the API token, may serve as a unique identifier for an entity or application requesting access to a channel in some embodiments. In some embodiments, the access token may be considered to be a unique credential assigned to the client, and may even be as granular as to an individual channel or an individual message in each channel. In some embodiments, the access token may be such that the client can provide to another entity for each of its channels for authentication. In this embodiment, the access token may be generated or provided by the client or the channel service for each transaction for the miner associated with the transaction.

[0055] In some embodiments, a channel may be associated with a channel identifier that is associated with a location or access point for the channel. 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 that may correspond to a location or endpoint through which the channel may be accessed. In some embodiments, a given channel is for communication with any other entity regarding data related to a particular type or topic, and data related to each topic in a channel is or is included in one or more messages or transactions. Advantageously, having a specific channel for a particular topic or transaction ensures greater clarity, reliability, and flexibility for the client, especially in the case of a client such as a merchant entity that may have multiple topics (e.g., transaction numbers or IDs or invoice numbers) that need to be tracked or handled separately from all of the other topics or other transactions related to the same client.

[0056] In embodiments, if the payment processor in the first implementation is also a channel processor, i.e., it implements not only payment services but also channel services for the client, the method of the fourth aspect may also include providing the miner access to the channel associated with a given client for the transaction. This is an advantage in embodiments where all communication with the client is managed or implemented by the payment processor and the channel is also set up by the payment processor on behalf of the client. Access may be provided in some embodiments by making available to the miner a channel identifier and / or location and an access token(s) that the miner may need to access one or more channels and / or messaging functions or APIs associated with the channels to get data or write to the channels for that client.

[0057] Once a channel is provided or access to a channel is provided, then callback notifications associated with the corresponding blockchain transaction from the miner are provided to the client using that channel, and thus data can be provided by the miner using that channel, i.e., data can be written to that channel using one or more channels and message functions or APIs obtained using the access token for that channel.

[0058] In some embodiments, the callback notification to the client can be an alert or message that is available as soon as data is written to the channel, and the notification includes a channel identifier in some cases. This is called a callback because it is for a specific TxID or blockchain transaction for a given client that has already been processed by the payment processor, i.e., sent by the payment processor to the miner. Advantageously, the channel allows for a message or response to be provided on a channel with a TxID specifically assigned for the given client.

[0059] In some embodiments, the callback notification concerns a notification of a double spend of a transaction already submitted by a given client and recorded on the blockchain. In this case, the data provided by the miner on the channel is a return payload that includes the following data: - The transaction identifier (TxID) of the blockchain transaction that was double-spent and, in some cases, optionally - A return payload containing the service endpoint for the payment processor that submitted the blockchain transaction. This is useful if the client is associated with multiple payment services and therefore the identifier clearly points to the payment processor that originally submitted the request to the miner.

[0060] In some embodiments, the callback notification relates to a proof of inclusion of the transaction submitted by the given client in the blockchain, i.e., a Merkle proof. In this case, the data provided by the miner on the channel is a return Merkle proof on the channel, which includes the following data: - The transaction identifier (TxID) of the blockchain transaction to which the Merkle proof pertains; and - the block header of the block that contains the blockchain transaction; - an array of sibling hashes of transaction identifiers (TxIDs); Including, In some embodiments, the channel or message functionality provided includes a JavaScript® Object Notation (JSON) over Hypertext Transfer Protocol (HTTP) API to enable accessing, creating and / or managing one or more data or messages on a channel for callback notification.

[0061] These data or callback messages related to the callback notification provided over the channel can be particularly advantageous for many blockchain-related applications, since in that case the miner can use the channel to send a Merkle tree proof or a double-spend notification of inclusion of the transaction submitted to the blockchain directly to another entity, in this case the client that requested the transaction submission. This is useful because it means that either the client or another entity, for example a merchant entity, no longer needs to look up the blockchain to find the transaction and check if it has been mined, since advantageously once mined, the proof of inclusion is provided directly over the channel.

[0062] The method of the second implementation of the fourth aspect also includes storing and / or providing the notification to the client. In some embodiments, when a client is offline or not communicatively connected to the channel processor, the callback notification is stored by the channel processor, i.e., stored as a push notification for data queued for a given client in the channel. In other embodiments, when a client is online or communicatively connected to the channel processor, the relevant data in the channel (related to the callback notification) may be pulled directly from the channel.

[0063] Advantageously, the use of channels allows for asynchronous processing of each request or message in a given channel. This allows for seamless and precise discontinuous or delayed processing flow for messages in channels, since channels are topic specific, so there is always clarity of messages and order for any given topic or transaction. This can be particularly useful in implementations or situations where a client or other entity is not operational, online, or unable to act on data associated with a callback notification. Thus, with channels, requests can still be reliably delivered and processed correctly and in order, since even if a party to a channel is offline or unresponsive, the messages will still be present in the channel so that they can be accessed based on notifications queued by the channel processor when they next come online or connect to the network. As mentioned above, the functionality of the channel processor can also be implemented by the same entity that implements the payment processor.

[0064] Also, no matter how many other messages are present in the channel, they are made accessible to the other entity in delivery order, so that despite delays or interruptions in the connection, the processing of messages in the channel is completed correctly and seamlessly, as if there was no delay at all.

[0065] Thus, the above-mentioned second implementation of the fourth aspect and its embodiments related to the present disclosure provides a secure, off-chain, party-to-party (peer-to-peer / direct) application messaging mechanism for processing transactions for clients by implementing a channel for direct communication. This aspect provides a mechanism by which parties can communicate in a secure manner even if, for example, one of the parties is temporarily offline. In the case of a client entity, which may be related to a business or represent an organization, for example a merchant, such a client may have a number of other entities (customers) with which it transacts with respect to a number of products. Thus, in such scenarios, it is highly beneficial to use a channel for communication with one or more customers or transactions, while being separated or decoupled from implementing functionality related to the blockchain that maintains a record of all such transactions. With the provision of channel and message functionality via the channel service, such a client has the ability to utilize a specific channel for a specific customer related to a specific transaction (e.g., a specific invoice or inquiry for a specific product), and further information specific to such transaction can be obtained at any time via the channel.

[0066] In a third implementation of the fourth aspect, the present disclosure provides a computer-implemented method of processing transactions associated with a blockchain, the method being executed by one or more processors associated with a client. The third implementation is similar to the second implementation with similar advantages. The method includes sending a channel request for a channel service executed by a channel processor. The channel processor may implement a client-facing channel service as described in UK Patent Application No. 2007597.4. The first request may be a Hypertext Transfer Protocol Secure (HTTPS) outgoing GET request to the channel processor. The client-implemented method then includes obtaining access to one or more functions that enable direct communication between a given client and another entity. As in the second implementation, the one or more functions include channel functions or procedures for one or more channels for transmission of data and / or message functions or procedures for data transmitted using the one or more channels. The client also obtains one or more access tokens for the channels as described above.

[0067] The method then includes sending a request to a payment processor implementing a payment service, such as a processor described in the first aspect or the first implementation of the fourth aspect, to submit the transaction related to the digital asset to the blockchain. The request may be a Hypertext Transfer Protocol Secure (HTTPS) transmission POST request to the payment processor, which may be associated with an HTTPS API.

[0068] The client then receives a response from the payment processor, the response including a transaction identifier (TxID) of a blockchain transaction corresponding to the submitted transaction. The corresponding blockchain transaction relates to a transaction submitted by the payment processor to the miner. This TxID received in the response is useful for tracking the corresponding blockchain transaction generated by the miner.

[0069] The client may also receive from the payment processor, separately or together with the response described above, an identifier or access point or location for the miner who provided the TxID.

[0070] Then, using one or more channel functions received from the channel processor, the method includes creating a channel for communication with the identified miner and transmitting one or more access tokens associated with the channel to another entity, in this case the miner, which advantageously allows for a secure, reliable and accurate set-up of a channel for direct communication between the client and the miner.

[0071] A callback notification is then received from the channel processor, which may be received at the client when it is online or when it is communicatively connected to the payment processor. Based on this notification, data related to a particular blockchain transaction, i.e., TxID, associated with the client can be obtained directly from the miner when the client is online.

[0072] Some embodiments of the third implementation of the fourth aspect relate to providing secure addressing and encryption for a channel used for peer-to-peer communication. In some examples, the method includes providing a client addressing key associated with a client and obtaining at least one minor addressing key associated with a minor. In some cases, if not already available or known to the client, the client endpoints may also be provided and minor points may be obtained. These addressing keys may be fixed or ephemeral or both and may be used to verify the identity of the respective endpoints. In this case, communication using the channel may be initiated based on the client addressing key and / or the minor addressing key, allowing a shared secret key to be derived based on a handshake pattern. Such shared secret key may then be used to encrypt all communication over the channel. The handshake pattern may be based on a noise protocol format, although other mechanisms may be used to derive the encryption / decryption key or key pair, such as, for example, Libsodium key exchange or generation techniques.

[0073] Advantageously, providing an endpoint, such as an API endpoint, for a client and an addressing key, such as a fixed key and / or a dynamic / temporary key, allows one or more processors associated with the client to securely access the miner. In some embodiments, these keys also allow an authentication procedure to be initiated prior to the transfer of messages over a channel, thereby enhancing security by verifying the identity of the parties managing the channel, thereby ensuring that all communication over that channel is only between two authenticated entities.

[0074] Obtaining a shared secret key so that direct communication using the channel is encrypted based on the shared secret key is further advantageous because the shared secret key is based on the identities, i.e. the addressing keys, of the two parties or entities managing the channel, and therefore only the respective legitimate and authenticated parties will be able to decrypt the encrypted ciphertext, thereby enhancing reliability and privacy, and being resistant to spoofing attacks by malicious parties.

[0075] In some embodiments, the endpoints for the client and / or miner may be HTTP API endpoints that are delivered to the other party (or trading partner) using the HTTP Secure (HTTPS) transport protocol prior to communication over the channel. This advantageously ensures that the endpoints are verifiable through a chain of certificates back to a known and trusted Certificate Authority (CA). In some embodiments, the client and miner endpoints may be Universal Resource Locations (URLs) that are included in responses to requests for one or more functions related to the channel services. Thus, advantageously, a person's identity can be known and verified by at least one party to the channel using a PKI or other mechanism.

[0076] In some embodiments, the endpoints for the client may be aliases associated with the respective entities of the channel, the aliases being unique to the client and provided by an alias-based addressing service having machine-readable resources accessible from a defined or well-known location, the machine-readable resources including one or more functions associated with the channel processor. The aliases may be known or provided to one or more other entities, and the aliases are associated with asymmetric cryptographic key pairs for authentication. Thus, advantageously, the identities of the parties may be known and verified by both parties using a PKI or other mechanism. Mechanisms already exist whereby easy-to-remember and more user-friendly aliases are used instead of complex published addresses of one or more client entities. One such solution is proposed in US Patent Application No. 16 / 384696 in the name of N-Chain Holdings Limited. The document describes an alias-based payment service, called bsvalias payment service, and an associated protocol, in which aliases are used instead of published addresses of client entities for destination addressing. An alias in such a system is typically associated with the domain name of the sending / receiving client entity and may be a URI or email address. Thus, as long as the sender or entity knows about or is provided with the alias, this is sufficient for the bsvalias payment system or other alias-based addressing mechanism. Messages are sent to the client's alias using instructions provided in a machine-readable resource, such as a JavaScript Object Notation (JSON) document, and stored at a well-known URI or location in the bsvalias or other payment service.

[0077] In a fourth implementation of the fourth aspect, the present disclosure provides a computer-implemented method for processing transactions associated with a blockchain, the method being executed by one or more processors associated with a miner. The fourth implementation is similar to the first implementation and has similar advantages.

[0078] In this implementation, the miner receives a request from the payment processor to submit a transaction to the blockchain, which in some embodiments may be similar to the second request from the payment processor as described in the third aspect to submit a transaction on behalf of a client.

[0079] The method then includes generating a blockchain transaction corresponding to the request and sending a response to the payment processor with an output script (UTXO) associated with the blockchain transaction. 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 miner may also be provided to the client along with the response.

[0080] Access to a client-specific channel for the TxID is then received. This access may be provided directly by the client after creating the channel, or by a payment processor on behalf of the client. As previously mentioned, this channel allows for direct communication with the given client. An access token is also received to access the channel to write data.

[0081] Based on the access token, the miner can then obtain, access, or retrieve a message function or message API to provide data related to a callback notification on the channel, the data relating to the corresponding blockchain transaction (TxID). As mentioned above, the callback notification can relate to a double-spend notification or Merkle proof for a given transaction, which can be delivered securely, accurately, and asynchronously directly to the client via the channel.

[0082] Thus, in this fourth implementation, a channel API or message API and / or an access token associated with the channel can be obtained by the miner to enable direct communication with the client. This is particularly advantageous in many blockchain-related applications, since the miner can then use the channel to send a Merkle tree proof of inclusion or some other message specific to the transaction submitted to the blockchain directly to the client. This is useful because it means that either the client, e.g. a merchant entity, or another entity, e.g. a customer or indeed a payment service, no longer needs to look up the blockchain to find the transaction and verify its status. This is because, advantageously, once mined, the proof of inclusion can be sent directly to the client using the channel. Alternatively, if for some reason the transaction associated with that TxID is not mined, a message can be sent over the channel about that transaction, e.g. an error notification or a double-spend notification. The present disclosure also provides a computer system having a payment processor communicatively coupled to at least one client and at least one miner via a wireless communication network, the payment processor being accompanied by an API converter for converting HTTPS requests from the client to RPC requests to the miner and vice versa, whereby the payment processor is implemented according to the first aspect. The computer system also has 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 has a plurality of miners, each of which is communicatively coupled to the payment processor via the wireless communication network, whereby each of which is implemented according to the third aspect.

[0083] In some embodiments, a computing device is provided having a processor and a memory, the memory including executable instructions that upon execution by the processor cause the device to perform the aspects and / or embodiments described above.

[0084] In some embodiments, a computer readable storage medium is provided having executable instructions stored thereon which, when executed by a processor of a computer system, cause the computer system to perform the methods of the above-mentioned aspects and / or embodiments.

[0085] Some particular embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which like features are referred to with like reference numerals, and in which:

[0086] First Aspect – Payment Processor FIG. 1 relates to a first aspect of the disclosure and illustrates a method performed by a payment processor to implement a payment service for a client, as described above. The payment processor is communicatively coupled to a client or clients, as well as to a number of miners, which may include two or more networks of miners or two or more mining pools. In some embodiments, the payment processor may be part of the client or may be implemented in association with the client. This is the case when the client is a computationally sophisticated commercial point-of-sale (POS) terminal. Aspects and embodiments of the disclosure are contemplated to cover both such implementations, i.e., remote payment processor or part of the client. An example of a system architecture can be seen in FIG. 4, described later herein.

[0087] In the example scenario illustrated in FIG. 1, the embodiments relating to obtaining a plurality of mining fee estimates, submitting a transaction based on a fee estimate selected from the obtained plurality of mining fee estimates, and sending a status query for a transaction identifier are described as all occurring sequentially and as a single process in the flowchart of FIG. 1. However, the present disclosure and the first aspect are not to be considered so limited. The steps relating to obtaining a fee estimate in a first request in steps 102-106 described below may be performed independently from the remaining steps. Similarly, the steps relating to submitting a transaction in a second request in steps 108-114 may be performed at a different time from the preceding step of obtaining a fee estimate. In the same manner, the steps relating to transaction status inquiry from step 116 onwards may be performed at any time after the client recognizes the transaction identifier and need not follow the sequence of FIG. 1. All steps are simply illustrated in a sequence here for ease of explanation and understanding, and the present disclosure should not be considered limited to such sequence or scenario under any circumstances.

[0088] Step 102 illustrates receiving a first request from a client for mining fee quotes associated with mining a transaction in a blockchain. The first request may be for multiple transactions. For ease of explanation and understanding, FIG. 1 is described with respect to a single transaction in the first request associated with the client, but the disclosure is by no means so limited. This step refers to the collection of mining fee quotes from multiple miners associated with mining a transaction on behalf of the client. The transaction typically relates to a digital asset payment between the client, which is a merchant computing resource or entity, and a customer entity. As mentioned above, the first request is received in JSON format from the client over or using the HTTPS protocol. The payment processor implements the payment interface as a client-facing application programming interface (API) and therefore can accept and process HTTPS when the API is implemented as a web service. An API endpoint is made available to the client. If there are multiple transactions in the first request, either the same API endpoint or another API endpoint of the payment processor may be used.

[0089] For example, in some embodiments, a 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 for developing web services and web-based interactions. The REST API design standard may handle HTTPS requests and communications using the following commands: [Table 1] Mostly GET and POST HTTPS requests will be discussed here, but the application is not limited to these commands. In this step 102, the first request received by the payment processor may be an HTTPS request of the form GET getFeeQuote.

[0090] A resource in the context of a REST API is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. In some embodiments, a payment service is provided by a payment processor as an API implementation to access the state of a blockchain or distributed ledger, e.g., the Bitcoin SV (BSV) blockchain, and trigger operations that can change that state through an application interface and expose it as a REST API. The payment processor may thus be considered as a REST endpoint for one or more clients. For ease of explanation only, one client (or merchant) and one payment processor are described throughout, but the disclosure is not so limited. The client may thus communicate with the payment service via HTTPS, and further, the client may advantageously have anonymous access to the payment processor or to the payment services implemented by the payment processor. When there are more than one client and more than one payment processor, the client is responsible in some embodiments for targeting or contacting the correct or intended payment processor or REST endpoint, based on an agreement that the client may have with, e.g., one or more third parties running a payment processor.

[0091] Step 104 shows obtaining a fee quote for mining the transaction from each of the miners among the miners. In this step, all miners coupled to the payment processor are polled or contacted by the payment processor and asked to return a current fee quote for mining the transaction, i.e., writing the transaction to the blockchain after validating the locking and unlocking scripts. Currently, some blockchain networks, such as the BSV network, support communication via remote procedure calls (RPC). Thus, in that case, an API converter associated with the payment processor is used to convert the HTTPS first request, i.e., GET getFeeQuote, to an RPC first request, i.e., RPC getFeeQuote(), and vice versa. Such conversion is necessary in embodiments that need to support such BSV node implementations or other implementations that only support RPC. As mentioned above, the API converter can be part of an API gateway or gateway processor associated with the payment processor, and HTTP / RPC conversion is just one of the functions provided by the API gateway. The purpose of the RPC format getFeeQuote() sent to the miners is to inform the client of the fee charged by each miner. No input parameters are required, but an RPC interface may need to be implemented around the RPC getFeeQuote() so that this command returns the data type from each miner in the form of a JavaScript Object Representation JSON object, i.e., MinerFeeQuote, that contains the fee-related data collected from each miner.

[0092] The data regarding the obtained fee quotes collected from each miner can be specified as a JSON object, as given in the example below.

[0093] The JSON object FeeQuote returned by each miner is shown below. An example is shown for a single transaction, but the disclosure is not so limited and the same applies to fee quotes representing mining fees for multiple transactions: [ { #MinerFeeQuote “MinerID”: <alphanumeric>, #If MinerID is null (empty), "NO-ID" is the default "CurrentHighestBlockHash": <alphanumeric>, "MinerSignature”: <alphanumeric>, #Contains current block hash + block height "SignatureTimestamp":<UTC Timestamp> #Miners guarantee fees from this point until they are superseded "MinerReputation": <alphanumeric>, #If this is blank (null), return "Unknown" [ { # FeeTypes "FeeType":<"SPB"||"SPDB"||…>, #Satoshis-per-byte,Satoshis-per-data-byte etc. "CurrentFee":<Floating Point Number> , "Expiry": <integer>, duration or date / time at which Fee expires, "FeeOnExpiry”:<Floating Point Number> , #If Expiry is 0, this should be set to CurrentFee "GuaranteeFee":<Floating Point Number> #Guarantee that Tx will be processed with this fee (0 means none) "KeepInMempoolFee":<Floating Point Number> , #Fee for holding Tx in auxiliary memory pool }, {…} ] "Margin":<Floating Point Number> , #Allowable margin for error in using FP numbers "API version": <numeric>#API version NN.nn (major.minor version number) }, { #MinerFeeQuote "MinerID": <alphanumeric>, #If MinerID is null (empty), "NO-ID" is the default "CurrentHighestBlockHash": <alphanumeric>, "MinerSignature”: <alphanumeric>, #Contains current block hash + block height "SignatureTimestamp":<UTC Timestamp> #Miners guarantee fees from this point until they are superseded "MinerReputation": <alphanumeric>, #If this is blank (null), return "Unknown" [ { # FeeTypes "FeeType":<"SPB"||"SPDB"||…>, #Satoshis-per-byte,Satoshis-per-data-byte etc. "CurrentFee":<Floating Point Number> , "Expiry": <integer>, duration or date / time at which Fee expires, if 0 fee is not guaranteed to not change "FeeOnExpiry”:<Floating Point Number> , #If Expiry is 0, this should be set to CurrentFee "GuaranteeFee":<Floating Point Number> #Guarantee that Tx will be processed with this fee (0 means none) "KeepInMempoolFee":<Floating Point Number> , #Fee for holding Tx in auxiliary memory pool }, {….} ] "Margin":<Floating Point Number> , #Allowable margin for error in using FP numbers "API version": <numeric>#API version NN.nn (major.minor version number) }, MinerFeeQuote may repeat as necessary - one per miner ]

[0094] For ease of understanding, another example of the above JSON object FeeQuote populated with data items is given below: GET / mapi / feeQuote response { "apiVersion":"0.1.2", "timestamp":"2020-09-15T12:44:19.75812Z", "expiryTime":"2020-09-17T13:09:31.4573849Z", "minerId": "030d1fe5c1b560efe196ba40540ce9017c20daa9504c4c4cec6184fc702d9f274e", "currentHighestBlockHash": "2084f6352e242c496cba0a3c45be9b69ff2ef69718b1286a9c0f9c2a1089f6ae", "currentHighestBlockHeight":1334, "fees":[ { "feeType":"standard", "miningFee":{ "satoshis":500, "bytes":1000 }, "relayFee":{ "satoshis":250, "bytes":1000 } }, { "feeType":"data", "miningFee":{ "satoshis":500, "bytes":1000 }, "relayFee":{ "satoshis":250, "bytes":1000 } } ] }

[0095] The JSON FeeQuotes object, in some embodiments, contains an array of miner details and fees charged, while MinerFeeQuote is a JSON structure that contains miner and fee data received from one miner. Some of the terms in the above JSON object are explained below:

[0096] CurrentHighestBlockHash can be used as a marker to identify the block hash at which the blockchain has grown up to the time getFeeQuote() is called.

[0097] MinerSignature may contain the signature of a miner who has agreed to endorse this transaction, as described above. This is distinct from the digital signature used to verify the identity of the miner. By doing this, the miner may guarantee that it will soon include the transaction in a block, and, optionally, not include a contradictory transaction. If the miner is not willing to endorse the transaction, this may be set to null.

[0098] The SignatureTimestamp indicates the time at which the miner guarantees to mine the transaction with the declared current fee, i.e., that the fee is guaranteed from that point on until it is superseded by any subsequent call to getFeeQuote() by the client.

[0099] MinerReputation is a measure of a miner's performance, i.e., how well the miner performs transactions with the current fees promised or quoted. This reputation score / indicator may be calculated, maintained, and managed by each payment processor.

[0100] The Miner ID can be a two-part piece of data that is added to a coinbase transaction when a block is mined. If a Miner ID is not present, the payment processor can tag the miner with a "NULL" Miner ID or simply leave it blank.

[0101] Within each MinerFeeQuote, an array of FeeTypes objects may be used to capture the various fee types currently available. In the future, any changes to the getFeeQuote() interface provided by the payment processor may introduce additional fee types as required. Every transaction may have one FeeTypes array.

[0102] Step 106 depicts providing the obtained fee quote by the payment processor to the client, which in some embodiments may include a recommended fee quote determined by the payment processor. As described above with respect to the first aspect, this step may include RPC to HTTPS conversion by an API converter so that the client can access the details using a web-based API.

[0103] At step 108, a second request is received from the client, the second request being a request to submit a given transaction in association with a fee quote selected from among the obtained fee quotes. The given transaction, in some embodiments, is based on a digital asset payment made by a customer to a client in response to a payment request from the client. For example, this may be a Satoshi-type or other type of digital asset payment in exchange for a cup of coffee, where the client is a commercial terminal in a coffee shop. At this step, the client requests that this digital asset payment be written to the blockchain via a payment services API implemented by the payment processor.

[0104] As mentioned above, the second request from the client may, in some embodiments, be a request to submit multiple transactions.

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

[0106] As mentioned above, the quote selected may be based on the average or maximum of all fee quotes obtained.

[0107] In some embodiments, the second request is an HTTPS request in the form of POST submitTransaction(Tx), where Tx, in some embodiments, is a JSON-formatted object related to a given transaction relating to a payment between the client and the customer. Thus, Tx (the JSON object) contains the data necessary to create a transaction on the blockchain that the client may provide or construct as a JSON structure prior to submitting the second request to the payment processor for delivery to the miner.

[0108] Step 110 illustrates sending a request to one or more of the miners to generate a blockchain transaction corresponding to the given transaction in step 108. In this step, the payment processor, in some embodiments, converts the HTTPS POST request in the previous step into an RPC request for submission to the miners. This can be done using a request RPC createRawTransaction(Tx), where Tx includes data related to the given transaction provided as a JSON object as described in step 108. RPC createRawTransaction(Tx) is an RPC call to create a transaction that uses the given inputs to create a new output, which can be an address or data. This RPC request can be sent to the miners, or it can be sent to a miner that meets or satisfies the selected fee quote from the client in step 108. As described above, miners that provide a current fee quote that is equal to or less than the selected fee quote are considered to meet the requirements of the selected fee quote since they can mine the transaction at their respective estimated current fee. In response, miners that meet the selected fee quote create a blockchain transaction corresponding to the given transaction. In some embodiments, the hex-encoded raw transaction corresponding to a given transaction is returned to the payment processor.

[0109] At step 112, an output or output script associated with a corresponding blockchain transaction created by at least one of the miners that meets the selected fee estimate is received at the payment processor. The output script may be a UTXO associated with the corresponding blockchain transaction created by the miner. In some embodiments, the UTXO may also be stored in the memory pool of the miner that meets the selected fee estimate. The output of this step will include a transaction identifier (TxID) of the corresponding blockchain transaction created by the miner. The TxID is a reference to the hex-encoded transaction submitted to the miner's memory pool, which is then mapped to the blockchain transaction accordingly by the payment processor.

[0110] This blockchain transaction may then be mined either immediately or at a later point in time to complete the mining process at the current fee estimate. In some cases, a created transaction may not be mined because another miner wrote it to the blockchain, or it may be held up or rejected for some reason, such as a double spend or being overdue or invalid.

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

[0112] Here is an example of the details present in the TxResult object for a client: The JSON object TxResult contains some of the terms and objects shown below for the miner and described in step 104 as part of the FeeQuotes JSON object. [ { "ReturnResult”: <alphanumeric>, #ReturnResult is defined below "ResultDescription”: <alphanumeric>, #Failure reason (e.g. which policy failed and why) "DoubleSpendTxID": <alphanumeric>, #TxID of the double-spend transaction "ExceptionTimestamp":<UTC Timestamp> , #Time exception detected (e.g. double-paid time) "BlockHash": <alphanumeric>, #The block containing this transaction "BlockHeight": <integer>, "MinerID": <alphanumeric>, #If MinerID is null (empty), "NO-ID" is the default "MinerSignature": <alphanumeric>, #Block hash + block height + TxID "SignatureValidFrom":<UTC Timestamp> , #MinerSignature validity time (from getFeeQuote) "TxID": <alphanumeric>, #Transaction ID assigned when submitting to memory pool "txSecondMempoolExpiry": <integer>, #minutes held in auxiliary memory pool "API version": <numeric>#API version NN.nn (major.minor version number) } ]

[0113] The ReturnResult described above can have one of the following possible values: ·Submitted - No problems, the transaction was submitted to the memory pool · Rejected_DS - rejected due to double spend - DoubleSpendTxID cannot be null ·Rejected_Policy - rejected due to policy violation · Rejected_Invalid - The transaction was rejected because it was invalid. Rejected_FeeTooLow - The miner did not include Tx in the block because the fee was too low Rejected_KeepInMemPool - Tx is rejected but kept in the memory pool to check for double spends.

[0114] Step 116 shows receiving a status query associated with the transaction identifier TxID from the client for sending to multiple miners. This step and subsequent steps may be performed asynchronously with the above steps of arranging for submitting a transaction after selecting a fee quote from among multiple mining fee quotes and should not be considered essential to the operation of the first aspect. The embodiment of step 116 and subsequent steps relates to a scenario where the client wants to know the status of one or more second requests made in step 108.

[0115] Step 116 allows the client to query the status of the transaction that the client submitted to the payment processor via the HTTPS POST submitTransaction(Tx) described in step 108. Thus, the TxID in this step can correspond to any second request made for any given transaction related to a digital asset payment between the client and its customer. As described in the above steps, the status query is received from the client using HTTPS as the transmission protocol, and the query is sent in JSON format, for example, GET queryTransactionStatus(TxID), which is then converted into an RPC request, RPC getRawTransaction(TxID), for sending to one or more miners among the miners.

[0116] At step 118, the payment processor receives a response from the relevant miner among the miners involved in creating and / or processing the blockchain transaction associated with the 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 that case, the result returned from the relevant miner in case of success will, in some embodiments, be in JSON format including the corresponding blockchain transaction decoded at steps 110 and 112. This advantageously provides flexibility in capturing and processing the data therein. If the Verbose parameter is set to 0, a hex-encoded transaction is returned to the payment processor instead of a JSON data type or document format. If no such transaction related to the TxID is found, null may be returned, which results in the ReturnResult object being set to 'Unknown'. Any other returned errors may also be reported by the miner to the payment processor via the ReturnResult and ResultDescription objects. These objects are shown in connection with step 114.

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

[0118] The JSON object TxStatus is shown below: [ { "ReturnResult”: <alphanumeric>, #ReturnResult is defined below "ResultDescription”: <alphanumeric>, #Failure reason (e.g. which policy failed and why) "DoubleSpendTxID": <alphanumeric>, #TxID of the double-spend transaction "ExceptionTimestamp":<UTC Timestamp> , #Time exception detected (e.g. double-paid time) "BlockHash": <alphanumeric>, "BlockHeight”: <integer>, "Confirmations”: <integer>, #0 if unconfirmed "MinerID": <alphanumeric>, #If MinerID is null (empty), "NO-ID" is the default "MinerSignature": <alphanumeric>, #Block hash + block height + TxID "SignatureValidFrom":<UTC Timestamp> , #MinerSignature validity time "API version": <numeric>#API version NN.nn (major.minor version number) } ]

[0119] BlockHash and MinerID may be populated if the transaction has been successfully mined and flagged as confirmed (i.e., added to a block) by the miner. If the miner has not set the MinerID, it shall be set to "NULL".

[0120] And the ReturnResult object may contain one of the following mining results: ·Submitted - No problems, the transaction was submitted to the memory pool Confirmed - transaction confirmed, confirmation cannot be 0 or null · Rejected_DS - rejected due to double spend - DoubleSpendTxID cannot be null ·Rejected_Policy - rejected due to policy violation · Rejected_Invalid - The transaction was rejected because it was invalid. Rejected_FeeTooLow - The fee is too low, so the miner will not include the Tx in the block. Rejected_KeepInMemPool - Tx is rejected but kept in the memory pool to check for double spends Unknown - transaction not seen or exists - it is possible that a transaction with the provided TxID does not exist in the memory pool or in the blockchain. If so, this should be described in the ResultDescription.

[0121] Second aspect – the client Figure 2 relates to a second aspect of the disclosure and illustrates a method performed by one or more processors associated with a client, the client being communicatively coupled to at least one payment processor implementing the method described in relation to the first aspect. The payment processor implements the payment service or payment API described in relation to Figure 1 for the client, as described above.

[0122] In the example scenario illustrated in FIG. 2, the embodiments relating to obtaining a plurality of mining fee estimates, submitting a transaction based on a fee estimate selected from the obtained plurality of mining fee estimates, and sending a status query for a transaction identifier are described as all occurring sequentially, i.e., as a single process in the flowchart of FIG. 2. However, the present disclosure and the second aspect are not to be considered so limited. The steps relating to obtaining a fee estimate in a first request in steps 202-206 described below may be performed independently from the remaining steps. Similarly, the steps relating to submitting a transaction in a second request in steps 208-212 may be performed at a different time from the preceding step of obtaining a fee estimate. In the same manner, the steps relating to transaction status inquiry from step 214 onward may be performed at any time after the client recognizes the transaction identifier and do not have to follow the sequence of FIG. 2. Here, all steps are simply illustrated in a sequence for ease of explanation and understanding, and the present disclosure should not be considered limited to such a sequence or scenario under any circumstances. Additionally, as discussed above in connection with Figure 1, fee quotes may be requested and / or obtained and / or submitted and / or queried separately for a single transaction each time, or for a set or batch of multiple transactions submitted by a client at the same time in a single request. For ease of explanation and understanding, Figure 2 is described with respect to a single transaction with first request / second request and status query associated with a client, but the disclosure is in no way so limited.

[0123] Step 202 depicts sending a first request to a payment processor among at least one payment processor associated with the client for providing the respective payment services. As described in connection with step 102 of FIG. 1, the request relates to one or more fee quotes for mining transactions for the client. The first request relates to an HTTPS GET getFeeQuote as described in connection with step 102. As discussed above, the request may be for mining any transactions for the client or may be a request to obtain a fee quote for mining transactions related to digital asset payments from a customer associated with the client.

[0124] At step 204, a plurality of mining fee quotes are received from the payment processor, the fee quotes relating to mining fees for each of a plurality of miners communicatively coupled to the payment processor serving the client. The structure and details of the received fee quotes have been described above in connection with step 104 of FIG.

[0125] Step 206 depicts selecting a fee estimate from among the one or more fee estimates received in step 204. In some embodiments, the selected fee estimate may be based on a recommended fee estimate proposed by a payment processor. In some embodiments, the selection is made by one or more processors associated with the client. The selected fee estimate may be the average or median of the obtained fee estimates, or the maximum of the fee estimates obtained from multiple miners, or the highest fee estimate in the auxiliary memory pool, as described above. Thus, the client may select the highest fee value obtained from multiple miners responding to the first request. In this way, all miners may be given an equal opportunity to mine the transaction at their respective currently quoted fees. On the other hand, the client may instead select a fee estimate that is at or above the median or average of all received fee estimates, so that miners with higher estimates simply keep the transaction in the auxiliary memory pool and use it to check for any double spends of the transaction to reject it.

[0126] Step 208 depicts requesting and / or processing a digital asset payment from a customer associated with the client. This may be a payment request or an invoice sent by the client to the customer for the digital asset payment using known methods applied to both parties' respective digital wallet implementations. Since the selected fee quote for mining any transaction into the blockchain is known, the request may include or be associated with the selected fee quote.

[0127] Step 210 depicts sending a second request to the payment processor to submit the given transaction related to the digital asset payment from the customer to the blockchain. The submission in this step is based on the selected fee estimate for mining the given transaction in step 206. This step involves the client sending an HTTPS POST submitTransaction(Tx) request to the payment processor with relevant details in JSON data type format for the given transaction in step 108 of FIG.

[0128] Step 212 depicts receiving a transaction identifier (TxID) for a blockchain transaction corresponding to the submitted transaction. As described in steps 110 and 112 of FIG. 1, the TxID is created by at least one miner that meets the selected fee quote. In some embodiments, this may be sent together with or as part of the transaction result, i.e., TxResult, which indicates the current mining status of the corresponding blockchain transaction for that miner. This is described in relation to step 114 of FIG. 1.

[0129] Step 214 involves the client sending a status query when the client wishes to inquire about the mining status of a transaction related to a settlement between the client and a customer and that was previously submitted in step 210. Since the client received the TxID of the submitted transaction in step 212, this request can be based on the TxID and can be in the form of HTTPS GET queryTransactionStatus(TxID), as described in step 116 of FIG.

[0130] Step 216 depicts obtaining a mining status result for the blockchain transaction corresponding to the transaction identifier TxID queried in step 214. This may be in JSON format and is sent by the payment processor to the client using HTTPS after the payment processor receives the corresponding transaction details. The status result may be in the form of a TxResult JSON object as seen in step 120 of FIG. 1.

[0131] Third aspect – Minor implementation Figure 3 relates to a third aspect of the disclosure and illustrates a method performed by a miner among a plurality of miners communicatively coupled to at least one payment processor implementing the method described in relation to the first aspect. The payment processor implements the payment service or payment API described in relation to Figure 1 for a client. The client is configured to implement the method described in relation to Figure 2.

[0132] In the example scenario illustrated in FIG. 3, the embodiments relating to providing a plurality of mining fee estimates, generating / creating a blockchain transaction based on a fee estimate selected from the obtained plurality of mining fee estimates, and providing a mining status for a transaction identifier are described as all occurring sequentially, i.e., as a single process in the flowchart of FIG. 3. However, the present disclosure and the third aspect are not to be considered so limited. The steps relating to providing a fee estimate in response to a first request in steps 302 and 304 described below may be performed independently from the remaining steps. Similarly, the steps relating to generating a corresponding blockchain transaction in response to a second request in steps 308-314 may be performed at a different time from the preceding step of obtaining a fee estimate. In the same manner, the step relating to providing a transaction status in step 316 may be performed at any time after the client recognizes the transaction identifier and need not follow the sequence of FIG. 3. Here, all steps are simply illustrated in a sequence for ease of explanation and understanding, and the present disclosure should not be considered limited to such sequence or scenario under any circumstances. Additionally, as discussed above in connection with Figures 1 and 2, fee quotes may be requested and / or obtained and / or submitted and / or queried separately for a single transaction each time, or for a set or batch of multiple transactions submitted by a client at the same time in a single request. For ease of explanation and understanding, Figure 3 is described with respect to a single transaction with first request / second request and status query associated with a client, but the disclosure is in no way so limited.

[0133] Step 302 depicts receiving a first request from a payment processor to provide a fee quote for mining a transaction on behalf of a client. This request relates to an RPC getFeeQuote() request sent from the payment processor as described in connection with step 104 of FIG.

[0134] Step 304 depicts providing a current fee quote associated with each miner among the plurality of miners for mining a transaction on the blockchain. The fee quote may be provided in the format of a JSON object FeeQuote as described in connection with step 104 of FIG. 1.

[0135] Step 306 illustrates a step in which a miner among the miners receives a second request to submit a given transaction related to a client to the blockchain, the given transaction being based on a selected fee quote from the client. The given transaction relates to Tx in POST submitTransaction(Tx) of step 210 of Figure 2, i.e., a given digital asset payment transaction between the client and a customer. As described in relation to step 110 of Figure 1, the RPC version of this received from the payment processor is the RPC createRawTransaction(Tx) for the given transaction.

[0136] Step 308 shows the miner checking to see if it satisfies or meets the selected fee quote from the client, which may include determining whether the current fee quote provided by the miner to the payment processor in step 304 is less than or equal to the selected fee quote that the client is willing to pay to mine a given transaction Tx.

[0137] If the current fee quote meets the selected fee quote, then at step 310, a blockchain transaction corresponding to the given transaction is created. This is described in connection with step 110 of FIG. 1. In some embodiments, a hex-encoded raw transaction corresponding to the given transaction is returned to the payment processor. As described in step 112 of FIG. 1, an 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 miner. The output script (UTXO) for the blockchain transaction may then be added immediately or at a later point in time to a memory pool associated with the miner for mining.

[0138] If the current fee estimate does not meet the selected fee estimate, i.e., if the current fee estimate of the given miner is higher than the fee estimate accepted or selected by the client, the given miner may, in some embodiments, choose to mine at a lower fee than the current fee estimate, or may choose not to mine the given transaction because the selected fee is lower than the respective current estimated fee. In embodiments in which the given miner chooses not to mine the transaction at the lower selected fee estimate, in step 312 the given miner may instead add details about the blockchain transaction constructed for the given transaction to an auxiliary memory pool associated with the given miner. This transaction may, in some embodiments, be kept in the auxiliary memory pool and used to check for double spends. All transactions stored in the auxiliary memory pool may have an expiration time after which they may be removed.

[0139] Assuming that the blockchain transaction has been created, i.e., the relevant miner meets the requirements of the selected fee quote set by the client, step 316 involves the relevant miner receiving a status query associated with the TxID of the blockchain transaction created for the client, the status query being based on the RPC request RPC getRawTransaction(TxID) received via the API converter, as described in connection with steps 116 and 118 of FIG.

[0140] At step 318, a result based on the current mining status of the corresponding blockchain transaction associated with the miner is provided to the payment processor, which may be based on the JSON object structure for TxStatus, as described in connection with step 120 of FIG.

[0141] FIG. 4 is a schematic diagram of a deployment architecture of payment services provided to clients 402 as APIs by a payment processor 404. There may be more than one such payment processor 404, and one or more of the payment processors 404 may be implemented as part of the client, associated with the client, or implemented separately from the client and communicate with the client over a communication network, such as the Internet. As described in the above aspects, communication between the client 402 and the payment processor 404 uses the HTTPS protocol. Although the API converter 406 is also shown separately in this schematic diagram, in some embodiments the API converter 406 may be implemented as part of the payment processor 404. In some embodiments, the API converter 406 may be operated or implemented by multiple miners 412-1 to 412-n. The API converter 406 allows for conversion of HTTPS requests into RPC requests before sending the HTTPS requests to one or more miners 412-1 to 412-n coupled to the payment processor 404 to provide services to the client 402. The API converter 406 is shown connected to the miners 412-1 to 412-n through a firewall 408. All communications related to the miners 412-1 to 412-n use RPC. Also shown is a node connector 410 for connecting the miners 412-1 to 412-n through the firewall 408 to the payment processor 404. In some embodiments, the node connector may guarantee or process RPC calls related to one or more payment processors implementing respective payment services, as described in connection with FIG. 1. The node connector 410 provides a secure communication channel between the API converter 406 and one or more miners 412-1 to 412-n.

[0142] There may be one or more payment processors 404 connecting the miners 412-1 to 412-n through an API converter 406. The client 402 will likely include a digital wallet application to get a quote for miner fees (getFeeQuote), submit a transaction (submitTransaction), and query the status of a transaction (queryTransactionStatus) as described in relation to the first to third aspects for individual or multiple transactions. The payment processor 404 acts as a REST endpoint for the client 402, and the client may have anonymous access to this service. The miners 412-1 to 412-n may mine one or more nodes in exchange for a mining reward, which in some embodiments may consist of a block reward and a miner fee. The block reward is referred to as BSV or a cryptocurrency that is awarded to the miner 412 when he or she successfully mines a block. The miner fee is the reward that the miner 412 receives when he or she validates a transaction and adds it to a newly mined block.

[0143] Figure 5 is a schematic diagram showing the data flow between the components of the architecture shown in Figure 4 for implementing a getFeeQuote command or template from a client. This has already been described above in relation to Figures 1-3, and Figure 4 simply outlines the interaction of the client, the payment processor and the miner for obtaining a mining fee quote. The flow originates from the client 402 when an HTTPS GET getFeeQuote command is sent to the payment processor 404 in step 501. In step 502, the GET command is sent to the API converter 406 which converts it to an RPC command RPC getFeeQuote() in step 503. In step 504, a MinerFeeQuote is returned from each of the miners 412 of the plurality of miners 412-1 to 412-n to the API converter 406 as a JSON object format, which is then provided to the payment processor 404 in step 505. Steps 502-505 are repeated for each miner in the plurality of miners 412-1 to 412-n, and the result (the fee quote) is sent to the client 402 in an HTTPS transmission in step 506.

[0144] FIG. 6 is a schematic diagram showing the data flow between the components of the architecture shown in FIG. 4 for implementing a submitTransaction command or template from a client. This has already been described above in relation to FIGS. 1-3, and FIG. 4 simply outlines the interaction of the client, the payment processor, and the miner to provide a blockchain transaction related to a payment to the client. The flow originates from the client 402 when, in step 601, an HTTPS POST submitTransaction(Tx) command is sent to the payment processor 404 for a given transaction Tx between the client 402 and the customer. As mentioned in relation to the above aspect, Tx may be related to a selected fee quote (not shown in this figure). In step 602, the POST command is sent to the API converter 406, which converts it to an RPC command RPC createRawTransaction(Tx) in step 603. A blockchain transaction is then constructed at each miner 412 that satisfies the selected fee quote. In step 604, the hex-encoded blockchain transaction is returned to the API converter 406. This transaction includes a unique identifier TxID, as described in the embodiment above. At step 605, outputs related to the blockchain transaction are sent to the payment processor 404. And, results related to the blockchain transaction are returned to the client at step 606 as a JSON TxResult object including the TxID.

[0145] FIG. 7 is a schematic diagram showing the data flow between the components of the architecture shown in FIG. 4 for implementing a queryTransactionStatus command or template from a client. This has already been described above in relation to FIGS. 1-3, and FIG. 4 simply outlines the interaction of the client, the payment processor, and the miner to provide a blockchain transaction related to a payment for the client. The flow originates from the client 402 when, in step 701, an HTTPS GET queryTransactionStatus(TxID) command is sent to the payment processor 404 for a given transaction TxID related to a blockchain transaction previously returned to the client as part of the submitTransaction flow of FIG. 6. In step 702, the GET command is sent to the API converter 406, which converts it to an RPC command RPC getRawTransaction(TxID). in step 703. The blockchain transaction related to the given miner 412 related to the TxID is then identified. In step 704, the identified hex-encoded blockchain transaction and its associated status are returned to the API converter 406. At step 705, the status results related to the blockchain transaction associated with the TxID are sent to the payment processor 404. And, at step 706, the status results related to the blockchain transaction associated with the TxID are returned to the client as a JSON TxStatus object.

[0146] Also, as discussed above in connection with Figures 1-3, fee quotes may be requested and / or obtained and / or submitted and / or queried separately for a single transaction each time, or for a set or batch of multiple transactions submitted by a client in a single request, i.e., at the same time. For ease of explanation and understanding, although Figures 4-7 are described with respect to a single transaction in a first request and / or second request and / or status query associated with a client, the disclosure is in no way so limited.

[0147] Fourth aspect – Callback Identifier 8 is a flow diagram illustrating a method of supporting a callback mechanism for a transaction according to a fourth aspect, the diagram relating to a method implemented by one or more processors associated with a payment service, such as those described above in relation to the first aspect.

[0148] Step 802 includes receiving a request from a given client of the one or more clients. The request is for submitting a transaction related to a digital asset. For example, this may be a second request to submit a transaction as described in step 108 of FIG. 1. The request is also associated with a callback identifier. The callback identifier, in some embodiments, may be either provided by the client or associated with the client. For example, it may be a URL or an API endpoint by which the client can be contacted. In some cases, it may also point to a location associated with the client. In some cases, the callback identifier may be a location or identifier communication channel. Such channels are further described in FIGS. 9-11 below. The purpose of the callback identifier is to enable or enable a means of establishing direct communication between the client and another entity. The callback identifier is specific to the client and, in some cases, specific to a particular topic, such as the transaction associated with the request in this step.

[0149] Step 804 includes submitting the transaction associated with the request to a given miner among the miners for inclusion of the transaction in the blockchain, similar to the process performed for the second request in step 110 of FIG.

[0150] Step 806 includes identifying the given miner to the client. This may be done by a number of techniques, such as providing the client with an endpoint or URL associated with the given miner. This may be sent to the client using the HTTPS transport protocol. In some cases, if the miner is associated with an addressing alias, such as using the bsvalias addressing service described above, this may be provided to the client. In some cases, if the miner is associated with a Miner ID and / or reputation as described above, such information may also be provided to the client. In some cases, this identification step may be performed in conjunction with or after step 812, described below.

[0151] Step 808 includes providing the callback identifier described in step 802 to the miner so that the miner can use it to contact the client directly. In some cases, the callback identifier may point to the payment processor if the payment processor is handling the communication on behalf of the client. Although this illustration is for a scenario in which the callback identifier is to the client, the disclosure is not so limited. For example, the callback identifier could be an encrypted identifier (endpoint) that uniquely identifies the client or the payment processor.

[0152] At step 810, a response is received from the given miner with details regarding the corresponding blockchain transaction generated in response to the transaction request at step 802. This will include a transaction identifier (TxID) for that transaction, which can be provided to the client. In some cases, the identity of the miner at step 806 may be provided to the client once the TxID is received or thereafter. In some embodiments, the response at this step includes an output script, e.g., unspent transaction output (UTXO), associated with the corresponding blockchain transaction, as described above in the first aspect. This transaction identifier (TxID) for the corresponding blockchain transaction is then sent to the client.

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

[0154] 9 relates to a second implementation of the fourth aspect of the disclosure, where the callback identifier associated with the request relates to a channel provided by a channel processor to the client. As mentioned above, the channel processor may be a separate entity that provides channel services to the client or may be the same entity as the payment processor. The following steps of this figure illustrate the embodiment implemented by the channel processor.

[0155] Step 902 illustrates receiving a request associated with a channel from a given client that has subscribed to the channel service, for example as described in UK Patent Application No. 2007597.4 filed in the name of N-Chain Holdings Limited. The request in this embodiment is for creating a channel. However, the channel service can enable other functionality, such as updating APIs associated with existing channels. In most cases, the client's identity may be checked to ensure that the client is registered to use the channel service and the functionality provided thereby. In some embodiments, this may be based on known authentication methods, such as password-protected login authentication or the like during registration. The verification may be based on the received password matching a password in a stored record. In other embodiments, standard PKI techniques based on cryptography or addressing private / public key pairs may also be used to verify a digital signature that may be present in the request received from the client in step 902. In this case, the client's identity may be verified by checking whether a request signed by a private key can be successfully restored or verified using a public key. If the client is not valid or registered, the request is not processed further at this step, or a registration step may be initiated by the channel service.

[0156] At step 904, the requested channel capabilities and / or message capabilities are provided to the client.

[0157] Below are some example schemas and / or formats associated with requests for the creation of channels and / or message functions / APIs, along with example schemas of responses provided by the channel processor.

[0158] 1.1 Channel API: The Channel API may be a JSON-over-HTTP API provided by the Channel Service to help client accounts create and / or manage Channels for peer-to-peer communication.

[0159] In some embodiments, all API endpoints may require authentication. The specific authentication scheme may be determined by the implementation. Common forms include schemes such as OAuth, Basic Authentication, and Bearer Token Methodology. As mentioned above, the Channel API may optionally be protected by an API token provided or generated by the client. Create Channel: Creates a new channel owned by the client, i.e. an account owner for the channel service. Request Format: POST / api / account / <account-id> / channel Authorization:... Content-type:application / json Content-length:... { "public_read":true|false, "public_write":true|false, "sequenced":true|false, "retention":{ "min_age_days":null| <number>, "max_age_days":null| <number>, "auto_prune":true|false } } Response Format: A successful response contains an initial access token. While the account credentials may be used to access the channel API, a token may need to be used to access the messaging API, for which this initial access token belongs to the account owner and its purpose is to read and write to the channel. 201 OK Content-type: application / json Content-length:... { "id":"...", "href":"https: / / example.org / channel / <id>", "public_read":true|false, "public_write":true|false, "sequenced":true|false, "head": <sequence>, "retention":{ "min_age_days":null| <number>, "max_age_days":null| <number>, "auto_prune":true|false }, "access_tokens":[ { "id":"...", "token":"...", "description":"Owner", "can_read":true, "can_write":true } ] } } The Message API allows account owners and associated trading partners (another entity with respect to the channel) to read or write messages to a given channel. To exchange messages, the following Message APIs can be provided as JSON over HTTP APIs to account owners and their trading partners:

[0160] 2.1 Test Channel for New Messages Request Format: HEAD / api / channel / <id> Authorization: <api-token> Response Format: 201 OK ETag: <max-sequence>

[0161] 2.2 Writing messages to a channel Request Format: POST / api / channel / <id> Authorization: <api-token> Content-type:... Content-length:... Response Format: a) Pass A message was put on a channel. 201 Created b) Sequencing failure If the channel was created to be sequenced and the API token associated with the request has not been marked as having read the latest message on the channel, the client may need to retry the write if it is still appropriate. 409 Conflict c) Message too large In embodiments where end-to-end encryption protects all messages, for example 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, in some embodiments it may be useful to limit the maximum size of messages written to a channel; messages larger than this may be rejected by the channel. 413 Payload Too Large d) Exceeding storage quota A quota, which may be set by a service operator in some embodiments, has been exceeded. The client request may be valid, but the storage service is currently unable to fulfill it. 507 Insufficient Storage

[0162] 2.3 Get Message on a Channel Returns all messages from a channel, optionally filtered as unread. Request Format: GET / api / channel / <id>[?unread=true] Authorization: <api-token> The unread query string parameter is optional. Response Format: 201 OK Content-type: application / json Content-length:... ETag: <max-sequence> { "messages":[ { "sequence": <number>, "received": <unix-timestamp>, "content_type":"...", "payload":"hex / base64" } ] }

[0163] 2.4 Mark a message as read or unread: Flag a message as read or unread. Request Format: POST / api / channel / <id> / <sequence>[?older=true] Authorization: <api-token> Content-type: application / json Content-length:... {"read":true|false} The optional older parameter allows the client to <sequence>It allows all messages with a sequence below the path argument to be marked as read in a single call. Response Format: 201 OK

[0164] An access token or API token associated with the requested channel is provided to the client in step 906. In some embodiments, the access token may also be revoked or invalidated if necessary, for example, if permissions have been revised or are no longer required by the client for a given channel. An example schema for this is provided below.

[0165] 3.1 Generate Channel API Token Request Format: POST / api / account / <account-id> / channel / <channel-id> / api-token Authorization:... Content-type: application / json Content-length:... { "description":"...", "can_read":true|false, "can_write":true|false } Response Format: This is the only API call that will return the token value - if it is lost, the token should be deleted and replaced with a new token. 201 Created Content-type: application / json Content-length:... { "id":"...", "token":"...", "description":"...", "can_read":true|false, "can_write":true|false } 1.6 Disable Channel API Token: Request Format: DELETE / api / account / <account-id> / channel / <channel-id> / api-token / <token-id> Authorization:... Response Format: 204 No Content

[0166] Step 908 illustrates the provision of notifications or alerts or other information to be securely received on behalf of the client from another entity (in the embodiment described in Figure 8, this entity is a minor) regarding a particular topic, such as a transaction. This is therefore referred to as a callback notification related to a particular transaction, which may have a TxID as described in Figure 8. This may be a notification of a change in state, in case of an exception occurring with respect to a given transaction or topic for which a channel was created, or some other notification.

[0167] Since notifications are received through channels, the client does not need to be online all the time, and notifications can be delivered asynchronously whenever the client connects or reconnects (online) with the channel processor. In some cases, settings may be provided that can impose a minimum time for a client to remain connected, or a setting may ensure that the client remains connected until all 'unread' alerts or notifications in a channel have been consumed by the client or by a wallet associated with the client. Thus, in some embodiments, a client may be allowed to disconnect once notifications have been consumed or received from a channel by it. For a given client, multiple such channels may be provided, one per topic or transaction.

[0168] In some embodiments, there may be an additional step to detect whether a client is connected to the channel processor, i.e., online, or not, i.e., offline. This may be done by known techniques to ensure that a network connection exists with the client when one or more notifications or messages arrive on the channel.

[0169] Callback notifications or messages placed on a channel for a client are 'pulled' by the client when online to ensure synchronization between messages in the channel and messages delivered to the client.

[0170] When channel notifications arrive, if the client is not connected or offline, they are stored in a memory or cache associated with the channel processor if it is offline. This may be specific to a given client in some embodiments. When the client comes online or when it is detected that it is connected, those notifications are pushed or provided to the client entity. Push notifications may be sent to the client to allow the client to retrieve data or unread messages in a channel. Thus, when the client is offline, messages or notifications are stored by the channel service or channel processor. They are then provided to the client when the client comes online.

[0171] Any type of message can be sent on a channel, but in most cases, when another entity is a miner mining transactions on behalf of a client, the direct communication scenario between the miner and the client is as follows: 1. When the status of a transaction is updated or changed; 2. Receive ad-hoc requests for information from miners.

[0172] In the first scenario, a callback notification is fired whenever the client needs to be informed of a change in state or an exception, e.g. a double-spend of a transaction, or needs to confirm mining, or needs to check the validity or invalidity of a transaction, etc.

[0173] In the second scenario, a client can request status updates from the miner directly using the same channel at specific times, which can be periodic or arbitrary.

[0174] Figure 10 relates to a third implementation of the fourth aspect of the disclosure, where a client is associated with a channel service implemented by the channel processor described in Figure 9. This relates to an embodiment where the callback identifier in Figure 8 is a channel created by the client using the channel service. The following steps in this figure show the embodiment implemented by the client.

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

[0176] The request in this embodiment relates to the creation of a channel that can enable, enable or provide a mechanism for direct communication with another entity, such as a miner.

[0177] At step 1004, one or more functions, e.g., a channel or message function / API, are received from the channel processor to enable the client to create a channel for securing direct communication with another entity. The channel function and message function are described in step 904 of Figure 9 and are received from the channel processor. An access token for the message API and requests as seen in step 906 are also received for the channel.

[0178] Step 1006 depicts sending a request to submit a transaction related to the digital asset to a payment processor. This may be a payment transaction related to a customer of the client or the like. This step is similar to step 208 of Figure 2, as also described above in connection with step 802 of Figure 8. The request is sent via HTTP to an API for the payment processor, and may be a POST request.

[0179] At step 1008, a transaction identifier (TxID) is received from the payment processor, which is based on the response from the given miner, as described in step 810 of FIG.

[0180] In step 1010, the client identifies or knows the miner who sent the TxID to the payment processor in the previous step. This may be based on the API or location or Miner ID and / or reputation associated with the miner, as described above in FIG.

[0181] At step 1012, the API received from the channel processor at step 1004 is then used to create a channel with the miner identified at the preceding step 1010. The received access token can be used to authenticate the other entity and provide access to various functions associated with the channel. In some embodiments, a message API and the access token can be sent to the other entity for communication over the channel. In some embodiments, following the creation of the channel, a handshake protocol can be performed between the client and the miner to establish keys for securing communication over the channel. This can be done using any known method, such as, for example, the Noise protocol framework or the Libsodium key exchange mechanism.

[0182] In step 1014, a response is received from the miner over the channel. This is possible because the other entity, i.e. the miner, has received all the necessary message API and access tokens in the previous steps to communicate directly with the client. The response from the miner will be associated with the specific TxID in step 1008, and therefore communication on the channel will be specific to that transaction identifier. The message can relate to anything related to that TxID. For example, a notification can be sent over the channel to inform the client that the TxID is a double spend of a previous transaction. This may be the case if the transaction is already in the temporary memory pool. Otherwise, if the transaction is included in a block, the message can be associated with a Merkle proof of the transaction's mining.

[0183] Figure 11 relates to a fourth implementation of the fourth aspect of the disclosure, where a client is associated with a channel service implemented by the channel processor described in Figure 9. This relates to an embodiment where the callback identifier of Figure 8 is a channel created by the client using the channel service. The following steps of this figure show an embodiment implemented by a miner.

[0184] At step 1102, a request to mine a transaction is received by a miner from a payment processor, as seen in step 804 of FIG. 8.

[0185] At step 1104, the miner generates a blockchain transaction. This step is similar to step 310 of FIG. 3, and in some embodiments, a hex-encoded raw transaction corresponding to the submitted transaction is generated. Thus, an output script or UTXO is provided that includes a transaction identifier (TxID) associated with the corresponding blockchain transaction created by the miner. The output script (UTXO) of the blockchain transaction can then be added to a memory pool associated with the miner for mining immediately or at a later time.

[0186] Then, in step 1106, this transaction identifier (TxID) of the corresponding blockchain transaction is sent to the client via the payment processor so that the client can have access to the TxID and identify the miner.

[0187] In step 1110, when a client uses the channel service to create a channel for direct communication with a miner, the miner receives access to the channel from the client along with an associated message API and access token.

[0188] At step 1112, the miner checks whether the transaction submitted in step 1102 is a double-spend of a previous transaction. As mentioned above, this can be done by checking if the same transaction exists in an auxiliary or temporary memory pool associated with the miner, or by checking if it has already been mined into the blockchain.

[0189] If that is the case, the miner generates a double spend notification or warning and sends it to the client using the channel. A double spend notification occurs when a miner, who is motivated to maintain his reputation, which can be tracked via his Miner ID, notifies a client that he is attempting to pay a digital asset, e.g., BSV, that was previously paid by the same client (i.e., merchant wallet).

[0190] One version of the example schema could be: request: { "txId":"tx_Id" "callbackURL":" / api / v1 / account / 1 / channel / <channel-id>", "type":"doubleSpend" } response: { "apiVersion":"0.1.1", "timestamp":"2020-07-15T11:40:29.826Z", "minerId": "03fcfcfcd0841b0a6ed2057fa8ed404788de47ceb3390c53e79c4ecd1e05819031", "BlockHash":" 986544449afaec80fcabbbbf08dcd82d392cf68c9a13fe29da1a0ccfnrhr", "BlockHeight":207, "callbackTxId": "6bdbcfab0526d30e8d68279f79dff61fb4026ace8b7b32789af016336e54f2f0", "callbackReason":"doubleSpend" }

[0191] Another version of the example schema for a double payment notification is given below: request: POST / mapi / tx body:whenContent-Typeisapplication / json: { "rawtx":"[transaction_hex_string]", "callBackUrl":"https: / / your.service.callback / endpoint", "callBackToken":"Authorization:<your_authorization_header> ", "merkleProof":false, "dsCheck":true, "callBackEncryption": <parameter> } response: { "apiVersion":"0.1.2", "timestamp":"2020-01-15T11:40:29.826Z", "txid":"6bdbcfab0526d30e8d68279f79dff61fb4026ace8b7b32789af016336e54f2f0", "returnResult":"success", "resultDescription":"", "minerId": "03fcfcfcd0841b0a6ed2057fa8ed404788de47ceb3390c53e79c4ecd1e05819031", "currentHighestBlockHash": "71a7374389afaec80fcabbbf08dcd82d392cf68c9a13fe29da1a0c853facef01", "currentHighestBlockHeight":207, "txSecondMempoolExpiry":0, "conflictedWith":"" }

[0192] At step 1116, a double spend callback notification, or "callbackpayload" as seen above, is sent to the callbackURL, which in this embodiment is the channel to which the miner received access. The channel may be identified by API or location or identifier. The notification is added to the channel using the message API and the access token associated with the channel to which the miner was provided access.

[0193] If the transaction submitted in step 1102 is not a double spend, then in step 1118, the miner proceeds to mine the transaction into a block associated with the blockchain using known techniques for mining, some of which are described in the Background section of this application.

[0194] The miner then generates a proof of inclusion of the transaction in the block, step 1120. In some embodiments, the proof may be a Merkle tree proof, which is a known authentication data structure organized as a tree. A hash of each data block is stored in a node on the base layer or leaf, and every internal node of the tree or branch contains a cryptographic hash calculated from the hashes of its two child / sibling nodes. The top node of the tree, the Merkle root, uniquely identifies the data set from which the tree was built. Thus, Merkle trees allow for efficient proof of inclusion, where a miner or prover node indicates to a submitter or verifier node that a data block is part of an authentication data set by sending them a proof with an audit path. The audit path contains the node hashes necessary to recalculate the Merkle root without the submitter having to reveal the entire data set. In Bitcoin SV, transactions included in a block are stored in a Merkle tree.

[0195] An example schema could be: request: { "txId":"tx_Id" "callbackURL":" / api / v1 / account / 1 / channel / <channel-id>", "type":"merkleproof" } response: { "apiVersion":"0.1.1", "timestamp":"2020-07-15T11:40:29.826Z", "minerId": "03fcfcfcd0841b0a6ed2057fa8ed404788de47ceb3390c53e79c4ecd1e05819031", "BlockHash": "986544449afaec80fcabbbbf08dcd82d392cf68c9a13fe29da1a0ccfnrhr", "BlockHeight":207, "callbackTxId": "6bdbcfab0526d30e8d68279f79dff61fb4026ace8b7b32789af016336e54f2f0", "callbackReason":"" }

[0196] Another version of the example schema for a Merkle proof notification is given below: request: POST / mapi / tx body:whenContent-Typeisapplication / json: { "rawtx":"[transaction_hex_string]", "callBackUrl":"https: / / your.service.callback / endpoint", "callBackToken":"Authorization:<your_authorization_header> ", "merkleProof":true, "dsCheck":false, "callBackEncryption": <parameter> } response: { "apiVersion":"0.1.2", "timestamp":"2020-01-15T11:40:29.826Z", "txid": "6bdbcfab0526d30e8d68279f79dff61fb4026ace8b7b32789af016336e54f2f0", "returnResult":"success", "resultDescription":"", "minerId": "03fcfcfcd0841b0a6ed2057fa8ed404788de47ceb3390c53e79c4ecd1e05819031", "currentHighestBlockHash": "71a7374389afaec80fcabbbf08dcd82d392cf68c9a13fe29da1a0c853facef01", "currentHighestBlockHeight":207, "txSecondMempoolExpiry":0, "conflictedWith":"" }

[0197] In step 1122, the miner sends a proof of inclusion attestation of its inclusion of the transaction in the blockchain directly to the client using the channel to which it has access, so that the client or payment processor does not need to run a copy of the blockchain or search the blockchain to find the transaction.

[0198] 12, an exemplary simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. For example, the computing device 2600 may be configured to be used as one or more components of the illustrated DBMS, or the computing device 2600 may be configured to be a client entity associated with a given user that makes database requests to a database managed by the DBMS of FIG. 12. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 12, the computing device 2600 may include one or more processors (collectively labeled 2602) with one or more levels of cache memory and a memory controller that may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and persistent storage 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used for storing information such as details related to transactions and blocks as described in this disclosure. The processor(s) 2602 may be used to provide the steps or functions of any of the embodiments described in this disclosure.

[0199] The processor(s) 2602 may also be in communication with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0200] Bus subsystem 2604 may provide a mechanism that allows various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is shown generally as a single bus, other embodiments of the bus subsystem may utilize multiple buses.

[0201] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from and sending data to other systems separate from the computing device 2600. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can send data to and receive data from the device while at a remote location, such as a data center.

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

[0203] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as, for example, an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as, for example, a liquid crystal display, a light emitting diode (LED) display, or a projection or other display device. In general, 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. The one or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications that perform the described processes and variations therein, when such interaction may be appropriate.

[0204] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) that, when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure 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 also 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 of programs and data. The persistent storage 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 Blue-Ray) drives 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 this disclosure, as well as data related to transactions and blocks as described in this disclosure.

[0205] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, lighting connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to receive fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through the ports that connect 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 shown in FIG. 12 is intended as merely one specific example for purposes of illustrating a preferred embodiment of the device. Numerous other configurations are possible having more or fewer components than the system shown in FIG. 12.

[0206] List of Example Embodiments The present disclosure will now be described based on the following sections relating to the above aspects, which are provided herein as exemplary embodiments to better explain, describe, and understand the claimed aspects and embodiments.

[0207] Item 1. A computer-implemented method for providing payment services to one or more clients for transactions associated with a blockchain, the method being performed by a payment processor, the method comprising: receiving a request from a given client among the one or more clients, the request being for submitting a transaction related to a digital asset to a blockchain, the request being associated with a callback identifier to enable direct communication between the given client and another entity regarding the transaction; submitting the transaction associated with the request to a given miner among a plurality of miners for inclusion of the transaction in the blockchain; identifying the given miner to the client; providing the callback identifier to the miner; having In response to receiving a response from the given miner regarding a blockchain transaction corresponding to the request, the method further comprises: enabling or processing at least one callback notification for the client regarding the corresponding blockchain transaction provided by the miner, the callback notification being based on the callback identifier associated with the request; A method comprising:

[0208] Clause 2. The method of clause 1, wherein the received response from the miner is associated with a transaction identifier (TxID), and the method further includes a step of sending the transaction identifier (TxID) of the corresponding blockchain transaction to the client.

[0209] Clause 3. The method of clause 1 or 2, wherein the received response is an output script associated with the blockchain transaction, the output script being an unspent transaction output (UTXO) associated with a memory pool for the miner, the UTXO including the transaction identifier (TxID) of the blockchain transaction.

[0210] Item 4. The payment processor is implemented as a Representational State Transfer (REST) ​​endpoint for the one or more clients, and the method further comprises: receiving the request from the client using a HyperText Transfer Protocol Secure (HTTPS) transmission protocol format; converting the request into a remote procedure call (RPC) format and sending the RPC to the miner; receiving a response from the miner in an RPC format related to a corresponding blockchain transaction; converting the response for transmission to the client using the HTTPS transmission protocol; The method of any one of claims 1 to 3, further comprising providing an application programming interface (API) gateway associated with the payment processor for executing the above.

[0211] Clause 5. The method of any one of clauses 1 to 4, comprising verifying the identity of the given miner, the verification being based on a digital signature associated with the given miner or based on an identifier for the given miner, the identifier optionally being associated with a reputation indicator for the given miner.

[0212] Clause 6. The method of any one of clauses 1 to 5, wherein the callback notification relates to a notification of a double spend of the transaction submitted by the given client, or the callback notification relates to a proof of inclusion in the blockchain of the transaction submitted by the given client.

[0213] Clause 7. The method of any one of clauses 1 to 6, wherein the callback identifier is a location of a channel associated with the client, or the callback identifier is a Universal Resource Identifier (URI) of the client.

[0214] Clause 8. The method of any one of clauses 1 to 7, further comprising providing the given miner with access to the channel, the providing step including providing the miner with a channel identifier or location of the channel associated with the request and one or more access tokens associated with the channel.

[0215] Item 9. A computer-implemented method of implementing a channel service for one or more clients, the method being performed by a channel processor, the method comprising: receiving a request from a given client of the one or more clients, the request being for 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 over the channel, the one or more functions comprising: channel capabilities or procedures relating to said channel for the transmission of data; and / or A message function or procedure relating to data transmitted using said channel; and issuing one or more access tokens for the channel, the one or more access tokens configured for secure communication with another entity over the channel; storing and / or providing, for the given client, one or more notifications associated with the channel; The method comprising:

[0216] Clause 10. The method of clause 9, wherein the one or more functions are application programming interfaces (APIs) published or provided to the given client, the APIs including a channel API for the channel and a message API for data associated with the channel, and the access token is an API token specific to the channel or a given message.

[0217] Clause 11. The method of clause 9 or 10, wherein the step of providing access to one or more functions includes providing a JavaScript® Object Notation (JSON) over Hypertext Transfer Protocol (HTTP) API to enable creation and / or management of one or more channels.

[0218] Clause 12. A 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 miner, another entity that communicates directly with the given client via the channel.

[0219] Clause 13. The method of clause 12, wherein the callback notification is for notification of a double-spend for a transaction submitted by the given client.

[0220] Item 14. The callback notification is accompanied by a return payload on the channel provided by the miner, the return payload containing the following data: - The transaction identifier (TxID) of the blockchain transaction that was double-spent, and, optionally, - a service endpoint for a payment processor that submitted the blockchain transaction; and The method according to claim 13, comprising:

[0221] Clause 15. The method of clause 12, wherein the callback notification is regarding proof of inclusion of a transaction submitted by the given client in the blockchain.

[0222] Item 16. The callback notification is accompanied by a return Merkle proof on the channel provided by the miner, the return Merkle proof including the following data: - The transaction identifier (TxID) of the blockchain transaction to which the Merkle proof pertains; and - a block header of a block in which the blockchain transaction is included; - an array of sibling hashes for said transaction identifiers (TxIDs); Item 16. The method according to item 15, comprising:

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

[0224] Clause 18. A method according to any one of clauses 9 to 17, wherein data relating to the one or more callback notifications is provided or pulled from the channel when the client is online or communicatively connected to the channel processor.

[0225] Clause 19. The method of any one of clauses 9 to 18, wherein the channel processor is or includes a payment processor, and the method includes the method of any one of clauses 1 to 8 performed by the payment processor.

[0226] Item 20. A computer-implemented method for processing transactions associated with a blockchain, the method being executed by one or more processors associated with a client, the method comprising: transmitting a channel request for a channel service to be executed by the channel processor, the request pertaining to the creation of a channel for communication with another entity; obtaining access from the channel service to one or more functions that enable direct communication between a given client and the other entity, the one or more functions comprising: Channel functions or procedures relating to the channel for the transmission of data, and / or A message function or procedure relating to the data transmitted using the channel; and obtaining, from the channel service, one or more access tokens that enable secure communication with the other entity; sending a request to a payment processor performing payment services to submit a transaction related to a digital asset to the blockchain; obtaining from the payment processor a transaction identifier (TxID) of a blockchain transaction corresponding to the submitted transaction; identifying a miner associated with the corresponding blockchain transaction based on a response from the payment processor; creating a given channel for communication with the identified miner using one or more channel capabilities received from the channel processor; sending the one or more access tokens associated with the given channel to the miner; receiving at least one callback notification associated with the given channel, the notification relating to data on the given channel provided by the miner related to a blockchain transaction; The method comprising:

[0227] Clause 21. The method of 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 queued data or messages on the given channel.

[0228] Clause 22. The method of clause 20 or 21, wherein data relating to the callback notification is pulled from the given channel when the client is online or communicatively connected to the channel processor.

[0229] Clause 23. The method of any one of clauses 20 to 22, wherein the one or more functions are application programming interfaces (APIs) for a given client, the APIs including a channel API for enabling 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 the given channel and / or write data to the given channel, and the access token is an API token specific to a given channel or a given message.

[0230] Clause 24. A method according to any one of clauses 20 to 23, wherein the channel request is a HyperText Transfer Protocol Secure (HTTPS) transmitted GET request to the channel processor and the request to the payment processor is a HyperText Transfer Protocol Secure (HTTPS) transmitted POST request to the payment processor.

[0231] Item 25. The method further comprises: providing a client endpoint; providing at least one client addressing key associated with said client; obtaining a minor endpoint; obtaining at least one minor addressing key associated with said minor; exchanging one or more handshake messages using the given channel based on the client addressing key and the minor addressing key; deriving a shared secret key based on the handshake result or pattern; having any communication using the given channel is encrypted based on the shared secret key; 25. The method according to any one of items 20 to 24.

[0232] Clause 26. The method of clause 25, wherein the client endpoint is a HyperText Transfer Protocol (HTTP) Application Programming Interface (API) endpoint, and the client endpoint is delivered using HTTP Secure (HTTPS).

[0233] Clause 27. The method of clause 25, wherein the client endpoint is a universal resource location (URL) included in messages from the given client sent using the given channel.

[0234] Clause 28. The method of 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 machine-readable resources accessible from a defined or well-known location, the machine-readable resources including one or more functions related to the client, and the alias is associated with an asymmetric cryptographic key pair for authentication.

[0235] Item 29. A computer-implemented method for processing transactions associated with a blockchain, the method being performed by one or more processors associated with a miner among a plurality of miners, the plurality of miners being communicatively coupled to at least one payment processor implementing a payment service for a given client, the method comprising: receiving a request from the payment processor to submit a transaction to the blockchain; generating a blockchain transaction corresponding to the request; sending an output script (UTXO) related to the blockchain transaction to the payment processor, the output script including a transaction identifier (TxID) associated with the corresponding blockchain transaction; receiving access to a channel that enables direct communication with the given client; obtaining a message function or message API for providing or writing data related to a callback notification on the channel based on an access token associated with the channel, the data being related to the corresponding blockchain transaction; The method comprising:

[0236] Clause 30. Based on a determination that the corresponding blockchain transaction is a double-spend of a previous transaction submitted by the client, the method further includes providing a return payload, the return payload including the following data: - The transaction identifier (TxID) of the given blockchain transaction that is a double spend, and, optionally, - a service endpoint of the payment processor that submitted the given blockchain transaction; and 30. The method of claim 29, comprising:

[0237] Item 31. In response to mining the corresponding blockchain transaction into a block, the method further includes providing a return Merkle proof supporting inclusion of the transaction in the block, the return Merkle proof comprising the following data: - a transaction identifier (TxID) of a blockchain transaction to which the Merkle proof pertains; and - a block header of said block; - an array of sibling hashes of the transaction identifiers; and 30. The method of claim 29, comprising:

[0238] Item 32. The method further comprises: Obtaining a client endpoint; obtaining at least one client addressing key associated with said client; providing a minor endpoint; providing at least one minor addressing key associated with a payment processor; exchanging one or more handshake messages using the channel based on the client addressing key and the minor addressing key; deriving a shared secret key based on the handshake result or pattern; having any communication using said channel is encrypted based on said shared secret key; 32. The method according to any one of items 29 to 31.

[0239] Clause 33. A computing device having 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 described in any one of clauses 1 to 8, the computing device associated with a payment processor.

[0240] Clause 34. A computing device having a processor and a memory, the memory including executable instructions which, when executed by the processor, cause the device to perform a computer-implemented method according to any one of clauses 9 to 19, the computing device being associated with a channel processor.

[0241] Clause 35. A computing device having a processor and a memory, the memory including executable instructions which, 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 associated with a client.

[0242] Clause 36. A computing device having 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 as recited in any one of clauses 29 to 32, the computing device being associated with a minor.

[0243] Clause 37. A payment processor communicatively coupled to at least one client and at least one miner via a wireless communication network, the payment processor implemented in accordance with the computing device of clause 33; a client communicatively coupled to the payment processor via the wireless communications network and capable of communicating with at least one customer, the client being implemented according to the computing device of clause 35, the client being communicatively coupled via the wireless communications network to a channel processor implemented according to the computing device of clause 34; A plurality of miners communicatively coupled to the payment processor via the wireless communication network, each miner implemented according to the computing device of clause 36; A computer system having:

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

[0245] It should be noted that the above-mentioned aspects and embodiments are illustrative rather than limiting of the present disclosure, and that those skilled in the art can design numerous alternative embodiments without departing from the scope of the present disclosure, which is defined by the appended claims. In the claims, any signs placed in parentheses shall not be construed as limiting the claims. The words "comprises" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "comprises or consists of" and "comprising" means "comprises or consists of". The reference of an element in the singular does not exclude the reference of the plural of such elements and vice versa. The present disclosure can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.< / parameter> < / parameter> < / sequence> < / sequence> < / id> < / number> < / id> < / id> < / id> < / number> < / number> < / sequence> < / id> < / number> < / number> < / numeric> < / alphanumeric> < / alphanumeric> < / integer> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric>

Claims

1. 1. A computer-implemented method for processing transactions associated with a blockchain, the method being executed by one or more processors associated with a client, the client being communicatively coupled to at least one payment processor that performs payment services for the client, the method comprising: sending a first request to a payment processor of the at least one payment processor, the request relating to one or more fee quotes for mining a transaction, the transaction relating to a digital asset payment from a customer; in response to receiving one or more fee quotes from the payment processor, selecting a fee quote from among the one or more received fee quotes; The method comprising:

2. requesting and / or processing the digital asset payment from the customer, the request being associated with the selected fee quote; sending a second request to the payment processor to submit a given transaction related to the digital asset payment from the customer to the blockchain, the submission being based on the selected fee estimate for mining the given transaction; Obtaining a transaction identifier (TxID) of a blockchain transaction corresponding to the submitted transaction; 2. The method of claim 1, comprising:

3. The method of claim 2 , wherein the given transaction in the second request comprises a batch of multiple transactions.

4. sending a status query associated with the obtained transaction identifier; Obtaining a status result of the blockchain transaction corresponding to the transaction identifier; 3. The method according to claim 1 or 2, comprising the steps of:

5. The method of claim 1 or 2, wherein the client includes or is communicatively coupled to the at least one payment processor.

6. The method of claim 1 or 2, wherein the first request and / or the status query is an HTTPS GET request and the second request is an HTTPS POST request.

7. 3. The method of claim 1, wherein the step of selecting a commission quote comprises averaging the obtained commission quotes and selecting a commission quote based on the average.

8. 3. The method of claim 1, wherein the step of selecting a fee quote comprises determining a maximum value of fee quotes among the obtained fee quotes and selecting a fee quote based on the maximum value.

9. The method of claim 1 or 2, wherein data relating to the first and / or second requests and / or the status query is provided in a JavaScript Object Notation (JSON) object format.

10. 3. A computing device having a processor and a memory, the memory including executable instructions which, upon execution by the processor, cause the device to perform a computer-implemented method as claimed in claim 1 or 2, the computing device being associated with a client.

11. a payment processor communicatively coupled to at least one client and at least one miner via a wireless communication network, the payment processor optionally having an API converter for converting HTTPS requests from the client into RPC requests to the miner, and vice versa; a client communicatively coupled to the payment processor via the wireless communication network and capable of communicating with at least one customer, the client implemented in accordance with the computing device of claim 10; a plurality of miners communicatively coupled to the payment processor via the wireless communication network; A computer system having:

12. 10. A computer readable storage medium having executable instructions stored thereon, the executable instructions, when executed by a processor of a computer, causing the computer to perform a method according to any one of claims 1 to 9.

Images