COMPUTER IMPLEMENTED SYSTEM AND METHOD

Abstract

In a first aspect, the present disclosure proposes a method, apparatus, and system for implementing a payment service that allows transactions related to clients to be written or stored on a distributed ledger, i.e., a blockchain. The payment service is implemented as an API that one or more clients can access to process digital asset payments related to each client. The first aspect includes obtaining mining fee quotes from multiple miners for the clients and processing requests to submit transactions to a blockchain based on a selected fee quote. In a second aspect, the present disclosure proposes a method, apparatus, and system for requesting a transaction related to a digital asset payment to be mined on a blockchain based on a digital asset payment between a client (payer) and the client's customer (payee). The request is associated with a selected fee quote from the fee quotes received in the above aspect and / or a service level associated with the selected fee quote. In a third aspect, the method includes creating, processing, and mining a blockchain transaction related to a client by a miner based on the miner meeting a selected fee quote from the client, as described in the above aspect.

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, that 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, 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 a first aspect, the present disclosure proposes a method, apparatus and system for implementing a payment service that allows transactions related to a client to be written or stored in a distributed ledger, namely a blockchain. The payment service is implemented as an API that one or more clients can access to process digital asset payments related to the respective client. The first aspect includes obtaining mining fee quotes from multiple miners for the client and processing a request to submit a transaction to the blockchain based on a selected fee quote.

[0010] In a second aspect, the present disclosure proposes a method, apparatus and system for requesting a transaction related to a digital asset payment to be mined in a blockchain based on a digital asset payment between a client (payer) and a customer (payee) of the client, the request being associated with a selected fee quote among the fee quotes received in the above aspect.

[0011] In a third aspect, the method includes creating, processing, and mining, by a miner, blockchain transactions associated with a client based on the miner meeting a selected fee quote from the client, as described in the above aspect.

[0012] 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]

[0013] 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] 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

[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 for mining the transaction from each miner among the multiple miners. This step is performed in response to a first request from a client for a mining fee quote associated with mining the transaction. In some embodiments, the first request from the client may be for a fee quote for mining a single transaction or for one or more fee quotes for mining multiple transactions. In some embodiments, when there are multiple transactions, the payment processor may be associated with a separate API or endpoint for receiving or handling or processing multiple requests associated with two or more (multiple) transactions together. Such an endpoint may also process single or separate transactions. In other embodiments, the same endpoint, i.e., the aforementioned API associated with the payment processor, is used for single and multiple transactions. Thus, the fee quotes obtained from the one or more miners may be (i) a fee quote obtained from each miner for a single transaction, (ii) multiple separate fee quotes from each miner, one for each of the multiple transactions, (iii) a single fee quote applied to each of the multiple transactions, or (iv) a single consolidated fee quote covering mining all of the multiple transactions requested by the client in the first request. In some embodiments, the miners are nodes, 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, where Bitcoin Satoshi's Vision (BSV) is the cryptocurrency or digital asset being bought, sold or transferred, the miners may be referred to as BSV nodes. The method of the first aspect includes providing the obtained fee quote to the client.In some embodiments, the fee estimate relates to the current fee collected or charged by miners for mining a transaction into the blockchain, regardless of what the transaction relates to or the parties involved. In other embodiments, the fee estimate may be adjusted based on a given transaction, which may be identified in the request. In some embodiments, the payment processor may provide all received fee estimates to the client, or may provide one or more recommended fee estimates to provide to the client among the obtained fee estimates.

[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 related to or including a selected fee quote among the obtained fee quotes, 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. In some embodiments, as described above, the request from the client may be to submit multiple transactions rather than a single transaction. This is advantageous where the client may be a merchant entity that processes or handles a large number of transactions within any given period of time, which may be dynamically defined or may be predefined to be minutes, hours, or days. This advantageously allows seamless scalability associated with the blockchain network according to the workload / performance requirements of the client, and may be based on the volume of transactions and / or customers handled by the client. When multiple transactions exist, the payment processor may in some embodiments be associated with separate endpoints for submitting multiple transactions. In other embodiments, the same API endpoint for the payment processor is used for requests from the client to submit multiple transactions as well as single transactions.

[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.

[0023] In some embodiments, upon obtaining the fee quotes from the miners, the method of the first aspect includes classifying the obtained fee quotes into multiple service levels or service categories by the payment processor. In some embodiments, this may be based on the fee quotes obtained from each miner for a single transaction or for a batch of multiple transactions. For example, if the obtained fee quote is within a dynamically set or predefined range, a particular service level is assigned to a given miner. In some embodiments, this service level may be based on a transaction fee (e.g., this may be a fee quoted by the miner) and a relay fee. The relay fee is the lowest possible fee for a given miner to consider validating a transaction and subsequently relaying it to a peer node in the blockchain network. In some cases, both of these fees may be the same. In most cases, the relay fee will be lower than the quoted transaction fee from a given miner. In some blockchains, the fee quoted by the miner is a set or default transaction fee that typically remains the same for any transaction. In some embodiments, the relay fee may be known and / or a common, i.e., default, relay fee for multiple miners. As mentioned above, in most cases this relay fee is less than the transaction fee, and sometimes it can even be the same as the transaction fee.

[0024] A particular service level among multiple possible service levels assigned to a fee quote obtained from a miner may, in some embodiments, be based on a priority associated with the transaction(s) to be mined into a block. In some embodiments, a particular service level may also be based on the degree of double-spend protection provided by the miner to ensure that malicious attempts to spend further funds / digital assets associated with the same transaction are rejected. Thus, a higher service level may indicate a higher priority transaction that may need to be mined within a short period of time, e.g., less than a few minutes, i.e., within 15-20 minutes, and / or with better double-spend protection. A lower service level may be associated with a longer mining time, e.g., within 24-48 hours, and / or with no double-spend protection for transactions not mined by a given miner. In some embodiments, transaction priority may be given by a client, and a service level is associated with this client for all transactions based on the client requirements. In some embodiments, double-spend protection may be associated with the ability to store transactions not mined by a given miner in an auxiliary memory pool so that a check for double-spends can be performed.

[0025] In some embodiments, the determination of the service level may be based on fixed values ​​and rules associated with a configuration record or file entry associated with the payment processor. In such cases, these values ​​for assigning the service level may be set in the payment processor. In other embodiments, it may be possible to add new values ​​or rules or modify the configuration record to further define the features associated with a given service level. This may be in addition to, or in some cases may be instead of, one or more of the transaction priority and double-spend protection associated with a given service level discussed above. This may be compared to the obtained fee quote to assign the service level.

[0026] In some embodiments, the transaction fee associated with a given service level may be dynamically assigned or may be predefined as a default recommended or selected fee by the payment processor for that service level. This recommended or selected fee may then be sent to the client along with the service level indicator provided by the given miner in some embodiments. In some embodiments, the fee associated with each service level may already be known or agreed to by the client. For example, the service level based on the client requirements and the selected fee associated with the client for the transaction may be pre-agreed in some cases. This may be based on an external service level agreement or may be set when the client registers to use the services or features offered by the payment processor. In some embodiments, the service level and fee may be selected by the client for each transaction or, in the case of a batch of multiple transactions, for that batch of transactions.

[0027] In some embodiments, the service level pre-assigned or recommended or selected by the payment processor may be based on one or more service requirements received from the client as part of the first request, in some embodiments, the service level is provided or specified to the miner along with the selection / recommended quote in the request to create a blockchain transaction.

[0028] Advantageously, categorizing mining fees based on a defined set of service levels that can be associated with each miner ensures transparency and standardization of the amount of mining fees applied to mine a transaction, as well as transparency of the performance for a given miner for mining a transaction at the assigned service level. As the use of blockchains in many applications increases, the number of transactions presented or submitted to the blockchain increases, so such categorization of a defined number of service levels ensures transparency and further visibility of fees for expected services, along with the certainty that the required level of protection against double spending is provided by the miner. This is important to ensure seamless scalability with the exponential increase in the number of clients, the number of miners, and the number of transactions per client / miner handled by the payment processor associated with the blockchain. Currently, with any existing miner fee mechanism, there is no guarantee or visibility that the quoted fee rate will actually provide 0-conf safety.

[0029] Once classified by the payment processor based on default or defined or known relay fees, such classification may in some embodiments be used or applied to miners in future transactions. Additionally, such classification may also advantageously encourage miners to submit better or more competitive fee quotes for mining transactions, allowing them to be associated with different or better service levels suited to a given client, while still insisting on mining transactions that meet the initial fee quote for mining.

[0030] Also, the service level classification advantageously allows clients and miners to differentiate transactions based on service level. Currently, there is no mechanism to differentiate transactions and price different types of transactions for different clients at different rates. In addition, the above classification based on service level performed by the payment processor advantageously allows such classification to be implemented without requiring changes to the configuration of the mining nodes. This is because the proposed mechanism associated with service level externalizes the fee assessment to the payment processor rather than to the miner or validator nodes using the payment processor's API, and is therefore easy to implement and apply to clients and miners, and greatly aids the scalability of blockchains, such as the BSV blockchain.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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 the miner for storing transactions not mined by the given miner in their respective auxiliary memory pools. As mentioned above, where fee quotes are categorized into multiple service levels, auxiliary memory pools are associated with miners that offer double-spend protection.

[0037] In some embodiments, as described above, requests from a client may query the status of multiple transactions in a batch together, rather than a single transaction each time. Similar to submitting multiple transactions to the blockchain for mining, querying multiple transactions together in a single status query request is advantageous, especially when the client may be a merchant entity that processes or handles a large number of transactions, and is submitting multiple transactions to be processed at once. This advantageously allows the system to seamlessly scale according to client requirements, and may be based on the volume of transactions and / or customers handled by the client. When there are multiple transactions, the payment processor may in some embodiments be associated with separate endpoints for querying multiple transactions. In other embodiments, the same endpoint to the payment processor is used for requests from clients to query single and multiple transactions.

[0038] 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.

[0039] 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:

[0040] 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, implemented by a client, i.e., a merchant, includes 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 or transactions to be obtained from multiple miners via the payment processor. As described above, the obtained fee quote can relate to mining any transaction or be specific to a given transaction relating to a digital asset payment from a customer. As described above, the first request may also indicate a service level required for mining.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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 multiple transactions, or may be specific to a particular transaction between the client and the customer.

[0048] 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.

[0049] 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.

[0050] 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 a remote procedure call (RPC). This is advantageous when the miner is configured to communicate wirelessly via RPC, 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.

[0051] 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.

[0052] The 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 associated with 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 a 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 computer system also has a plurality of miners, each of which is communicatively coupled to the payment processor via a wireless communication network, whereby each of which is implemented according to the third aspect.

[0053] 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.

[0054] 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.

[0055] 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:

[0056] 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.

[0057] 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.

[0058] Step 102 illustrates receiving a first request from a client for a mining fee quote associated with mining a transaction in a blockchain. As previously mentioned, 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 previously mentioned, 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.

[0059] 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.

[0060] 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 for targeting or contacting the correct or intended payment processor or REST endpoint, in some embodiments, based on an agreement that the client may have with, e.g., one or more third parties running a payment processor.

[0061] 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.

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

[0063] The JSON object FeeQuote returned by each miner is shown below. Although an example is shown for a single transaction, 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 ]

[0064] 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:

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] As mentioned above, the second request from the client may in some embodiments be a request to submit multiple transactions. The request for submitting multiple transactions may be sent to the same payment processor API or another endpoint associated with the payment processor. All endpoints associated with the payment processor will be known to or provided to the client. The selected fee quote in the case of multiple transactions may be either one associated with mining all of the multiple transactions, i.e., the selected fee is 10 satoshis for mining 10 transactions in a batch of multiple transactions, or one associated with a selected fee for mining each of the multiple transactions at the selected fee quote, i.e., the selected fee is 1 satoshi / transaction for mining each transaction in the batch of 10 transactions.

[0074] In the case of multiple transactions, the body of the second request may be in the form of an array of raw transactions. This endpoint is used to send multiple raw transactions to the miner for inclusion in the next block that the miner creates.

[0075] An example of the request body format is shown below: POST / mapi / txs [ "010000000135ff04d97f7f5d214b66dcc401cee7967c.......", "0100000001569c0e1df6cdbbc99bdfbc25dc153ce5e........", "etc..." ]

[0076] An example response could be: { "apiVersion":"string", "timestamp":"string", "errorCount":"integer (count of where txn returnResult <> success)", "txs":[ { "txid":"string", "minerid":"string|null", "returnResult":"string", "resultDescription":"string", "currentHighestBlockHash":"string", "currentHighestBlockHeight":"integer", "txSecondMempoolExpiry":"string", "confirmations":"integer (0 for unconfirmed)" } ] }

[0077] 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.

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

[0079] As mentioned above, in some embodiments, the selected fee quote may be based on service level, with the obtained fee quotes being categorized by the payment processor into multiple service levels.

[0080] In some embodiments, the mining fees and features / functionality associated with each service level may be predefined by the payment processor. A given client may then be assigned a service level and associated mining fee (selected fee quote) based on the client's requirements. The client requirements may be based on the type of transactions the client handles. The service levels may be pre-assigned or pre-agreed upon, for example, based on an external service level agreement. Thus, the pre-assignment may be based on the priority associated with the transaction and the level of protection against double-spending provided by the miner(s) that meet the selected fee quote / service level.

[0081] Thus, the fees associated with the service level of the mined transaction may be predetermined by the payment processor and agreed with the client. If a service level or fee is not selected by the client, details of the acquisition fee quotes broken down into multiple service levels (each associated with a respective fee) may be provided to the client for selection.

[0082] Alternatively, the payment processor may recommend a service level and associated fee as a selected fee estimate. Such a recommendation of a service level may be based on learned data and statistics from previous transactions associated with that client. That is, in some cases, the payment processor provides recommendations based on input from the client.

[0083] As mentioned above, in some embodiments, a service level is assigned to a miner based on the obtained fee estimate and the lowest fee the miner can receive for mining one or more transactions, i.e., the relay fee. Thus, different fees can be advantageously applied for different transaction types or use cases. The transaction type or service requirements can be obtained by the client in some embodiments.

[0084] The service level may also be determined immediately by the payment processor based on knowledge of transaction fee estimates obtained from miners and knowledge of relay fees for the miner. This allows the payment processor to categorize the fees, and optionally even a recommended fee for the client, regardless of whether the client has indicated a minimum service level. Once the payment processor has obtained the fees, it may inform the client of the service level that can be expected from the selected / recommended fees for the transaction. These may include attributes related to that service level.

[0085] The table below provides an example of a matrix that may be used by a payment processor to categorize fees into service levels (SL) 0-4 based on relay fees and transaction (txn) fees. The units of fee in this example are expressed in satoshis per byte, but the disclosure is not so limited. It may also be expressed in satoshis per data byte for some transactions. Other digital assets or cryptocurrencies may also be used. This matrix may be stored in a static or dynamic configuration file or entry associated with the payment processor so that service levels can be categorized based on this logic.

[0086] In the example below, two features are considered for service levels: (i) transaction priority and (ii) protection provided against double spending, however, the disclosure is not so limited and service levels can be based on other features and attributes. [Table 2]

[0087] In this example, it is: Service Level (SL) 0, i.e. SL0 - minRelayerfee<0.20 satoshis, does not guarantee that any miner will mine and has no double-spend protection, i.e. no guarantee of service for mining. There is no additional double-spend protection, since the fee does not cover the inclusion of non-mined transactions in the auxiliary memory pool to check for double-spends.

[0088] SL1 - If (minRelayrfee)=<0.20 satoshis and (txnfee)=<0.3 satoshis, then there is low priority and no double-spend protection. That is, the transaction may or may not be mined ahead of other transactions in the mining queue, and thus may not be mined for (say) another 24 hours or so. There is no additional double-spend protection, since the fee does not cover the inclusion of non-mined transactions in the auxiliary memory pool to check for double-spends.

[0089] SL2 - If (minRelayrfee)=0.25 satoshis and (txnfee)=<0.4 satoshis, then it is medium priority and has double-spend protection, i.e. the transaction has priority over some, if not all or most, other transactions in the mining queue and can therefore be mined within a period of (say) 12 to 24 hours or so. There is additional double-spend protection as the fee covers the inclusion of non-mined transactions into an auxiliary memory pool that is used to check for double-spends.

[0090] SL3 - If (minRelayrfee)>=0.25 satoshis and (txnfee)=0.5 satoshis, then it is high priority and has double-spend protection. That is, the transaction has priority over most other transactions in the mining queue and can therefore be mined within a period of (say) 12 hours or so. There is additional double-spend protection since the fee covers the inclusion of non-mined transactions into an auxiliary memory pool that is used to check for double-spends.

[0091] SL4 - txnfee>0.5 satoshis, highest priority, will be mined by all miners, full double-spend protection. That is, the transaction has priority over all other transactions in the mining queue, and can therefore be mined within a period of (say) 2 hours. There is additional double-spend protection, as the fee covers the inclusion of non-mined transactions in an auxiliary memory pool that is used to check for double-spends.

[0092] In this case, the above mentioned JSON object FeeQuotes described in step 104 may also include: [ { #MinerFeeQuote "minerID": <alphanumeric>, #null indicates no minerID "currentHighestBlockHash": <alphanumeric>, "currentHighestBlockHeight”: <alphanumeric>, "timestamp”:<UTC timestamp>, # Fee timeStamp "minerSignature”: <alphanumeric>, #Contains current block hash + block height "minerReputation": <alphanumeric>, #can be null [ { # FeeTypes "feeType":<"SPB"||"SPDB">, #Satoshis-per-byte,Satoshis-per-data-byte etc. { # currentFee # Fee unit tuple (x satoshis / y bytes) "satoshis":<Unsigned Integer> "bytes":<Unsigned Integer> } "expiry": <integer>, expiry datetime as set by miner "feeOnExpiry”:<Floating Point Number> , #If Expiry is 0, this should be set to CurrentFee "keepInMempoolFee":<Floating Point Number> , #Fee for holding Tx in auxiliary memory pool "mempoolExpiryFee":<Floating Point Number> , #keepInMempoolFeeFee after expiry }, {…} ] { # Service Level "service level”:<Unsigned Integer> "SLDescription”: <string> } "apiVersion”: <numeric>#Commercial API version NN.nn (major.minor version number) },

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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) } ]

[0099] 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.

[0100] If there are multiple transactions associated with the client, submitted together using the same endpoint or using separate endpoints associated with a payment processor, the response body returned to the second request may be in the following JSON format: (outside 1) TIFF0007598368000003.tif48170

[0101] In some embodiments, for multiple transactions submitted in the second request, the response body provides: - Response group header information and transaction level (payload) information - Response reports on the results (or current status) returned for each transaction - The response returns an error count: count(result<>success) - The response returns an error threshold, where X is a configurable parameter that may be predefined or dynamically defined, and if the error count > X, further processing of the transaction is stopped and all of the transactions submitted in the second request are rejected. If a batch of transactions submitted together in a second request is rejected for mining by the miner due to an error count greater than X, an error code may be assigned along with a suitable description of the code.

[0102] The JSON envelope terms are listed below along with a description of their function: [Table 3]

[0103] An example of a payload or message field return is shown below: { "apiVersion":"string", "timestamp":"string", "errorCount":"integer (count of where txn returnResult <> success)", "txs":[ { "txid":"string", "minerid":"string | null", "returnResult":"string", "resultDescription":"string", "currentHighestBlockHash":"string", "currentHighestBlockHeight":"integer", "txSecondMempoolExpiry":"string", "confirmations": "integer (0 for unconfirmed)" } ] }

[0104] 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.

[0105] 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.

[0106] If multiple transactions are submitted by the client in the second request, as described above, in some embodiments, the status of the multiple transactions may be queried by the client in a single query transaction status request rather than sending a separate request for each transaction. The requests to query the status of multiple transactions may be sent to the same payment processor API or may be sent to different endpoints associated with the payment processor. All endpoints associated with the payment processor will be known to or provided to the client. This may be provided when the client registers for services related to the payment processor. As described above, providing the API to the client may use known open API tools such as Swagger.

[0107] If multiple transactions are being queried, the body of the second request may be in the form of an array of transaction identifiers (TxIDs). An example of the request format is shown below: POST / mapi / txs [ "txId", "txId", "etc….." ]

[0108] 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.

[0109] 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:

[0110] 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) } ]

[0111] The 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".

[0112] 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 does not exist - 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.

[0113] If there are multiple transactions associated with the client that should be queried together using the same endpoint or using separate endpoints associated with payment processors, the returned response body may be in the following JSON format: (outside 2) TIFF0007598368000005.tif48170

[0114] In some embodiments, for multiple transactions queried, the response body groups together header information and transaction-level (payload) information. [Table 4]

[0115] An example of a returned payload or message field return is shown below: { "apiVersion":"string", "timestamp":"string", "txs":[ { "txid":"string", "minerid":"string | null", "returnResult":"string", "resultDescription":"string", "currentHighestBlockHash":"string", "currentHighestBlockHeight":"integer", "txSecondMempoolExpiry":"string", "confirmations": "integer (0 for unconfirmed)" } ] }

[0116] 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.

[0117] 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.

[0118] Step 202 depicts sending a first request to a payment processor among at least one payment processor associated with the client to provide the respective payment service. 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. This first request relates to an HTTPS GET getFeeQuote as described in connection with step 102. As described above, the request may be for mining any transaction 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. As described above, in some embodiments, the first request may also include details of the level of service required for one or more transactions to be mined. This may relate to the speed of mining and / or the protection against double spending provided by the miner.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] Referring now to FIG. 8, 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. 8. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 8, 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.

[0143] 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 .

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.). A device that may be connected to the computing device 2600 may include multiple ports configured to receive fiber optic connectors. The device may thus 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. 8 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. 8.

[0150] 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.

[0151] 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 first request from a client related to mining a transaction in a blockchain; sending a request for a fee quote to each miner in a plurality of miners communicatively coupled to the payment processor; obtaining, from each miner, a fee estimate for mining the transaction; providing the obtained fee quotes from the plurality of miners to the client, wherein a selected fee quote for mining the transaction is determined based on the obtained fee quotes; or determining a selected fee quote for mining the transaction for the client based on the obtained fee quote; The method comprising:

[0152] 2. The method of claim 1, wherein the transaction associated with the first request includes a batch of multiple transactions.

[0153] 3. in response to a second request from the client to submit a given transaction related to the selected fee estimate from the obtained fee estimates, sending a request to one or more miners among the plurality of miners to generate a blockchain transaction corresponding to the given transaction; receiving an output script associated with the corresponding blockchain transaction from at least one miner among the plurality of miners that satisfies the selected fee quote; sending a result to the client, the result including a transaction identifier of the blockchain transaction corresponding to the given transaction; 3. The method according to item 1 or 2, comprising the steps of:

[0154] 4. The method of claim 3, wherein the given transaction comprises a batch of multiple transactions.

[0155] 5. The method of any one of clauses 1 to 4, wherein the step of providing the obtained fee estimates further comprises determining a recommended fee estimate based on an average value of the obtained fee estimates or a maximum value among the obtained fee estimates.

[0156] 6. The method of claim 5, further comprising providing the suggested fee quote or providing all of the obtained fee quotes including the suggested fee quote, the suggested fee quote including an identifier.

[0157] 7. The method of claim 5 or 6, wherein the selected fee quote is the same as or different from the recommended fee quote, the different fee quote being either predetermined or arbitrarily selected.

[0158] 8. The method of any one of clauses 1 to 7, wherein the step of determining a selected fee estimate comprises assigning to each of the obtained fee estimates a service level among a plurality of service levels, each service level being associated with a respective selected fee estimate for mining the transaction.

[0159] 9. The method of claim 8, wherein the service level is assigned based on the obtained fee estimates and a minimum relay fee associated with the miner related to each fee estimate. 10. The method of claim 8 or 9, wherein the assigned service level indicates a priority for mining the transaction and / or a level of protection against double-spending associated with the transaction for recommendation fees.

[0160] 11. The method of any one of clauses 8 to 10, wherein the service level for the mined transactions is assigned based on one or more service requirements obtained from the client.

[0161] 12. The method of any one of claims 1 to 11, comprising verifying the identity of a given miner among the plurality of miners, the verification being based on a digital signature associated with the given miner or based on an identifier related to the given miner, the identifier being optionally associated with a reputation indicator for the given miner.

[0162] 13. The method of any one of clauses 1 to 12, comprising the step of authenticating each fee quote obtained from a given miner among the plurality of miners based on a miner signature, the miner signature serving as a commitment from the given miner to mine the transaction for the respective fee quote and, optionally, to reject any conflicting transactions.

[0163] 14. The method of any one of claims 1 to 13, wherein the fee estimates obtained from each miner are provided in a data type, the data type being in a JavaScript Object Notation (JSON) object format.

[0164] 15. The method of any one of clauses 1 to 14, wherein the received output script is an unspent transaction output (UTXO) associated with a memory pool for the at least one miner, the UTXO including the transaction identifier (TxID) of the blockchain transaction.

[0165] 16. In response to a status query associated with a transaction identifier from the client, sending a request to the plurality of miners to obtain a blockchain transaction corresponding to the transaction identifier; obtaining the corresponding blockchain transaction from at least one miner among the plurality of miners; sending a status result related to the acquired blockchain transaction to the client; Item 16. The method according to any one of items 1 to 15, comprising:

[0166] 17. The payment processor is implemented as a Representational State Transfer (REST) ​​endpoint for the one or more clients, the method further comprising: receiving, from the client, the first request, and / or the second request, and / or a status query relating to a given transaction, using a HyperText Transfer Protocol Secure (HTTPS) transmission protocol format; converting each request into a remote procedure call (RPC) format and sending the RPC to one or more miners of the plurality of miners; receiving a response in an RPC format from the one or more miners of the plurality of miners, the response being associated with a corresponding blockchain transaction; converting each response so that it can be sent to the client using the HTTPS transmission protocol; 17. The method of any one of claims 1 to 16, further comprising providing, in association with the payment processor, an application programming interface (API) converter for executing the above.

[0167] 18. 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 implementing payment services for the client, the method comprising: 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, 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:

[0168] 19. 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; Item 19. The method according to item 18, comprising the steps of:

[0169] 20. The method of claim 19, wherein the given transaction in the second request includes a batch of multiple transactions.

[0170] 21. sending a status query associated with the obtained transaction identifier; obtaining a status result of the blockchain transaction corresponding to the transaction identifier; 21. The method according to any one of items 18 to 20, comprising:

[0171] 22. The method of any one of clauses 18 to 21, wherein the client includes or is communicatively coupled to the at least one payment processor configured to implement the method of any one of clauses 1 to 17.

[0172] 23. The method of any one of clauses 18 to 22, wherein the first request and / or the status query is an HTTPS GET request and the second request is an HTTPS POST request.

[0173] 24. The method of any one of clauses 18 to 23, wherein the step of selecting a commission quote comprises determining an average value of the obtained commission quotes and selecting a commission quote based on the determined average value.

[0174] 25. The method of any one of clauses 18 to 24, wherein the step of selecting a fee quote includes determining a maximum value of fee quotes among the obtained fee quotes, and selecting a fee quote based on the maximum value.

[0175] 26. The method of any one of clauses 18 to 25, wherein data associated with the first request and / or the second request and / or the status query is provided in JavaScript Object Notation (JSON) object format.

[0176] 27. 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 that implements payment services for a client, the method comprising: receiving a first request from a payment processor for a fee quote for mining transactions associated with the client; providing a current fee quote associated with the miner for mining the transaction on the blockchain, the current fee quote representing a commitment to mine the transaction at the current fee quote; The method comprising:

[0177] 28. In response to a second request for submitting a given transaction associated with the client to the blockchain based on a selected fee quote, the method further includes: generating a blockchain transaction corresponding to the given transaction based on a determination that the selected fee quote associated with the given transaction satisfies the current fee quote of the miner; generating an output script (UTXO) of the blockchain transaction; adding the generated output script to a memory pool associated with the miner; sending the output script to the payment processor, the output script including a transaction identifier (TxID) associated with the corresponding blockchain transaction; 28. The method according to claim 27, comprising the steps of:

[0178] 29. The method of claim 28, comprising: in response to a request for a status associated with the transaction identifier, returning a result based on a mining status of the corresponding blockchain transaction.

[0179] 30. The method of any one of clauses 27 to 29, wherein the step of providing the current fee quote and / or the step of sending the output script and / or the step of returning the result are implemented as a remote procedure call (RPC).

[0180] 31. The method of claim 30, further comprising sending the RPC from the miner to a node connector, and optionally to a firewall for the plurality of miners, before propagating the RPC to the payment processor for the client over a wireless communication network.

[0181] 32. The method of any one of clauses 27 to 31, further comprising adding an output associated with a corresponding blockchain transaction to a secondary memory pool associated with the miner based on a determination that the selected fee estimate associated with the given transaction does not meet the current fee estimate of the miner.

[0182] 33. The method of any one of clauses 27 to 32, wherein the miner is communicatively coupled to at least one payment processor configured to perform the method of any one of clauses 1 to 9, and the at least one payment processor is associated with or communicatively coupled to a client configured to perform the method of any one of clauses 12 to 19.

[0183] 34. 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 or agreeing to one or more service requirements from a client for transactions to be mined in the blockchain; receiving a first request from a client to mine one or more transactions in a blockchain; sending a request for a fee quote to each miner in a plurality of miners communicatively coupled to the payment processor; obtaining, from each miner, a fee quote for mining the one or more transactions; categorizing the obtained fee estimate into a given service level among a plurality of service levels offered for mining, each service level being associated with a set mining fee; determining a service level for the client based on the one or more received service requirements, the set mining fee associated with the determined service level being a selected fee quote for mining the one or more transactions associated with the client, the determined service level indicating a priority for mining the transactions and / or a level of protection against double spends; The method comprising:

[0184] 35. 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 1 to 17 and clause 33, the computing device being associated with a payment processor.

[0185] 36. 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 as recited in any one of clauses 18 to 26, the computing device being associated with a client.

[0186] 37. 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 27 to 33, the computing device being associated with a minor.

[0187] 38. A payment processor communicatively coupled to at least one client and at least one miner via a wireless communication network, the payment processor optionally associated with an API converter for converting HTTPS requests from the client into RPC requests to the miner and vice versa, the payment processor being implemented according to the computing device of clause 35; a client communicatively coupled to the payment processor via the wireless communication network and capable of communicating with at least one customer, the client being implemented in accordance with the computing device of clause 36; 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 37; A computer system having:

[0188] 39. 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 34.

[0189] 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.< / numeric> < / alphanumeric> < / alphanumeric> < / integer> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / string> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / numeric> < / integer> < / alphanumeric> < / alphanumeric> < / alphanumeric> < / alphanumeric>

Claims

1. 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 first request from a client related to mining a transaction in a blockchain; sending a request for a fee quote to each miner in a plurality of miners communicatively coupled to the payment processor; obtaining, from each miner, a fee estimate for mining the transaction; providing the client with the obtained fee quotes from the plurality of miners; or providing the client with the obtained fee quotations from the plurality of miners, and determining for the client a selected fee quote for mining the transaction based on the obtained fee quotations; The method comprising:

2. The method of claim 1 , wherein the transaction associated with the first request comprises a batch of multiple transactions.

3. In response to a second request from the client to submit a given transaction related to the selected fee estimate from the obtained fee estimates, sending a request to one or more miners among the plurality of miners to generate a blockchain transaction corresponding to the given transaction; receiving an output script associated with the corresponding blockchain transaction from at least one miner among the plurality of miners that satisfies the selected fee quote; sending a result to the client, the result including a transaction identifier of the blockchain transaction corresponding to the given transaction; 3. The method according to claim 1 or 2, comprising the steps of:

4. The method of claim 3 , wherein the given transaction comprises a batch of multiple transactions.

5. 5. The method of claim 1, wherein the step of providing the obtained commission quotes further comprises determining a recommended commission quote based on an average value of the obtained commission quotes or a maximum value among the obtained commission quotes.

6. 6. The method of claim 5, further comprising providing the suggested fee quote or providing all of the obtained fee quotes including the suggested fee quote, the suggested fee quote including an identifier.

7. 7. The method of claim 5 or 6, wherein the selected fee quote is the same as the recommended fee quote or is different from the recommended fee quote, the different fee quote being either predetermined or arbitrarily selected.

8. 8. The method of claim 1, wherein the step of determining a selected fee quote comprises assigning to each of the obtained fee quotes a service level among a plurality of service levels, each service level being associated with a respective selected fee quote for mining the transaction.

9. 9. The method of claim 8, wherein the service levels are assigned based on the obtained fee quotes and minimum relay fees associated with miners related to the respective fee quotes.

10. 10. The method of claim 8 or 9, wherein the assigned service level indicates a priority for mining the transaction and / or a level of protection against double-spending associated with the transaction for recommendation fees.

11. 11. The method of claim 8, wherein the service level for the mined transactions is assigned based on one or more service requirements obtained from the client.

12. 12. The method of claim 1, further comprising verifying the identity of a given miner among the plurality of miners, the verification being based on a digital signature associated with the given miner or based on an identifier relating to the given miner, the identifier being optionally associated with a reputation indicator for the given miner.

13. 13. The method of claim 1, further comprising: authenticating a respective fee quote obtained from a given miner among the plurality of miners based on a miner signature, the miner signature serving as a commitment from the given miner to mine the transaction for the respective fee quote and, optionally, to reject any conflicting transactions.

14. 14. The method of any one of claims 1 to 13, wherein the fee quotes obtained from each miner are provided in a data type, the data type being in a JavaScript Object Notation (JSON) object format.

15. 15. The method of any one of claims 1 to 14, wherein the receiving output script 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 the blockchain transaction.

16. In response to a status query associated with a transaction identifier from the client, sending a request to the plurality of miners to obtain a blockchain transaction corresponding to the transaction identifier; obtaining the corresponding blockchain transaction from at least one miner among the plurality of miners; sending a status result related to the acquired blockchain transaction to the client; 16. The method according to any one of claims 1 to 15, comprising:

17. The payment processor is implemented as a Representational State Transfer (REST) ​​endpoint to the one or more clients, and the method further comprises: receiving from the client, using a HyperText Transfer Protocol Secure (HTTPS) transmission protocol format, a status query relating to the first request, and / or the second request, and / or a given transaction; converting each request into a remote procedure call (RPC) format and sending the RPC to one or more of the plurality of miners; receiving a response in an RPC format from the one or more miners of the plurality of miners, the response being related to a corresponding blockchain transaction; converting each response so that it can be sent to the client using the HTTPS transmission protocol; 17. The method of claim 1, further comprising the step of providing, associated with the payment processor, an application programming interface (API) converter for implementing:

18. 18. 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 according to any one of claims 1 to 17, the computing device being associated with a payment processor.

19. a payment processor communicatively coupled to at least one client and at least one miner via a wireless communication network, the payment processor optionally associated with an API converter for converting HTTPS requests from the client into RPC requests to the miner and vice versa, the payment processor being implemented in accordance with the computing device of claim 18; 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 as a computing device having a second processor and a second memory, the second memory including second executable instructions that, upon execution by the second processor, cause the device to perform a computer-implemented method comprising: sending a first request to a payment processor among the at least one payment processor, the request relating to one or more fee quotes related to mining a transaction, the transaction relating to a digital asset payment from a customer, and in response to receiving the one or more fee quotes from the payment processor, selecting a fee quote from among the one or more received fee quotes; With the client, a plurality of miners communicatively coupled to the payment processor via the wireless communications network, each miner implemented as a computing device having a third processor and a third memory, the third memory including third executable instructions that, upon execution by the third processor, cause the device to perform a computer-implemented method comprising: receiving a first request from a payment processor for a fee quote for mining transactions associated with the client; providing a current fee quote associated with the miner for mining the transaction on the blockchain, the current fee quote representing a commitment to mine the transaction at the current fee quote; Multiple miners that execute the above, A computer system having:

20. 18. 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 17.

Images