Destination addressing associated with distributed ledgers

Abstract

To provide a method, an apparatus, and / or a system associated with transactions for distributed ledgers, such as the Bitcoin blockchain.SOLUTION: In some embodiments, the present disclosure relates to a method for performing payer entity validation upon a request. In other embodiments, the present disclosure relates to a method for performing asynchronous processing of a request sent by a payer entity when a payee entity does not respond.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] The present disclosure relates generally to methods and systems for effectuating transactions associated with a distributed ledger, and in particular to methods for destination addressing for one or more digital wallets. The present disclosure is particularly, but not exclusively, suited to providing a method for effectuating digital asset transfers or payments from a payer to a payer. [Background technology]

[0002] Herein, we use the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referenced herein for convenience and illustrative purposes, but it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are encompassed within the scope of this disclosure. The term "user" here may refer to a human or processor-based resource. The term "Bitcoin" is considered herein to include any protocol derived from or a variation of the Bitcoin protocol.

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

[0004] For a transaction to be written to the blockchain, it must be validated. Network nodes (miners) perform the work to ensure that invalid transactions are rejected by the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must (i) be validated by the first node that receives it, and if the transaction is valid, the node relays the transaction to other nodes in the network; (ii) be added to a new block constructed by miners; or (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 cryptocurrency to another address associated with an input in another transaction. This is often done using a digital cryptocurrency wallet. This digital wallet can be a device, physical media, a program, an application (app) on a mobile device, or a remotely hosted service associated with a domain on a network such as the Internet. The digital wallet stores public and private keys, tracks ownership of assets associated with the user, and can be used to receive or spend the cryptocurrency. The cryptocurrency itself does not reside within the digital wallet. In Bitcoin and cryptocurrencies derived from it, the cryptocurrency is decentralized and stored within a publicly available ledger, or blockchain. There are various types of cryptocurrency wallets known, and a network of such wallets is called an ecosystem, such as the Bitcoin SV (BSV) wallet ecosystem.

[0006] Currently, to effect a user-to-user, i.e., BSV, cryptocurrency payment from Alice to Bob, Alice needs to have a digital wallet associated with her (private and public) cryptographic keys and know Bob's public address to send the cryptocurrency to, i.e., Bob's digital wallet address. Public addresses associated with an entity, here a digital wallet, are typically generated automatically by an address generator. These public addresses are a string of numbers in a specific format recognized by the cryptocurrency network and used for transactions. For example, they may be Bitcoin addresses for a BSV-based cryptocurrency network. This can be referred to as the public key or a hash of the public key of an asymmetric private / key pair associated with the entity. Public addresses can be shared publicly so that other users know where to send cryptocurrency payments. However, public addresses recognized and used by the BSV wallet ecosystem or other cryptocurrency wallets are in the following format: 17Dx2iAnGWPJCdqVvRFr45vL9YvT86TDsn

[0007] Therefore, Alice needs to know or be provided with this type of address in order to send cryptocurrency to Bob. Furthermore, more than one type of address may be used by an entity or wallet for different types of transactions, and these addresses may only be used once to effect one transaction that is written to the blockchain. Obviously, these public addresses may not be user-friendly or easy for a user to remember, and therefore these public addresses or keys for transactions may need to be identified or obtained or derived for each transaction and may further need to be stored / cached for a certain period of time by the entity that wants to make a cryptocurrency payment to another entity.

[0008] Thus, while using blockchain technology to record data and events is desirable because blockchain offers advantages such as tamper resistance and permanent records, difficulties exist in identifying or establishing destination addresses for cryptocurrency payments. This is because the possible formats for these addresses recognized in the wallet ecosystem are not simple or user-friendly. One reason for this format may be the security associated with the specific naming protocol for public IP addresses applied across digital payment networks. Another reason is that the Bitcoin blockchain stores data in transactions (Tx), which are built into blocks. Identifying and accessing relevant data from the blockchain is based on the public address (linked to the private key) of the entity associated with the transaction. The present disclosure addresses these technical concerns by providing aspects and embodiments for improved destination identification and / or payment addressing for the cryptocurrency ecosystem.

[0009] Throughout this specification, the terms "comprise" or "having" and variations thereof (comprise, includes, comprises, comprising) are understood to mean a stated element, integer or step, or group of elements, integers or steps, but not to exclude any other element, integer or step, or group of elements, integers or steps. Summary of the Invention

[0010] The present disclosure relates to methods, devices, and / or systems associated with transactions for distributed ledgers. In some embodiments, the disclosure relates to a method for performing sender entity or payer entity validation for a request associated with a recipient entity or payee entity alias, establishing a check that the request originates from the payer entity or an addressing process / protocol or mechanism, such as a payment service associated with the payer entity. Embodiments include sending a request from the payer entity, the request based on the payee entity alias. Embodiments include validating the payer entity based on a timestamp and a digital signature included in the request. In response to successful validation, an output script associated with the payee entity is provided to the payer entity. This output script may be used to generate a transaction, which is stored or posted to the distributed ledger.

[0011] In another embodiment, the present disclosure relates to a method for implementing asynchronous, discontinuous, or delayed processing of requests sent by a payer entity. This embodiment includes sending a request from the payer entity, the request based on an alias of a payee entity. The embodiment includes providing an acknowledgment of receipt of the request to the payer entity, typically in the form of a token unique to the request. A notification may be sent to the payee entity regarding the request. This notification is sent even when the payee client is unavailable or offline, i.e., without a network or internet connection. As a result, the notification can be received and accessed when the payee client comes back online. Once the payee client authorizes the request, the embodiment includes generating and / or providing to the payer entity an output script associated with the payee client, the output script being generated for the correct request based on the token. The output script can then be used to generate a transaction, which is stored or posted to the distributed ledger.

[0012] Further relevant aspects and embodiments of the present disclosure are described in the detailed description below. Combinations of the aspects and embodiments discussed herein may be implemented in accordance with the present disclosure.

[0013] One or more computing devices or systems, including one or more processors, may be provided for executing computer-readable instructions, or programs, for implementing the above-described embodiments. [Brief explanation of the drawings]

[0014] Aspects and embodiments of the present disclosure are now described, by way of example only, and with reference to the accompanying drawings. [Figure 1] FIG. 2 is a flow diagram illustrating a method for updating a directory to include payment services according to a first aspect of the present disclosure. [Figure 2A]FIG. 1 is a flow diagram illustrating a method for identifying a host responsible for a payment service, performed by one or more processors of the payment service. [Figure 2B] FIG. 1 is a flow diagram illustrating a method for identifying a host responsible for a payment service, performed by one or more processors of a payment client entity. [Figure 3A] FIG. 10 is a flow diagram illustrating a method for identifying a public address associated with an alias, performed by one or more processors of a payment service, according to a second aspect of the present disclosure. [Figure 3B] FIG. 10 is a flow diagram illustrating a method for identifying a public address associated with an alias, performed by one or more processors of a payment client entity, according to a second aspect of the present disclosure. [Figure 4] FIG. 1 is a flow diagram illustrating a public key infrastructure sequence. [Figure 5A] FIG. 10 is a flow diagram illustrating a method of destination addressing implemented by one or more processors of a payment service according to a third aspect of the disclosure. [Figure 5B] FIG. 10 is a flow diagram illustrating a method of destination addressing implemented by one or more processors of a payment client entity according to a third aspect of the disclosure. [Figure 6] FIG. 10 is a flow diagram illustrating a payee endpoint resolution sequence. [Figure 7] FIG. 1 is a flow diagram illustrating a method for updating capabilities associated with a payment service. [Figure 8] FIG. 10 is a flow diagram illustrating a method for verifying a payer entity, performed by one or more processors of a payment service, according to a fourth aspect of the disclosure. [Figure 9] FIG. 10 is a flow diagram illustrating a method for verifying a payer entity, implemented by one or more processors of the payer entity, according to a fourth aspect of the present disclosure. [Figure 10] FIG. 10 is a flow diagram illustrating a method of asynchronous request processing performed by one or more processors of a payment service according to a fifth aspect of the present disclosure. [Figure 11] FIG. 10 is a flow diagram illustrating a method of asynchronous request processing performed by one or more processors of a payer entity according to a fifth aspect of the present disclosure. [Figure 12] FIG. 10 is a flow diagram illustrating a method of asynchronous request processing performed by one or more processors of a recipient client according to a fifth aspect of the present disclosure. [Figure 13] FIG. 10 is a flow diagram illustrating a process for verifying a public key associated with a client of a payment service. [Figure 14] FIG. 1 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0015] While the appended claims relate to the fourth and fifth aspects, which are discussed in detail below, the detailed discussion of the first, second, and third aspects is provided herein to provide the reader with a full and complete understanding of the claimed aspects and related embodiments of the present disclosure.

[0016] According to a first aspect of the present disclosure, a computer-implemented method is provided for implementing an addressing process or protocol for one or more clients for transactions associated with a distributed ledger. The addressing process is referred to as a payment service for one or more clients, as some aspects and embodiments of the present disclosure relate to transactions associated with the transfer of digital assets, such as cryptocurrency, from one entity to another. However, the term "payment service" should not be considered limited to mechanisms for the payment of digital assets, but rather as an entity or process that implements an addressing mechanism for any entity or client to send requests to or communicate with another entity or client, where such communications may be stored in, associated with, or submitted to a distributed ledger, i.e., blockchain. The term "service" is understood as the provision of one or more processes, protocols, or functionality used by and for one or more computing devices that wish to access or operate the functionality and / or require access to such functionality.

[0017] Similarly, the term "payer" should not be considered limited to an entity making a payment, but rather should be understood as the sender of a request or communication or transaction request. The term "payee" should likewise be understood as the recipient of a request or communication from a sender. Solely to facilitate the description of aspects and embodiments of the present disclosure, the terms "payment service," "payer client," and "payee client" are used throughout the following, but should not be considered limiting and are inclusive of the above.

[0018] A method of a first aspect includes providing an alias for a given client, the alias being unique to the given client, the alias including or associated with a network identifier. The method then includes associating the alias with the network identifier in a directory. This association is achieved by generating a service record based on the network identifier in the directory. The service record is then updated to indicate that a payment service is provided by a network or domain associated with the network identifier and the location of a host computing resource responsible for the payment service. Here, the host computing resource is configured to provide an identification of the client associated with the alias in response to receiving a request for a transaction related to the alias.

[0019] In some embodiments, the one or more clients described above are associated with one or more entities, such as a computing resource, a user terminal, or an application associated with the computing resource. In some embodiments, each client may be a digital wallet or an entity associated with a digital wallet, such as a user terminal having a digital wallet or application for the digital wallet installed. While aspects and embodiments of the present disclosure relate to digital wallets, it should be understood that client entities that do not have a digital wallet or a separate application therefor but are configured to provide functionality that operates as, with, or similar to a digital wallet are also within the scope of the present disclosure. For ease of explanation only, the following description relates to a digital wallet (a client entity associated with a digital wallet), but the present disclosure is not limited to only client entities having digital wallets.

[0020] The one or more digital wallets described above in the first aspect are one of multiple digital wallets in a network sometimes referred to as an ecosystem of digital wallets, such as a wallet ecosystem of multiple Bitcoin BSV cryptocurrency wallets. In other embodiments, the wallet may not be part of a network of wallets but may simply be a separate, independent entity associated with a domain. In either case, the network identifier may be or may include the network's domain name, e.g., nchain.com. In some embodiments, the directory may be a publicly accessible and / or decentralized system, such as a Domain Naming System (DNS), and may be referred to as a global directory. The location of the host computing resource may be the location of a server responsible for providing payment services for the network. For example, this may be an endpoint universal resource identifier (URI) and may include a web server universal resource location (URL) from which payment services may be accessed by other entities. For example, the other entity may be a digital wallet that may or may not be part of a network associated with a network identifier, one or more payment servers or client entities, or a payment application.

[0021] Advantageously, the first aspect enables a domain owner of one or more digital wallets to use a payment service that manages one or more functions for effectuating transactions, such as payment transactions, from a requesting (payer) entity to a destination (payee) entity associated with the digital wallet as a one-time activity, i.e., through the creation of a service record (SRV record). While service records in DNS for identifying service endpoints are well known, such records are not used or configured to enable payment transactions associated with a blockchain.

[0022] Advantageously, the above-described aspects allow requests for payment transactions to be generated using an alias to address a payee entity or a digital wallet associated with the payee. Thus, the requester (payer entity) does not need to know, obtain, or store / cache the complex public address for the digital wallet, i.e., 17Dx2iAnGWPJCdqVvRFr45vL9YvT86TDsn, to effect or configure a cryptocurrency transaction for a distributed ledger. Consequently, cryptocurrency payments can be made to this wallet. Only a network or associated alias that is easy for the payee to remember—for example, one that may be related to the payee's email address (name@domain.com)—needs to be known or sent by the requesting entity to request a payment transaction. Other formats for identifying entities may also be used as aliases. This type of alias addressing provides a much simpler and more user-friendly technique for resolving payment addresses. In some embodiments, even if the network identifier is not explicitly stated in the alias, as long as the alias is associated with the network identifier, i.e., by searching a directory or database, this is sufficient to identify the payment service associated with the alias.

[0023] In some embodiments, the method includes performing a directory lookup based on the alias in response to a request from a requesting entity for a transaction associated with the alias. The request for the transaction represents a request for information necessary to create or compose a transaction to be posted to the distributed ledger, i.e., blockchain. Thus, the request does not create a blockchain transaction itself, but is merely a request for or regarding a future transaction, i.e., an off-block request for information for creating a transaction to be posted to the blockchain in the future. This is understood to be a request for a future transaction for the blockchain. For ease of reference, the following description discusses a request for a transaction to explain this step. It is understood that this request relates to a future transaction for the blockchain. The method includes identifying a service record for the payment service in the directory associated with the network identifier and returning a location of a host computing resource for the payment service. Based on the returned location, a public address associated with a digital wallet associated with the alias can be determined, which in some embodiments corresponds to a public address that may be associated with a future transaction for the distributed ledger, i.e., the Bitcoin blockchain. In some embodiments, returning the location of the host computing resource includes returning a target and port pair. Here, target includes an identifier of the host computing resource, and port includes an identifier of an Internet Protocol communication port used by the payment service.

[0024] Advantageously, this enables discovery of a host responsible for providing a payment service and realizing a payment transaction to the payee entity based solely on the payee entity's alias, thereby significantly simplifying payment addressing of payment transactions for a digital ledger. Once a host is identified, and the digital wallet is associated with a network or network identifier, and thereby associated with a payment service, a public address associated with the payee entity's client or digital wallet can be determined. The term "public address" as referred to herein relates to the identity or address of a digital wallet or client, and in some embodiments, to one or more (future) transactions for a distributed ledger. In some embodiments, the public address may be a payment or destination address of the client or digital wallet. In other embodiments, the public address may be used to derive a payment or destination address. This public address may be the same or different for each transaction associated with the digital wallet.

[0025] In some embodiments, a method according to a first aspect of the present disclosure includes a method implemented in a payment client entity, which may be a requesting entity associated with a digital wallet for cryptocurrency. In this case, the method implemented by the payment client entity includes sending a request for a transaction from the requesting entity, the request being associated with an alias. The method includes obtaining a location of a host computing resource associated with the payment service, the location based on a service record associated with a network identifier identified in a directory search. The method then includes receiving a public address of a digital wallet associated with the alias, the public address being thereafter used in the requested transaction.

[0026] In some embodiments, the host computing resource is associated with a payment network that is different from the network identifier associated with the one or more digital wallets, and payment services for multiple entities registered with the domain associated with the network identifier are delegated to the domain associated with the payment network.

[0027] Advantageously, this allows a network to delegate alias-based payments to be managed and provided by a third party network associated with an entirely different domain.

[0028] In an alternative embodiment, the host computing resource is associated with the same domain as the domain of the network identifier. Alternatively, the domain owner may choose to implement the payment service within the network. In this case, the endpoint identifier in the service record is set to or updated to reference the same domain as the network (of the digital wallet). Advantageously, using the service record to indicate the host or endpoint responsible for the alias-based payment service makes it straightforward to add or change payment service providers for the digital wallet or network of digital wallets. Once the service record is updated, requests or lookup searches can continue seamlessly once the new host location is indicated in the service record.

[0029] According to a second aspect, the present disclosure relates to a computer-implemented method for implementing a payment service for one or more digital wallets for transactions using a distributed ledger, the method including: generating a machine-readable resource associated with the payment service, the machine-readable resource including, for each digital wallet in one or more digital wallets (or a network), an endpoint identifier of a host computing resource responsible for implementing the payment service, each digital wallet being associated with an alias. The machine-readable resource further includes an entry associated with at least one capability among a plurality of capabilities supported by the payment service. The machine-readable resource further includes instructions and / or specifications for accessing a public address or location or one or more resources for fulfilling transactions associated with the alias. The method further includes providing the machine-readable resource in a predictable or known location associated with the host computing resource for the payment service.

[0030] In some embodiments, each capability is specified in the machine-readable resource as a name-value pair. In some embodiments, capabilities include payee entity or payer entity verification for some or all transactions, functionality for multiple digital signatures of transactions, payee entity or payee authorization and / or email-based payment transactions so that a payment client may obtain a transaction script via email or the like.

[0031] Advantageously, the second aspect provides a means for discovering one or more capabilities or functions associated with a given payment service implemented for one or more digital wallets. Similar to the first aspect, all that is required by a requesting entity is the alias of the payer or destination entity, i.e., the alias associated with the payee's digital wallet, thus providing a user-friendly, simplified addressing mechanism. This advantage is ensured by the provision of a publicly accessible, machine-readable resource that specifies the functions or functions offered by a payment service implemented for a digital wallet. This second aspect, discovering the capabilities of a payment service based only on knowledge of the payee entity's alias, is particularly useful when a payer entity associated with a digital wallet wants to ensure that a capability or function for the transaction is supported when making a payment to an alias before a transfer request is made. Certain capabilities are considered key to realizing a cryptocurrency payment transaction associated with a distributed ledger, for example, to identify at least one endpoint identifier associated with the payment service, or to implement a secure communication mechanism based on a public key infrastructure (PKI), etc. These capabilities are often specified separately from the capability entries in the machine-readable resource. Advantageously, a capability entry allows for the specification, or provision of a record, of all available supporting functionality. For example, details for configuring a particular type of validation, additional security for a specified type of transaction or network, level of encryption, type of PKI architecture supported, level of addressing, etc. may be provided in a capability object. Thus, a requesting entity can discover and ensure that the required capabilities associated with an alias are first compatible with the requesting entity's resources and secondly provided for any transaction bearing the alias by accessing machine-readable resources associated with the alias's payment services.

[0032] In some embodiments, the method of the second aspect includes determining a host location associated with the payment service according to the first aspect and related embodiments described above. Accordingly, an endpoint identifier in the machine-readable resource is then obtained in relation to the determined host location.

[0033] Advantageously, this embodiment enables first host discovery based on a directory, i.e., DNS lookup of service records, followed by capability discovery of one or more features supported by the payment service. Thus, upon receiving a request for a payment transaction associated with an alias, a service record matching a network identifier in the alias is identified, which provides the location of the host and enables an endpoint identifier to be obtained. Capability discovery according to the second aspect is then performed based on the endpoint identifier in the machine-readable resource.

[0034] It is understood that the method according to the first aspect for host discovery is only one of many host discovery methods that may be performed before machine-readable resource-based capability discovery is performed according to the second aspect. Thus, the first aspect may be performed independently of the second aspect, and vice versa. While a preferred implementation may include both the host and capability discovery described above, this combination is not required to establish the capabilities of a payment service associated with an alias. Other methods of host discovery may also be compatible with the second aspect, in addition to the use of service records in the first aspect to identify host locations. For example, text-based records in a specified network path of a host location may be used instead of the service record-based implementation discussed in the first aspect. Furthermore, host discovery to resolve endpoint identifiers may be skipped altogether in the second aspect in some embodiments, for example, if the host location is easily discoverable or publicly available, or associated with the same domain as one or more digital wallets.

[0035] Therefore, it will be understood that the embodiments described below are based on the second aspect only, or on a combination of the first and second aspects described above.

[0036] In some embodiments, in response to receiving a request from the requesting entity for a transaction associated with the alias, the method further includes identifying a payment service associated with the alias based on the network identifier. Then, based on identifying the payment service, the method includes accessing a machine-readable resource from a predictable or known network location. Upon determining whether one or more capabilities required for the requested transaction are present in the machine-readable resource, the method includes returning an endpoint identifier of a host computing resource for the payment service, and based thereon, obtaining a public address associated with the alias according to one or more of the instructions and / or specifications in the machine-readable resource.

[0037] Advantageously, the above-described embodiments enable obtaining a public address associated with an alias without knowing only the alias and without knowing further information for contacting the payee entity. Furthermore, the public address is obtained based on an endpoint identifier from a machine-readable resource associated with a payment service to determine that one or more capabilities in the machine-readable resource comply with one or more requirements of the requesting entity or transaction. This thereby provides a seamless, simplified, and user-friendly technique for obtaining and navigating the public address of an entity having only an alias.

[0038] The above-described embodiments may be implemented in a requesting client payment entity, i.e., a payer entity generating a request for payment. In this case, the method includes sending a request for a transaction from the requesting entity, the request being associated with an alias. The method includes accessing a machine-readable resource from a location associated with a payment service, the payment service being identified based on a network identifier in the alias, the machine-readable resource being generated as described above for the second aspect. Then, based on identifying whether one or more capabilities required for the requested transaction are present in the machine-readable resource, the requesting entity receives an endpoint identifier of a host computing resource for the payment service associated with the alias. The method includes obtaining a published address associated with the alias using one or more of the instructions and / or specifications in the machine-readable resource.

[0039] In some embodiments, each digital wallet is associated with a user or entity registered for payment services in the network, and each digital wallet is a cryptocurrency wallet associated with a public key and a private key of an asymmetric cryptographic key pair for transactions on the distributed ledger. In some embodiments, obtaining the public address includes obtaining a public key of a digital wallet associated with an alias. In some embodiments, the public address associated with an alias is based on a cryptographic hash of the public key of the digital wallet associated with the alias. In related embodiments, the public key of the digital wallet is an elliptic curve digital signature algorithm (ECDSA) public key, and the public key is not part of any transaction previously stored or posted to the distributed ledger.

[0040] In some embodiments, related to a second aspect of capability discovery, the instructions and / or specifications in the machine-readable resource include subsequent steps of obtaining a public key associated with the alias. These steps include obtaining a public key infrastructure (PKI) request template from the machine-readable resource for a PKI endpoint identifier. The alias and network identifier are then included in the template to generate a complete PKI request. An HTTP GET request is then sent based on the complete PKI request to obtain the public key associated with the alias.

[0041] In some related embodiments, in connection with the second aspect of capability discovery, the instructions and / or specifications in the machine-readable resource related to the PKI include instructions for checking or verifying that a public key is still a valid identity key for a given payment client. In other words, this embodiment relates to verifying the owner of a given public key. In some embodiments, the public key to be checked relates to a public key previously obtained according to the embodiments described above, in connection with the same or a different transaction. In some embodiments, the public key to be checked relates to a public key that may be cached or stored by one or more payment clients for future use. In some embodiments, public key verification may be performed when a set period of time has elapsed since the public key was obtained or verified. In some embodiments, this verification may be triggered automatically. Method steps for such verification include obtaining a public key verification request template from the machine-readable resource for an endpoint identifier for such verification. In some embodiments, this may be the PKI endpoint identifier described above. To generate a complete public key verification request, an alias and a network identifier are included in the template. An HTTP GET request is then sent based on the complete public key verification request to prove that the public key associated with the alias is still valid, and in some embodiments, a response to this request is generated indicating whether the public key associated with the alias is in fact correct, i.e., whether the public key in the request matches the current public key associated with the alias, by indicating "true" or "false," or "1" or "0."

[0042] Advantageously, the above-described embodiments improve security, accuracy, and reliability for payment services by ensuring that old, ignored, or discarded keys that may have once been associated with a payment client and validity obtained by the payment entity, for example, based on a PKI request template, are not misused or sent to one or more clients or digital wallets. Such requests for public key verification or public key owner validation can be performed automatically at set intervals depending on the importance or sensitivity of the transaction intended by the payment entity, such as every 24 hours or every week, or after a specified amount of time has passed since the client's public key associated with the payment service was last obtained or validated. This automatic or periodic verification ensures that only current keys are used in transactions and also ensures the freshness of information regarding any public keys provided to the payment entity. In other embodiments, verification may be performed simply based on one or more requirements set by the payment entity making the request or requesting verification. Such above-described embodiments of public key verification are particularly useful when the public key for a given alias may change over time. This is troublesome because when trying to verify data signed with old keys, even if these old keys were securely obtained, it is impossible to be sure that the obtained public key actually belongs to the correct user, i.e., the client associated with the alias, as discussed above.

[0043] It should be understood that while the above-mentioned instructions and / or specifications reside in machine-readable resources associated with the payment service, the instructions may be intended to be executed by one or more computing resources or applications associated with a payment client entity. The one or more computing resources that execute these instructions may be associated with a payment client application installed on or associated with the payment client entity's digital wallet.

[0044] Advantageously, the provision of machine-readable documentation associated with the payment service enables the known alias to be utilized to generate an appropriate request in a specified format to the payment service to obtain the payee entity's public key, which is required to sign transactions for the distributed ledger.

[0045] In some embodiments, the known or predictable location of the machine-readable resource is based on at least one of an endpoint identifier, an Internet Protocol communication port used by the payment service, and / or a configuration specification of the payment service contained in a publicly accessible, well-known domain repository. Advantageously, the foregoing allows the machine-readable resource to be easily located based on either the payment service or the domain name associated with the network identifier.

[0046] In some embodiments, machine-readable resources are generated using the JSON (Java Script Object Notation) format. This is advantageous because JSON is primarily a machine-readable language, but is also a lightweight data-interchange format that is easy for humans to read and write. It is easy for machines to parse and generate, making it a useful data-interchange language for generating machine-readable resources.

[0047] In a third aspect, the present disclosure provides techniques for payment recipient addressing. This third aspect is related to the second aspect of capability discovery, as machine-readable resources are used to resolve payment recipient addressing, i.e., to send payments. Optionally, the third aspect may also include the first aspect of host discovery, although this is not essential, as other means of host discovery may also be used in combination with the third aspect of the present disclosure.

[0048] A third aspect of the present disclosure provides a method, wherein the step of obtaining a public address associated with the alias in the second aspect described above further includes obtaining a payee entity payee associated with the alias, the payee being used in structuring a transaction for making a cryptocurrency payment from the payer entity to the alias. The step of structuring the transaction according to the third aspect includes accessing a machine-readable resource based on identifying a payment service. This is followed by returning a payee endpoint identifier based on one or more instructions and / or specifications in the machine-readable document. Payment details for the transaction are then obtained from the payer entity. The payment details include at least the alias associated with the payee entity's digital wallet and the cryptocurrency amount to be paid to the payee. A digital signature associating the payment details with the payer entity's cryptographic key is then obtained. An output script associated with the payee endpoint identifier associated with the alias is then generated for provision to the payer entity. The output script is provided for embedding into a payment transaction for a distributed ledger.

[0049] Advantageously, the third aspect enables receipt of an output script for a digital wallet associated with an alias, thereby automatically enabling construction of a transaction in a format suitable for inclusion in a digital ledger. This is based solely on knowledge of the payee's alias, with the remaining details being established from a machine-readable resource associated with the host responsible for the payment service. Furthermore, enabling provision of a ready output script to be included in the transaction, along with knowledge of the alias, alone provides an overall simplified, seamless, efficient, automatic, easy-to-implement, and user-friendly alias based payment addressing technique for digital wallets.

[0050] The method of the third aspect may be implemented in or by a payment client entity, such as a digital wallet or application or processor associated with the payment client entity requesting the transaction. In this case, a method for configuring a transaction includes sending a request for the transaction from a payer entity, the request being associated with an alias. The method includes accessing a machine-readable resource from a location associated with a payment service and receiving a payee endpoint identifier based on one or more instructions and / or specifications in the machine-readable resource. The payer entity then provides payment details for the transaction. The payment details include an alias associated with a digital wallet of a payee entity and a cryptocurrency amount to be paid to the payee. The method includes providing a digital signature associating the payment details with a cryptographic key and receiving an output script associated with the payee endpoint identifier associated with the alias. The output script is then embedded into a payment transaction for the distributed ledger.

[0051] In some embodiments, the method of the third aspect includes retrieving a payee request template from a machine-readable resource of payee endpoint identifiers. The alias and network identifier are then included in the template to generate a complete payee request. An HTTP POST request is then generated based on the complete payee request to retrieve the payee endpoint identifier associated with the alias.

[0052] It should be understood that although these instructions reside in machine-readable resources associated with the payment service, the instructions may also be intended to be executed by one or more computing resources or applications associated with a payment client entity. The one or more computing resources that execute these instructions may be associated with a payment client application installed with or associated with a digital wallet associated with the payment client entity.

[0053] Advantageously, the provision of machine-readable documentation associated with the payment service enables a known alias to be utilized to generate a specified formatted request to the payment service to obtain a payee endpoint identifier or URI, which may then be used in composing transactions for the distributed ledger.

[0054] In some embodiments, the alias and public address of the payer entity include the public keys of the respective digital wallets associated with the payee entity and the payer entity, respectively, and the digital signature is used to verify the identity of the payer entity requesting the transaction. In some related embodiments, digital signatures associated with both the payee entity and the payer entity are required for verification of the respective entities before the transaction is stored or posted to the distributed ledger.

[0055] In some embodiments, the alias is referred to as a payment handle associated with a digital wallet within the network.

[0056] In a fourth aspect, the present disclosure provides techniques for verifying a payment client, i.e., a payer entity, that wishes to make a cryptocurrency payment to another payment client, i.e., a payee entity. The fourth aspect is related to the second aspect of capability discovery, as the machine-readable resources of the second aspect are used to perform payer entity verification. In some embodiments, the fourth aspect is related to the third aspect of payment addressing, and provides additional or related techniques for performing payment addressing.

[0057] A fourth aspect relates to a computer-implemented method for implementing a payment service for one or more clients for transactions associated with a distributed ledger, such as the Bitcoin blockchain. In a first implementation, the method is executed by one or more processors associated with the payment service. The method includes updating a machine-readable resource associated with the payment service. In some embodiments, the machine-readable resource is as described above with respect to the third aspect and is provided at or accessed from a predictable or well-known location associated with the payment service. Accordingly, as discussed in the second aspect, the machine-readable resource includes at least one identifier associated with a host computing resource responsible for implementing the payment service for each of the one or more clients, where each client is associated with an alias, the alias being client-specific. The machine-readable resource also includes an entity associated with at least one capability supported by the payment service, where each capability is associated with a protocol or instructions implementing the respective capability for the client of the payment service. The machine-readable resource also includes instructions and / or specifications for accessing or obtaining a public address associated with the alias, where the public address is used to effectuate transactions associated with the alias.

[0058] In a fourth aspect, updating the machine-readable resource includes adding at least one further capability supported by the payment service, the at least one further capability including verifying that a payer entity requesting a payee for an alias of a given client among the one or more clients is associated with the alias and / or asynchronous processing of requests from a payer entity, the request being associated with a payee for an alias of a given client among the one or more clients associated with the alias.

[0059] The fourth aspect provides all of the advantages associated with the second aspect described above of discovering one or more capabilities or functions associated with a given payment service implemented for one or more clients, each of which may, in some embodiments, be associated with a digital wallet. As with the second aspect, all that is required by the requesting entity, i.e., the payer entity, is the alias associated with the payee's digital wallet, thus providing a user-friendly, simplified addressing mechanism and providing a record of all supported functions or capabilities available or supported by clients associated with the payer entity in a manner that can be easily dispatched by any entity wishing to engage in transactions with such clients.

[0060] A further advantage provided by the first implementation of the fourth aspect is that it facilitates the provision or addition of one or more new capabilities to be supported by the payment service. By updating a machine-readable resource provided in a predictable or well-known publicly accessible location associated with the payment service, new capabilities that are added can be automatically deployed or made applicable to clients of the payment service, and a requesting entity can also establish that such new capabilities are supported when the machine-readable resource is accessed. Thus, new or updated capabilities can be directly discovered and applied to process one or more requests related to future transactions by one or more payment clients associated with the payment service.

[0061] In some embodiments, in addition to the added or further capabilities mentioned above, there may be an indication to specify whether the further capabilities, or indeed the originally generated capabilities, are true (on, or 1) or false (off, or 0). This toggle functionality is advantageous because it allows the payment service to implement or not implement one or more of the capabilities specified in the machine-readable resource for a particular type of transaction, or to set this implementation value accordingly for a particular period of time. Thus, any payment entity, such as a payer entity, can check whether a particular capability is actually implemented for the type of transaction associated with the request, or at the time the request is being generated. For example, if the requesting payment client, i.e., the payer entity in this case, is a client that does not support or is unable to respond to messages or commands regarding such capabilities, the request may be withdrawn or simply not sent.

[0062] A second implementation of the fourth aspect is also executed by one or more processors associated with a payment service. Here, a computer-implemented method is provided for implementing a payment service for implementing transactions associated with a distributed ledger, wherein an alias is provided for a client among one or more clients associated with the payment service, the alias being unique to the client. The method includes receiving a request associated with the alias from a payer entity, the request being associated with a payee client among one or more clients associated with the payment service, the payee client being associated with the alias in the request. In some embodiments, the request is an HTTP POST request generated based on the description associated with FIG. 6 above using a payee template. The method then includes validating the payer entity based on at least one capability supported by the payment service, wherein the at least one capability is identified using a machine-readable resource associated with the payment service. In some embodiments, how the machine-readable resource is accessed and how the supported capabilities are discovered and implemented is consistent with the second aspect already described above. Thus, in some embodiments, the at least one capability may be a capability originally generated based on the second aspect, or may be a further capability added based on the first implementation of the fourth aspect described above. The verifying step of the method includes obtaining a public key associated with the payer entity. In some embodiments, this step may be based on instructions and / or specifications in a machine-readable resource for the PKI, such as described above in connection with FIG. 4, i.e., by sending an HTTP GET request. The method includes determining, based on a request from the payer entity, whether a predetermined condition is met. In some embodiments, the predetermined condition may be a single condition, or multiple conditions to be met.

[0063] If it is determined that the predetermined conditions are met, the payer entity is considered valid, i.e., the payer entity verification is successful. In some embodiments, this verification may include verifying or confirming the identity of the payer entity. In some embodiments, this verification may include verifying or confirming the validity of the request in addition to the identity of the payer entity. The method then includes generating an output script associated with the payee client's payee destination associated with the alias. In some embodiments, the generated output script is associated with the payee alias and may be generated in the manner described above with respect to FIG. 5A (see the above discussion related to step 512a of this figure). Once generated, the output script is provided to the payer entity for embedding into transactions for the distributed ledger. Transactions are constructed for the distributed ledger based on this output script.

[0064] In some embodiments, it may be determined that the predetermined condition (or one or more such conditions) is not met. In this case, the method, when implemented by the capabilities in the machine-readable document, includes generating a response denying the request received from the payer entity because the payer entity was not valid. In some embodiments, this denial response is sent to the payer entity, while in other embodiments, a denial response is simply generated and not sent for the record. In this case, the request may simply remain unanswered or unauthorised.

[0065] In addition to the advantages associated with the second and third aspects, the above-described method of the second implementation improves security and reliability for a payment client or entity associated with a payment service that supports or implements payer verification capabilities when processing a request for a payment transaction from another entity, i.e., a payer entity. This is because, in order to establish the authenticity of the requesting entity, i.e., by verifying its identity and correspondingly validating the request sent by the payer entity, the payer entity must be verified based on at least one predetermined condition. Thus, a payment client of the payment service may be assured that the request is authentic and indeed originates from the paying entity, and not from any other malicious party or entity.

[0066] In some embodiments, the request includes a timestamp indicating the date and time the request was sent by the payer entity, and / or a digital signature associated with the payer entity's public key, and / or a one-time token. At least one of the above is present in the request. In some embodiments, the digital signature is always present along with either the timestamp or the one-time token. In some cases, both the timestamp and the token may be present in a request signed with a digital signature.

[0067] In some embodiments, when a timestamp is present in the request, the predetermined condition includes verifying that the timestamp included in the request is within a predetermined period of time of receipt of the request by the payment service associated with the payee client. In some embodiments, the predetermined period is a maximum of two minutes. This two-minute period is selected to allow for a reasonable delay buffer due to synchronization issues between clocks in different entities. It should be understood that this period is not limited to two minutes and may be longer depending on the required application and implementation. Typically, two minutes is an acceptable time difference buffer, and in some cases may be shorter if the application or implementation has particularly critical or time-sensitive characteristics. The date and time may be recorded by a clock associated with either entity to record the date and time of transmission / reception.

[0068] In some embodiments, when a digital signature is present in the request, the predetermined condition includes verifying that the digital signature in the request corresponds to the payer entity's obtained public key. In some embodiments, this includes checking that the signature in the signed request can be verified or checked based on the obtained public key. In some embodiments, the signature is applied based on the private key of an asymmetric or cryptographic key pair for the payer entity, which can be verified or decrypted only using the public key of the same key pair. In some embodiments, the verification may also include checking to see if the public key is still a valid identity key for the payer entity, rather than an old or unused key. This may be relevant when the public key may have been obtained some time ago, or if the public key is changed periodically but the key was obtained just before the change occurred.

[0069] In some embodiments, when a one-time token is present in a request, the predetermined condition includes verifying that the token has not been used in any previous request. In some embodiments, this includes maintaining a record of all one-time tokens included in previous requests. This record may then be used to establish that the token in the current request has not been used previously. For example, a scheme for issuing single-use tokens may be used that monotonically increments a counter each time a token is issued.

[0070] The above-described embodiments advantageously require that the request include one or more of a signature, a timestamp, and / or a one-time token from the payer entity, so that these may be used to verify the payer entity and the message, i.e. the request, sent by this entity. Advantageously, by verifying the signature, to check that it can be decrypted or verified using the payer entity's public key, which has already been obtained, the payment service can verify that the request actually originates from the payer entity. Thus, the identity of the payer entity can be verified.

[0071] Advantageously, validating that the request timestamp is within a predetermined period further improves security and reliability by limiting the scope of message reply attacks. A message reply attack or man-in-the-middle attack can occur when a malicious party intercepts and replies to the same message one or more times in an attempt to confuse the destination or payee client or payment service into believing that the message is actually being sent from the payer entity rather than the malicious party. This may prompt the payee client or payment service to reply to the message, leading to or providing access to the malicious entity rather than the genuine payer entity that originally sent the message. For example, a simple application login screen implementation may capture sensitive information such as a username and password from a user. If this data is captured, an attacker can log into the application as the user by simply re-submitting the captured sensitive information at some later point in time. If both the username and password remain valid, the attacker will be granted access. Therefore, in this disclosure, by checking that the timing of receipt is within a small period of the timestamp in the request itself, this narrows the window for successful replay of a captured request, thus preventing these types of attacks or making them easily detectable if they occur. Advantageously, verification based on one-time tokens ensures that a given request is processed only once. Thus, if a request is captured but it is detected that the request has already been processed, subsequent replays of that request can be rejected. For example, again referring to the user login example, each time a user accesses a login page for a web application, a one-time-use token may be embedded as a hidden field along with the username and password fields. As a result, any duplicate or subsequent requests will feature the same one-time token. Thus, a malicious party cannot guess a valid token, for example, through brute force trial and error.In embodiments where such one-time or single-use tokens are incremented using a counter each time a token is issued, such counter may be a sequence or serial number.

[0072] Advantageously, combining one-time use tokens with timestamps and digital signatures presents an attacker with multiple obstacles when carrying out a replay attack. Not only must the attacker capture and record a valid request, but they must also prevent the initial request from being processed. Once the original request is processed, the one-time use token is burned, i.e., used up, and is no longer valid, so replay does not work. This means that timestamp-based validation, plus digital signatures that prevent message modification, make it extremely difficult for a malicious party to successfully carry out a replay attack.

[0073] In some embodiments, transmitting the output script includes applying a digital signature associated with the payee client's public key to the output script, and transmitting the signed output script to the payer entity. Advantageously, signing the output script under a key or cipher related to the payee entity's public key prevents tampering with the output script associated with the requested payment. In some embodiments, this includes applying the signature using a private key of an asymmetric or cryptographic key pair for the payee entity, such that the signature can only be verified or decrypted using the public key belonging to the same key pair.

[0074] In some embodiments, the payer entity is associated with a payment service that is different from the payment service of the payee client and is assigned an alias associated with the different payment service, and the alias is included in the request from the payer entity. In other embodiments, the payer entity is associated with the same payment service as the payment service of said payee client and is assigned an alias associated with the same payment service, and the alias is included in the request from the payer entity.

[0075] While it is not essential to the implementation of the fourth aspect that the payer entity be associated with the same or a different payment service as the payee entity's payment service, if so, this also has the advantage that it can be accessed simply based on the alias to discover the public address and any capabilities supported by the payer entity (as described in connection with the first through third aspects above). In other embodiments, an HTTP GET request such as that described in Figure 4 can be used to obtain and verify the public key associated with the payer entity when this makes use of a PKI template in the machine-readable resource of the paying entity's payment service.

[0076] According to a third implementation of the fourth aspect of the present disclosure, a method related to payer verification as described above may be performed in association with a requesting client payment entity, i.e., in this case, the payer entity making the request. The method may include generating a request associated with an alias, the request associated with a payee client payee among one or more clients associated with a payment service, the payee client associated with the alias in the request. The method includes applying a digital signature associated with the public key of the payer entity to the generated request to obtain a signed request. In some embodiments, this includes signing the request with a private key of an asymmetric key pair for the payer entity, where the signed request can be obtained, verified, or read using the public key of the same pair. The method further includes accessing a machine-readable resource associated with the payment service of the alias. In some embodiments, such access is based on the alias of the payee client described in association with the second aspect. The method includes sending the signed request based on one or more instructions and / or specifications in the machine-readable resource associated with the payee, the request including a timestamp indicating the date and time of sending. In some embodiments, when performed by the requesting payment entity, the request may be an HTTP POST request based on a payee template as discussed in relation to the third aspect in Figure 6. The method then includes receiving an output script associated with the requested payee, and embedding the received output script into a transaction for the distributed ledger, the transaction being associated with the payer entity and the payee client.

[0077] In some embodiments, the received output script includes a digital signature based on a public key associated with the recipient client, and the method includes first verifying the signature by obtaining the recipient client's public key using an HTTP GET request as described in relation to Figure 4, and then verifying that the digital signature is verified or decrypted using the obtained public key, thereby advantageously verifying that the message was originally generated by the recipient entity and that the output script is authentic and can be used to compose a transaction.

[0078] In a fifth aspect, the present disclosure provides techniques for implementing asynchronous processing of requests for payees associated with an alias. The request is sent from a payer entity, i.e., in this case, the payer entity, to a payment service associated with the alias, i.e., the alias is associated with a payee client. Asynchronous processing of requests may be considered to include delayed or discontinuous processing of requests when a response associated with the request is not provided immediately or within a short time of receiving the request. This also covers situations when processing may occur out of order, i.e., in some cases, requests from a paying entity are processed in an order other than the order in which the requests were received. The term "asynchronous processing" is therefore used hereafter to cover all of the above-mentioned situations in which processing of responses to requests is not synchronized with the timing of receipt of the requests. In some embodiments, such asynchronous processing may apply when a response or action is mandatorily required from a paying entity, when such entity is unavailable or offline, i.e., not connected to a communications network, such as the Internet, used for transferring requests, responses, and messages. The fifth aspect relates to the second aspect of capability discovery, as the machine-readable resources of the second aspect are used to implement capabilities that enable such asynchronous processing for payment clients associated with a payment service. The fifth aspect relates, in some implementations, to the third aspect of payee addressing, providing additional or related techniques for implementing asynchronous, but payee addressing. In some embodiments, methods related to the fourth aspect related to payer verification may be included in the fifth aspect.

[0079] A fifth aspect relates to a computer-implemented method for implementing a payment service for one or more clients for transactions associated with a distributed ledger. In a first implementation, the method is executed by one or more processors associated with a payment service and relates to a computer-implemented method for implementing a payment service for transactions associated with a distributed ledger, wherein an alias is provided for a client among the one or more clients associated with the payment service, the alias being unique to the client. The method includes receiving a request associated with the alias from a payer entity, the request being associated with a payee of a payee client among the one or more clients associated with the payment service, the payee client being associated with the alias in the request. In some embodiments, the request may be an HTTP POST request based on a payee template associated with the payment service, such as discussed with respect to FIG. 6. Implementing asynchronous processing of requests in this aspect is based on at least one capability supported by the payment service, the at least one capability being identified using a machine-readable resource associated with the payment service. In some embodiments, the capability is generated or provided according to the second aspect described above using a machine-readable resource accessible from a predictable or well-known location associated with the payment service. The at least one capability may be a capability that was originally present at the time of creation of the machine-readable resource, or may be a further capability as described above in relation to the first implementation of the fourth aspect that is applicable for the fifth aspect.

[0080] Performing asynchronous processing includes generating a token unique to the received request. In some embodiments, this token serves as an acknowledgment of receipt of the request associated with the payee client. In some embodiments, the token also serves as an identifier for the request. As a result, it may be used to reference or call back to such request. The token is then transmitted to the payor entity. In some embodiments, the method includes sending a notification of receipt of the response to the payee, i.e., the client associated with the payee to which the request relates. This notification may be sent to a digital wallet or message or mailbox application on a user device associated with the payee client. Here, such a notification may be sent even when the payee client is offline or unavailable or not responsive, i.e., not connected to the Internet, or simply turned off. In some embodiments, whenever the payee client is operational or online and responsive, this response authorizes or denies the request from being received by the payment service. In some embodiments, if a response is not received by the recipient client by a predetermined period of time, which may be, for example, 24 hours or two days, a response similar to a denial, such as an unresponsive or unauthenticable response, is considered to have occurred. The remaining steps of the fifth aspect are performed based on the received response.

[0081] In response to receiving an authorization for the request in response from the payee client, the method of the fifth aspect includes generating an output script associated with a payee of the payee client associated with the alias. In some embodiments, this output script may be generated in the manner described with respect to FIG. 5A of the third aspect, particularly with respect to step 512a. The method then includes generating a callback request. The callback request includes the token and the generated output script. The output script is associated with the payee of the payee client. The callback request is then sent to the payer entity. The token is provided within the callback request. As a result, the output script is correctly correlated with each request generated associated with the payee in the output script. The output script is provided for embedding into transactions for the distributed ledger.

[0082] In some embodiments, if a denial of the request is received or the above-mentioned predetermined period of time expires without a response being received from the payee client, the method includes generating a response denying the received request. In some embodiments, the generated response is not sent to the payer entity and the request token is then simply discarded. In other embodiments, a callback message is generated based on the token and the denial response, which is sent to the payer entity to inform the payer entity that the request associated with the token has been denied. In both cases, no output script is generated.

[0083] Advantageously, implementing such asynchronous processing of requests provides a means for seamless, accurate, discontinuous, or delayed processing of requests. This technique is particularly useful in implementations or situations where a response from the destination, in this case a payee client, needs to be processed, but the payee client is inoperable or unable to provide such a response. Thus, the above-described technique allows requests to still be processed accurately even when the payee client is offline or unable to respond. This is achieved by generating a token as described above and further associating this token with the request. Sending a callback based on this same token for the request in question ensures that the output script is correctly associated with the transaction associated with the request, regardless of the amount of time that has elapsed since the request was sent from the payer entity or the response was received from the payee entity. Furthermore, regardless of how many other requests are provided from the same payer entity associated with the same payment service to the same or different payee entities, or in what order they were sent before any responses were received, the token in the callback request ensures that the output script is correctly and seamlessly correlated to only one request to which it is related or to which it is to respond. Thus, rather than delays or interruptions in processing the request, processing is accomplished accurately and seamlessly, as if there were no delays or puts of synchronous flow whatsoever. Advantageously, therefore, payment clients of a payment service that includes and implements such capabilities of asynchronous request processing enjoy seamless and reliable processing even if they are not operational or offline or available when notification of a request is received.

[0084] In some embodiments, the step of performing or initiating asynchronous processing of the request by generating a token may be performed for all requests associated with a payee client. This implementation is advantageous because the token is always returned first as an affirmative response to the payer entity, regardless of whether the payee client is offline or present. As a result, there is a record of this request associated with the token. In some embodiments, if a response from the payee client authorizing the transaction is received almost immediately, within a predetermined period of time, e.g., 10 seconds, a callback request may be returned directly. In this case, a token may still be generated in some embodiments to maintain a record of the request, but may or may not be sent along with the callback request including the output script or the actual rejection response, if applicable. In some embodiments, if a response from the payee client is not received within the predetermined period of time, the token may not be generated. In this case, the request / response flow is synchronous, and the callback request may include the output script. Advantageously, this embodiment saves computing and network resources associated with separately sending a token when it is already established that the payee client is online and that an approval / rejection response has already been received.

[0085] Both of the above implementations have the advantage of allowing asynchronous processing associated with the token. The latter implementation is only useful if the predetermined period is very short, for example, 10 seconds or less. This protects the payment service or payment entity from any malicious party conducting a message replay attack. This is ensured by generating the token immediately or shortly after the request is received at the payment service.

[0086] In some embodiments, sending the token and / or sending the callback request includes applying a digital signature associated with the payee client's public key to the token to obtain a signed token, or to a combination of the output script and token in the callback request to obtain a signed callback request, which is then returned to the payer entity. This advantageously increases security by protecting the integrity of the contents of the token and prevents the callback request from being tampered with during transmission, while also serving to verify the identity of the payee client based on its public key. In some embodiments, a digital signature is applied to either the token or the callback request based on the private key of the payee entity's asymmetric key pair, where only the public key of the same key pair can be used to obtain or use, i.e., decrypt or decrypt, the contents of any message signed with the private key.

[0087] In some embodiments, the payer entity is associated with a payment service that is the same or different from the payee client's payment service and is assigned an alias associated with the payment service, which is included in requests from the payer entity. As with the fourth aspect, it is not essential that the payer entity be associated with the same or different payment service as the payee entity's payment service. Any entity configured to access and transfer cryptocurrency can generate requests as a paying entity, even if it does not implement a digital wallet. However, if the paying entity is so associated, the paying entity may also benefit from being accessed simply on an entity basis to discover the public address and any capabilities supported by the paying entity (as described in connection with the first through third aspects above). For example, in some embodiments, a method may utilize an HTTP GET request on the paying entity's payment service to obtain and verify the public key associated with the payee entity, as described in FIG. 4. Similarly, if the paying entity is associated with a payment service, the callback request is an HTTP POST request based on a payee request template, a token, and an alias for the payer entity, where the payee request template is obtained by accessing a machine-readable resource associated with the payment service of the payer entity, as described with respect to Figure 6. For asynchronous request processing, in addition to the HTTP POST request of Figure 6, capabilities within the machine-readable resource also include including, or provision for including, the token in the payee template. Thus, advantageously, the payer entity may be contacted simply using an alias, as discussed in the second aspect.

[0088] According to a second implementation of the fifth aspect of the present disclosure, a method related to asynchronous processing as described above may be performed in connection with or for a requesting client payment entity, i.e., a payer entity making a request. In this case, the method may include generating a request associated with an alias, where the request is associated with a payee client payee among one or more clients associated with the payment service, the payee client being associated with the alias in the request. The method may include transmitting the request based on one or more instructions and / or specifications accessed from a machine-readable resource associated with the payee, the machine-readable resource being associated with the payment service. In some embodiments, such access is based on the techniques described above in connection with the second aspect. The method may include receiving a token from the payment service, where the token is unique to the request and associated with a digital signature. The method may include verifying that the digital signature associated with the token is associated with the payee client's public key. As described above, the signature in some embodiments is applied using the private key of the payee client's asymmetric key pair, such that the token can only be verified or decrypted using the public key of the pair. In response to successful verification, the method includes updating a record associated with the request based on the token. In some embodiments, the record may be associated with the payer entity itself, a payment service associated with the payer entity, or may be based on a record stored remotely on a device or in the cloud associated with the payer entity. The method includes receiving a callback request, the callback request including the token and an output script associated with the requested payee, the callback request being associated with a digital signature. The digital signature may be as described above for the token. The method includes verifying that the digital signature associated with the callback request corresponds to the public key of the payee client, and further includes correlating the token in the callback request to the updated record in response to successful verification.Once correlated to the correct request, the output script in the callback request is then embedded into a transaction for the distributed ledger, and the transaction is associated with the payer and payee entities.

[0089] The advantages discussed above for the first implementation of the fifth aspect apply equally to the second implementation. Furthermore, when a request-specific token is provided to a payment client, such as a payer entity, this entity can advantageously easily identify requests associated with transactions originating from that entity without having to search through a list or collection of transactions or messages before a response associated with each request is received, even if many other messages have been sent / received by the entity.

[0090] In some embodiments, the received token or callback request includes a digital signature associated with the recipient client's public key, and verifying the digital signature includes retrieving the public key and checking that the retrieved public key corresponds to a public key used to verify the signed token and the output script. In some embodiments, retrieving the public key is based on sending an HTTP GET request using a public key infrastructure (PKI) request template in a machine-readable resource, as described in connection with FIG. 4.

[0091] In some embodiments, the method is associated with capabilities related to payer verification as performed by or by a payer client according to the third implementation of the fourth aspect described above.

[0092] According to a third implementation of the fourth aspect of the present disclosure, the method related to asynchronous processing described above may be performed in association with a destination payer client, i.e., a payee client to which a request is directed. In this case, the method includes receiving, by the payee client, a request associated with an alias, the request being associated with a payee client's payee destination among one or more clients associated with a payment service, the payee client being associated with the alias in the request. When the payer client is online or otherwise available to respond to the received request, the request requiring such input from the payee to be processed, the payee client may approve or deny the request and transmit a response to the payment service based on the approval or denial.

[0093] In some embodiments, the notification may include details of the request, such as instructions from the requesting payor client, the type and / or amount associated with the requested transaction. In some embodiments, the notification may be presented to the payee client on a computing device or display terminal associated with the payee client's digital wallet. In some embodiments, the method may include interacting with or entering data to approve or deny the request on a user interface of the computing device or display terminal. In some embodiments, the approval or denial may be provided automatically by the payee client without requiring interaction or any explicit action at the computing device. In some embodiments, the payee client may include or be associated with one or more records or lists that allow or disallow requests associated with particular properties or payer entities or payer entity aliases. For example, if the request is from a payer entity that is on a whitelist, the whitelist is checked and an approval is sent as soon as the payee client comes online. Similarly, if the payer entity is on a blacklist, a denial is automatically sent. Lists can be associated with other properties of the request, such as the type or amount of the request, etc. Once the response is provided, processing of the request proceeds per the first and / or second implementation of the fifth aspect.

[0094] An exemplary scenario related to the fourth aspect includes a method associated with transactions for a distributed ledger, the method including sending a request from a payer entity to a payee entity, the request including or addressed to an alias for the payee entity, where the request is received by a payment service associated with the payee entity. The payment service verifies the payer entity based on a timestamp and a signature included in the request. In response to successful verification, an output script associated with the payee entity is sent to the payer entity for generating a transaction based on the output script. The transaction is posted to the distributed ledger.

[0095] An exemplary scenario related to the fifth aspect includes a method associated with transactions for a distributed ledger, the method including sending a request from a payer entity to a payee entity, the request based on an alias for the payee entity, where the request is received by a payment service associated with the payer entity. An acknowledgment of receipt of the request in the form of a token is provided to the payer entity. A notification related to the request is provided to the payee entity. When the payee entity is online or available, the payee entity approves or denies the request in the notification by interacting with a user interface. In response to the approval from the payee entity, an output script associated with the payee entity is sent to the payer entity for generating a transaction based on the output script. The transaction is posted to the distributed ledger.

[0096] A further aspect of the present disclosure relates to a method of configuring a prefix for requesting a payment transaction from a requesting entity to an alias associated with a digital wallet in a network, such that in response to receiving a request from the requesting entity that includes the prefix and the alias, one or more of the above-described first through fifth aspects of the present disclosure may be automatically performed by the payment service based on the alias.

[0097] Advantageously, this further aspect allows the above aspects and embodiments to be automatically triggered by simply presenting a prefix, such as "payto:" or "bsvto:", followed by an alias of the payee entity known to the requesting entity. This prefix advantageously allows a request for a payment transaction to be generated and sent to the payment service according to one or more of the above aspects and embodiments. All that the requesting entity needs to do is append the known alias to the prefix.

[0098] The present disclosure also provides a computing device including a processor and a memory containing instructions that, when executed by the processor, cause the computing device to perform any aspect or embodiment of the computer-implemented methods described herein. The present disclosure also provides a system including a plurality of such devices operable together to perform any aspect or embodiment described above.

[0099] The present disclosure also provides a non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computing device or system, cause the computing device or system to perform at least one aspect or embodiment of the computer-implemented methods described herein.

[0100] Some specific embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numerals indicate like features, and in which:

[0101] FIG. 1 illustrates a method for implementing payment services for one or more digital wallets associated with aliases, according to a first aspect of the present disclosure. In FIG. 1, the method is understood to be implemented by one or more processors associated with providing the payment services. In the present disclosure, a payment service may be one or more executable rules or protocols that perform the functions described below. The wallets may be within a network of digital wallets or may be individual, standalone cryptocurrency wallets for transactions associated with a distributed ledger. For example, the method may be implemented within a network of Bitcoin wallets for the BSV cryptocurrency. For simplicity and ease of understanding, aliases associated with digital wallets within a network of digital wallets are referenced below in the description of the figures. However, as noted above, the present disclosure is not generally limited to digital wallets connected to other wallets within a network.

[0102] Step 102 involves assigning or providing an alias to a given digital wallet within the network of digital wallets. This involves providing a mapping or correlation of the alias with the respective public address associated with the digital wallet. The alias can then be used in place of the public address. Such an assignment may occur, for example, when a particular payment client or entity signs up to the network. In this regard, an "alias:public address" pair may be provided for each wallet. The alias is unique to a particular wallet and includes either a network identifier, such as the network's domain name, or a name that identifies the network. For example, the alias may be in the familiar email format, such as clientname@domainname.com, where clientname may simply be the name or identifier of the person or company signing up or registering to the network of digital wallets, such as Alice or Bob. Domainname refers to the organization or domain owner, e.g., "nChain." In this case, Alice's alias is alice@nchain.com. If Bob signs up to a different network of digital wallets with the domain name "notnchain" that implement one or more aspects and / or embodiments of the present disclosure, Bob's alias may be assigned as bob@notnchain.com. Other alias formats, such as AliceNC or BobBSV, may also be used, as long as the alias is associated with a network identifier.

[0103] Step 104 relates to generating a service record for the payment service based on the network identifier in the directory. This step is necessary to associate an alias with the network identifier that provides the payment service in the directory. The directory referred to here is typically an open, decentralized directory that is publicly accessible by any user. For example, a global directory such as DNS can be used. This is decentralized and open, and therefore accessible by any entity or user from anywhere via the Internet. While an open, accessible, decentralized directory is a preferred implementation, the present disclosure is not limited thereto. In some embodiments, the referenced directory may be a centralized directory. In other embodiments, the directory may be a closed directory, that is, accessible to users or entities registered with the network or service. For ease of explanation, a global directory such as DNS will be referred to in the following description. It will be understood by those skilled in the art that other types of directories are within the scope of the present disclosure.

[0104] For example, when an alias is provided in an input or request in the above format, a directory such as DNS is searched (caDNS lookup) to identify whether a payment can be made using the alias. If an alias associated with a network or domain that does not support aliases based on payment services is entered, this situation may be handled using one or a combination of the following implementations. In one implementation, no result is returned by DNS indicating that payments cannot be made using the alias. If no service record exists, the requesting entity must obtain the public address by other known techniques before any transactions associated with the distributed ledger can be created. In another implementation, for example, when the service is provided by a dame domain as the network identifier, the returned result may be the location of a host responsible for the network or domain associated with the alias. For example, based on the above example, if a service record for a payment service associated with the network identifier in the alias does not exist in the directory, the location or URI of the host responsible for the domain "nchain" may be provided, or the requesting entity may be directed to a host for the domain "nchain." Thus, the host responsible for the domain indicated in the alias may process the request further.

[0105] Step 106 involves updating the service record created in step 104, or including an entry or field therein indicating a payment service provided by the network or domain associated with the network identifier. Updating the service record in the DNS indicates that a particular network identifier, such as nchain.com, provides or uses a particular payment service, e.g., a service identified as "bsvpay" or "bsvalias." This updating indicates to entities performing DNS lookups that the identified payment service, i.e., given "bsvalias," can perform payment transactions against the alias associated with the nChain domain.

[0106] Step 108 involves updating the service record to indicate the location of the host computing resource responsible for the payment service indicated in step 106. Thus, if the payment service is associated with a different network or domain to the digital wallet's network, this entry in the service record would point to the web server location or IP address of the host computer or server responsible for the service. Continuing with the example above, if the bsvalias payment service is associated with a separate network or separate domain (bsvalias.com), a location or instruction identifying the host server for bsvalias.com would be indicated in the service record to identify where to find the host computing resource configured to implement the identity of the digital wallet associated with the alias.

[0107] An example of a service record (srv record) in DNS that defines the location of a server for a specified service is shown below:

[0108] A service record for a domain name (nchain) associated with a payment service (bsvalias) may have the following fields or entries in the following format: · service: The symbolic name of the desired service. proto: the transport protocol of the desired service, which is usually TCP (transmission control protocol) or UDP (User datagram protocol). · name: The domain name for which this record is valid, ending in a dot. · TTL: A standard DNS time-to-live field that sets the expiration period or deadline associated with a record. · class: The standard DNS class field. priority: The priority of the target host. · weight: the relative weight for records with the same priority. port: The TCP or UDP port on which the service should be discovered. · target: The canonical hostname of the machine providing the service.

[0109] For example, a domain owner in nchain may create an SRV (service) record with the following parameters: [Table 1] Figures 2A and 2B are flow diagrams illustrating a method for identifying a host responsible for a payment service. Figure 2A illustrates a method performed by one or more processors associated with the payment service. Figure 2B illustrates a method performed by one or more processors associated with a payment client entity.

[0110] In step 202a of Figure 2A, the host service receives a request from a requesting entity for a transaction associated with the alias. This request may be in the form of input from an interface of the requesting entity's computing device, i.e., an installed digital wallet. For example, the request may include a request indicating a payto from a payer entity to alice@nchain.com.

[0111] In step 204a, in response to the request or input in step 202a, a global directory search or lookup, e.g., a DNS lookup, is performed based on the entered alias to identify a service record for the payment service in the global directory associated with the network identifier in the alias. Thus, using the same example described above with reference to FIG. 1, this step would identify the service record for the domain nchain, as described above, since nchain was received among the network identifiers in the alias. This service record for nchain then identifies bsvalias as the payment service to be used for nchain.

[0112] In step 206a, once the service record, and therefore the payment service, i.e., bsvalias, has been identified, the location of the host computing resource for the payment service is obtained. In some embodiments, this is returned to the requesting entity. In the example above, this location of the host corresponds to the target:port pair in the srv record of nchain. The target:port pair provides the location at which the host responsible for the service bsvalias is used or operates.

[0113] In step 208a, a public address of a digital wallet associated with the alias may be determined based on the host location, i.e., target:port pair, obtained in step 206a. In some embodiments, this may be based on a mapping when signing up to a payment service or network, such as discussed in connection with Figure 1. Once the public address is obtained, it can be used for Bitcoin blockchain transactions between digital wallets.

[0114] FIG. 2B, as described above, relates to steps corresponding to FIG. 2A, but performed in a computing device or digital wallet of the payer or requesting entity.

[0115] Thus, step 202b involves sending a request for a transaction from a requesting entity, the request being associated with an alias.

[0116] Step 206b relates to obtaining the location of a host computing resource associated with the payment service, where the location is based on a service record associated with the network identifier. This is performed, for example, in steps 204a and 206a of Figure 2A. Thus, the location obtained here is the target:port pair of the host of the "bsvalias" payment service.

[0117] In step 208b, the public address of the digital wallet associated with the alias is obtained so that it may be used for transactions associated with the digital ledger.

[0118] 3A and 3B are flow diagrams illustrating a method according to a second aspect of the present disclosure for identifying a public address associated with an alias in a request for a transaction. Figure 3A illustrates a method implemented by one or more processors associated with a payment service. Figure 3B illustrates a method implemented by one or more processors associated with a payment client entity.

[0119] At step 302a of FIG. 3A , a machine-readable resource is generated for the payment service. The machine-readable resource is provided to ensure that the features or capabilities provided or supported by the payment service and / or any instructions utilizing these capabilities can be identified. This process is therefore referred to as capability discovery associated with the payment service. Accordingly, a machine-readable document is generated for the capability discovery process, allowing a payment client entity or digital wallet or application wishing to use or request the service to learn about or discover the supported features of the payment service and any respective endpoints and configurations associated with using the payment service. In some embodiments, the machine-readable resource is a file or document that is pre-generated and stored in association with the payment service, i.e., a static document. In some embodiments, for example, in enterprise-grade service implementations, the machine-readable resource may be dynamic, e.g., generated on demand rather than as a static file stored on a web server. Advantageously, such dynamically generated resources provide simplification in service deployment, migration, maintenance, and any upgrades that may be required to be performed.

[0120] In some embodiments, JSON (JavaScript Object Notation), a lightweight data-interchange format, is used to create machine-readable resources. JSON is a completely language-independent text format, using conventions familiar to programmers accustomed to C-family languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. Furthermore, JSON is built on two structures: a set of name / value pairs and an ordered list of values. In many languages, this is realized by an array, vector, list, or sequence. Because these are generic data structures, virtually all modern programming languages ​​support them. Therefore, using JSON for machine-readable resources is desirable because JSON provides a data format that is interchangeable with other programming languages ​​based on these same structures.

[0121] The machine-readable resource may include the following information about the payment service: At least one endpoint identifier associated with a host computing resource responsible for implementing the payment service. This may be the location of a server or computing resource responsible for one or more functions of the payment service, i.e., a target:port pair.

[0122] An entry associated with at least one capability among a plurality of capabilities supported by the payment service, which may be one or more functions that may be supported by the payment service, such as requesting entity or payer entity verification, multiple digital signatures for a transaction, payee entity or payee authorization for a transaction, and / or email-based payment transactions where the transaction is sent to an email address associated with an alias before being posted to the distributed ledger, payer and / or payee callback functionality related to a request or response, etc.

[0123] Instructions and / or specifications for accessing a public address (of an entity of a digital wallet) that can be used to effect a transaction with the entity or digital wallet associated with the alias. In some embodiments, accessing the public address includes accessing one or more resources or URIs associated with a payment service based on the alias. In some embodiments, once obtained, the public address may be used in an output script used in constructing transactions for a distributed ledger. In some embodiments, accessing the public address may include resolving the entity's public key based on PKI procedures and resolving the payment destination, i.e., the recipient digital wallet.

[0124] For example, the machine-readable resource may point to the following files or entries for the payment service "bsvalias":

number

[0125] The template values ​​{name} and {domain.tld} are in alias format. <name> @ <domain> . <tld>where tld is a top level domain such as .com or .org or .co.uk etc. The requesting entity or payment client may replace the template with an alias. So in the example above, this would be alice@nchain.com.

[0126] Step 304a involves storing the machine-readable resource in a predictable or known location associated with the payment service. For example, a payment service operator or processor for the payment service "bsvalias" may provide the document at the following location following generation of the JSON-formatted text document described above in step 302a: https: / / <host-discovery-target> : <host-discovery-port> / .well-known / bsvalias

[0127] It is useful to provide the JSON-formatted document in a well-known, predictable location so that it is publicly accessible by all entities that recognize the payment service (e.g., based on a network identifier). The exemplary location mentioned above is based on the IANA (Internet Assigned Numbers Authority) Well-Known URI resource. Thus, machine-readable resources are placed in predictable locations on web servers for discovery capabilities related to payment service bsvalias.

[0128] At step 306a, a request for a transaction is received from a payment client entity, the request including the alias to which the payment should be directed. Continuing with the example above, this would include a request such as payto:alice@nchain.com.

[0129] In step 308a, a payment service associated with the alias is identified. This is based on the network identifier in the alias, i.e., nchain. The payment service associated with this identifier, i.e., bsvalias, is identified in this step. Host discovery according to the first aspect to identify the service record may be performed before this, but this is not essential in the embodiment shown in FIG. 3. For example, a mapping stored in a database or a text document based on the service discovery process may be used to identify the host of bsvalias instead of the service record in the first aspect.

[0130] In step 310a, based on the identified payment service, a machine-readable resource for the payment service is accessed from a predictable or known network location. For example, a JSON document for service bsvalias is retrieved from a well-known location such as that specified in step 304a.

[0131] Step 312a determines whether one or more capabilities for the requested transaction are present in the machine-readable resource. This step includes identifying whether one or more entries related to supported capabilities are appropriate for the request. For example, this may include checking whether a common capability is supported by the requesting client entity's payment service and capabilities in the JSON document for bsvalias, the payment service for payee alice@nchain.com. In some cases, additional capabilities may not be specified or required by the requesting entity. In this case, the payment transaction can proceed regardless of whether the common capability is present.

[0132] In step 314a, assuming the machine-readable resource has at least one supported capability for the transaction (if this was specified by the requesting entity), once this is identified, an endpoint identifier associated with the payment service's host computing resource is returned from the machine-readable resource. In the example above, this may be the location of the host responsible for bsvalias. One or more of the instructions and / or specifications in the machine-readable resource for the payment service "bsvalias" can then be used to obtain a public address for the digital wallet associated with the alias.

[0133] FIG. 3B, as described above, relates to steps corresponding to FIG. 3A, but performed in the computing device or digital wallet of the payer or requesting entity.

[0134] Thus, step 306b involves sending a request for a transaction from the requesting entity, the request being associated with an alias, ie, continuing the example above, sending payto:alice@nchain.com.

[0135] In step 310b, following identification of the payment service based on the network identifier in the alias, e.g., as described in step 308a of FIG. 3A, this step includes accessing, by the requesting client, a machine-readable resource from a well-known location associated with the identified payment service, e.g., as described in step 304a of FIG. 3A.

[0136] Step 312a involves the requesting entity determining whether one or more capabilities for the requested transaction exist within the machine-readable resource. This step, similar to step 312a of Figure 3A, involves checking the JSON document to identify whether one or more entries related to common or specified supported capabilities are appropriate or required for the requested transaction.

[0137] In step 313b, based on identifying whether one or more capabilities exist in the machine-readable resource, the requesting client receives an endpoint identifier associated with a host computing resource for the payment service, i.e., a host location for the service bsvalias.

[0138] In step 314b, the requesting client then obtains the public address associated with the alias, which may be obtained by the requesting client performing a function according to one or more of the instructions and / or specifications in the machine-readable resource.

[0139] FIG. 4 illustrates an exemplary sequence of instructions specified in a machine-readable resource of a second embodiment for implementing public key infrastructure (PKI) techniques for obtaining a cryptographic key associated with an alias.

[0140] In step 402, a PKI request template from a machine-readable resource must be obtained from a machine-readable resource associated with the payment service. This template, in some embodiments, is a template for requesting a PKI endpoint identifier, which is a URI of a computing resource of the payment service that is configured to identify and / or verify the public key of a payment client entity. For example, continuing from the example above, the template might be: "pki": "https: / / bsvalias.example.org / {name}@{domain.tld} / id

[0141] In step 404, once the template is received, the alias and associated network identifier are included or substituted into the appropriate fields of the template to generate the complete PKI request. For example, the template values ​​{name} and {domain.tld} are used to represent the alias, i.e. <name> @ <domain> . <tld>This represents a component of the `bsvalias` and must be populated before issuing a complete request based on the machine-readable resource. The result of this step is the provision of a PKI endpoint identifier for `bsvalias`.

[0142] In step 406 , an HTTP GET request is generated based on the PKI endpoint identifier obtained in step 404 .

[0143] In step 408, the public key associated with the alias may then be obtained in response to the request generated in step 406. Often the public key will be a stable elliptic curve digital signature algorithm (ECDSA) public key that has not been used as part of an on-chain transaction. If a request for a valid alias, i.e., one that is associated with a payment service and has been assigned a public key, is received, the response message from the host responsible for the payment service's PKI may return the public key in the following format:

number

[0144] The ECDSA public key is a valid point on the secp256k1 curve, compressed and hex-encoded, which means the "pubkey" string is 66 bytes long (33 binary bytes, each byte encoded as 2 hex characters). [Table 2]

[0145] If the request is based on an alias that is not valid, i.e., one that is not associated with a payment service and / or public key, the response message indicates that an error has occurred or that the requested resource is not found, not available, or not authorized.

[0146] 5A and 5B are flow diagrams illustrating a method according to a third aspect of the present disclosure for identifying a payee associated with an alias in a request for a transaction. The payee is used in structuring the transaction for a distributed ledger. FIG. 5A illustrates a method implemented by one or more processors associated with a payment service. FIG. 5B illustrates a method implemented by one or more processors associated with a payment client entity. In some embodiments, obtaining the payee is based on or part of obtaining a public key associated with the alias in FIGS. 3A and 3B. In some embodiments, the payee endpoint identifier is associated with an address to be encoded or included in the output script, so that the transaction may be constructed for the blockchain based on this address. In some embodiments, the payee endpoint identifier is the same as the public address described above. In other embodiments, the payee endpoint identifier may be different from the public address associated with the alias or may be part of or associated with the public address for the digital wallet. In some embodiments, the public address and / or payee endpoint identifier associated with the alias may be assigned statically or dynamically.

[0147] Step 502a of Figure 5A involves identifying a payment service within the alias followed by accessing a machine-readable resource for the payment service. The identity of the payment service, along with the location of the machine-readable resource, may be obtained as described above in connection with Figures 1, 3A and / or 3B.

[0148] In step 504a, a payee endpoint identifier is obtained from a machine-readable resource using one or more instructions and / or specifications in the machine-readable document, which may be a URI of a computing resource or server of a payment service configured to resolve a payee endpoint of a digital wallet associated with the alias.

[0149] In step 506a, payment details for the payment transaction are obtained from the paying entity. For example, this may include at least an alias associated with the payee entity's digital wallet and the amount of cryptocurrency to be paid to the payee. This may be provided using an interface associated with the payer entity's computing resources or application.

[0150] In step 508a, a digital signature for the request with payment details in step 506a and a cryptographic key associated with the payer entity is obtained. This signature associated with the request related to the transaction is often applied using the private key of the requesting, i.e., payer entity.

[0151] In step 510a, the digital signature may be verified so that the identity of the payer entity can be authenticated. This may be performed using one or more known techniques. In some embodiments, assuming ECDSA keys are used, the payer entity's public key, obtained using, for example, the PKI sequence of FIG. 4, can be used to verify the identity of the signing entity (the payer entity). If verification fails, the digital signature may need to be provided again, or one or more error messages may be generated.

[0152] In step 512a, following the successful validation output in step 510a, an output script based on the payee endpoint identifier associated with the alias is generated, and the output script is provided for embedding into a payment transaction for the distributed ledger to automatically resolve the payee in the transaction for the distributed ledger.

[0153] For example, the output script returned for the composition of a transaction before t on a distributed ledger, i.e., the Bitcoin blockchain, may follow the formula:

number

[0154] The value of the output field may be hex-encoded Bitcoin script, which the payer entity uses while composing the payment transaction.

[0155] Although various possible types of output scripts may be generated, for ease of explanation, Pay to Public Key Hash (P2PKH) output script generation is discussed in the following example.

[0156] Given a key pair with the public key:

number

[0157] The P2PKH output script for the same may be hex-encoded as follows:

number

[0158] This can be broken down as follows:

number

[0159] The service response body, i.e., the script to embed into the transaction in step 512a, is therefore as follows:

number

[0160] FIG. 5B, as described above, relates to steps corresponding to FIG. 5A, but performed in the computing device or digital wallet of the payer or requesting entity.

[0161] In step 502b, a request for a transaction from a payer entity, the request being based on a request associated with the alias, and a machine-readable resource is accessed by the payer entity from a location associated with the payment service.

[0162] In step 504b, a payee endpoint identifier based on one or more instructions and / or specifications in the machine-readable document is obtained by the payee entity.

[0163] Step 506b involves transmitting or providing payment details for the transaction, including the alias associated with the payee entity's digital wallet and the cryptocurrency amount to be paid to the payee.

[0164] Steps 508b and 510b relate to the payer entity providing a digital signature to associate the payment details with the cryptographic key, followed by verification as discussed in the corresponding steps of Figure 5A.

[0165] Step 512b relates to receiving an output script by the payer entity based on a payee endpoint identifier associated with the alias, as described above in relation to Figure 5A.

[0166] Step 514b involves constructing a payment transaction for the distributed ledger by the payer entity by embedding the received output script into the transaction.

[0167] FIG. 6 illustrates an example sequence of instructions specified in a machine-readable resource that implements a payee endpoint resolution sequence associated with an alias for a digital wallet.

[0168] At step 602, a payee request template from a machine-readable resource is obtained from a machine-readable resource associated with the payment service. In some embodiments, this is a template for requesting a payee endpoint identifier as discussed in Figures 5A and 5B. For example, continuing from the example above for payment service bsvalias, the template may be: "paymentDestination":https: / / bsvalias.example.org / {name}@{domain.tld} / payment-destination

[0169] Once the template is received in step 602, the alias and associated network identifier are included or substituted into the appropriate fields of the template to generate a complete payee request in step 604. For example, the template values ​​{name} and {domain.tld} are used to generate the target alias, i.e. <name> @ <domain> . <tld>and must be populated before issuing a complete request based on the machine-readable resource. The result of this step is the provision of a payment endpoint identifier, which in some embodiments may be the URI of a computing resource responsible for identifying the payment address to be used for generating the output transaction associated with the alias.

[0170] In step 606 , an HTTP POST request is generated based on the payee endpoint identifier obtained in step 604 .

[0171] In step 608, an output script based on the payee endpoint identifier associated with the alias is returned, which is also used in constructing payment transactions for the distributed ledger, as discussed in Figures 5A and 5B.

[0172] In some embodiments related to the third aspect described above, the body of a request for a payee according to the third aspect (e.g., a request related to steps 502a, 502b, or the POST request of FIG. 6 described above) may indicate a content type of application / json. This is because the template for generating or completing the request is based on a machine-readable resource for the payment service, i.e., bsvalias. In some embodiments, as described above (see, e.g., FIG. 6), in addition to identifying the alias of the payee entity in the request, the request from the payer entity may conform to the following schema:

number

[0173] The fields of the above schema are briefly described in the table below, with further explanation of some of the fields provided below. [Table 3]

[0174] In some embodiments, it is sufficient that the field identified as payerHandle in the above schema is present or associated with the request in addition to containing the payee entity's alias. In some embodiments, if the payer entity or digital wallet associated with the payer client does not have an alias for the payment transaction, this payerHandle may simply be associated with the payer's public identifier or IP or Bitcoin address. In the following, the payerHandle in this disclosure will be described as being an alias associated with the payer client entity. Thus, in such embodiments, the payer entity has an alias and is associated with a payment service that facilitates the payment transaction based on that alias. The payer's payment service may be the same as or different from the payee's payment service.

[0175] In some embodiments, the timestamp field, denoted by "dt" in the table above, and the payerHandle may be required in the schema for the request. In other embodiments, the timestamp, payerHandle, and signature fields may be required for a particular request or to act according to one or more capabilities that may be present in machine-readable resources associated with the payee client.

[0176] The remaining fields may be optional as far as the function or operation of the request is concerned. However, in many situations, a quantity is usually indicated (even if it is zero). However, optional fields or non-zero values ​​for optional fields may be present in the request if they are known or if the information is available to the payment entity, in this case the payer entity. The timestamp and signature fields may be considered mandatory for certain payment service capabilities specified in the machine-readable resource and are described below.

[0177] The timestamp field "dt" may contain the current time in standard ISO-8601 format accepted at the time the payer initiated the payee request. From JavaScript, this can be constructed using commands or instructions associated with machine-readable resources such as JSON.stringify(). For example, it may return the following:

number

[0178] In some embodiments, the signature field may be based on the ability of the payment entity or client to sign messages and verify message signatures. This functionality is often essentially a standard ECDSA implementation, but with an (r,s) signature pair for integers r and s, with additional information provided to allow the client to verify message signatures against a P2PKH address (a hash of the public key) rather than directly against the public key.

[0179] In some embodiments, the signature may be the raw (r, s) fields computed over a double-SHA256 hash of the message, in this case the request described above. Existing signing and verification protocols may be appropriate for some embodiments to take advantage of existing Bitcoin client libraries, such as MoneyButton's BSV library, or other similar cryptocurrency libraries.

[0180] In some embodiments, the MoneyButton BSV library implementation nominates a standard message digest construction and signature encoding method for signatures included in payee requests. The message or request to be signed may begin with the traditional or known preamble of the Bitcoin signature scheme (as may be documented in the BSV library source code), followed by a Unicode Transformation Format-8-bit (UTF8) string concatenation of the fields payerHandle and dt, and optionally the amount and purpose fields discussed in the example schema above.

[0181] Regarding the specification of quantities in a request, based on the above schema, in some embodiments the following rules may apply:

[0182] If a quantity is present, it is converted to a string (without leading zeros).

[0183] If the amount is not present, the string "0" is used.

[0184] If no purpose is present, the empty string "" is used (effectively no purpose is included in the message).

[0185] Figure 7 is a flow diagram illustrating a method for updating capabilities for a payment service, which method is applicable to one or more of the second through fifth aspects described above. This figure relates to a method performed by one or more processors associated with the payment service described above in connection with the first implementation of the fourth aspect.

[0186] In step 702, a machine-readable resource associated with a payment service, such as bsvalias as described above in the example embodiment, is accessed. Such access may be performed by a host responsible for the payment service. In some embodiments, access to make updates or changes may be limited to the responsible host.

[0187] In some embodiments, the machine-readable resource may be generated and accessed from a well-known location associated with the payment service based on an alias for one or more payment clients of the payment service, as described above with respect to the second aspect, which is described in more detail with respect to Figures 3A and 3B.

[0188] In step 704, at least one further capability supported by the payment service below (and thus such capability is provided to all payment clients associated therewith) is added to the machine-readable resource. Such addition may be made by a host responsible for the payment service. As discussed with respect to the second aspect, a capability or entry in the machine-readable resource is a set of one or more protocols to follow, or a specification or executable file or instructions for implementing the respective capability for one or more clients associated with the payment service. A client is a payment entity, such as a payer or payee entity or node, involved in a transaction.

[0189] In some embodiments, an update in this step may simply be a change of a value or field related to the implementation of the capability. Thus, if the payment service bsvalias already has a capability specification in a machine-readable document, but the value is set to "false" or "0" because the capability is not yet ready to be deployed by bsvalias to its clients, or if a change or version update is in progress that should be terminated, then updating this to "true" or "1" would be considered an update in this step.

[0190] For example, to add a new capability such that the payment service bsvalias supports future payer verification for all future cryptocurrency transactions for all clients or digital wallets associated with bsvalias, the machine-readable resource for bsvalias (which is in JSON format, as described above in the second aspect) may be updated to include the following entry or schema for the payer verification capability:

number

[0191] The path capabilities.payervalidation, or any other identifier such as c318d09ed403, is thereby included in the machine-readable resource and, in some embodiments, is set to the value "true" to identify that payer validation is performed. This capability is further discussed in connection with the fourth aspect.

[0192] In some embodiments, the value field is not present. In this case, the inclusion of the above entry or schema may be sufficient to mean that payer verification is performed. In some embodiments, if the value field is present, any value other than "true" may be considered equivalent to "false," indicating that payer verification is not performed.

[0193] Similarly, if another capability such as asynchronous request processing is added during the update in step 704, separately or in addition to payer verification, the following entry is added to include a declaration of support for asynchronous processing in the machine-readable resource for bsvalias:

number

[0194] The capabilities.da377cdc9ae7 path or object in the JSON document for asynchronous request processing does not include a value field. In this example, this capability is understood to be supported by bsvalias hereafter simply by adding the above specification. The above also includes a callback property with a template endpoint URI containing the incoming payee callback request. This is discussed further in relation to the fifth aspect.

[0195] Figure 8 is a flow diagram illustrating a method for performing payer entity verification for a payment service such as bsvalias according to a fourth aspect. The method is performed based on one or more instructions, protocols, or rules specified in a capability entry for payer verification described above in Figure 7 when the capability is performed by the payment service for its client. The method relates to one or more of the second and third aspects described above, and relates to a method performed by one or more processors associated with the payment service described above in connection with the second implementation of the fourth aspect.

[0196] At step 802, a request is received, the request being from a payer entity and associated with an alias of a payee entity associated with a payment service.

[0197] For example, a request may include the alias "alice@nchain.com"; continuing with the previous example, the payment entity or digital wallet payment service associated with such alias is bsvalias. Henceforth, the digital wallet for this alias is referred to as the payee client (to identify that this payment entity is a client of bsvalias). The payer entity sending the request may or may not be associated with a payment service. In this case, the payer entity is identified simply by its public address for cryptocurrency transactions. If the payer entity is associated with the same payment service as the payee client, it may be represented using the alias "bob@nchain.com." It is also possible for the payer entity to be associated with an entirely different alias based on the payment service, i.e., "notbsvalias," which has a different machine-readable resource specifying its own capabilities entity. In this case, the payer entity's alias may be "bob@notnchain.com."

[0198] Hereinafter, for ease of explanation for all implementations and embodiments of the fourth and fifth embodiments, the alias "bob@nchain.com" will be considered as an alias for a payer entity that implements the same payment service, i.e., bsvalias, as the payee client, and therefore the same set of capabilities based on the same JSON document or machine-readable resource. However, it will be understood that the present disclosure is not limited to the implementations as described above.

[0199] In some embodiments, this request may be based on an HTTP POST request associated with a payee request template for bsvalias, such as that described with respect to FIG.

[0200] In step 804, a public key associated with the payer entity is obtained by one or more processors associated with the bsvalias payment service, which may be obtained using an HTTP GET request based on a machine-readable resource for bsvalias, as described with respect to FIG.

[0201] In step 806, it is determined whether one or more predetermined conditions are met for the payer verification capability performed by bsvalias for alice@nchain.com. In the embodiment discussed in this figure, two conditions are evaluated, the first being public key verification for the payer entity. However, as noted above, the predetermined conditions may be based solely on these conditions or may include additional conditions (such as based on a one-time token). In the embodiment of the present application discussed, the request should be digitally signed with bob@nchain.com's private key, which can only be used together with the public key linked to bob@nchain.com's private key, i.e., part of the same cryptographic key pair. As a result, the request can be read, i.e., verified, retrieved, or decrypted, using the public key. Therefore, in this step, it is checked whether the digital signature in the request from bob@nchain.com is verified with the public key retrieved in step 804.

[0202] If the request does not include a digital signature, or if the digital signature cannot be verified using the public key obtained in step 804, this indicates that the request includes a digital signature that is not associated with the payer entity. The request is therefore rejected in step 810 because the identity of the payer entity is invalid or cannot be verified. In some embodiments, a response may be generated for the payer entity indicating that the request is rejected, unauthorized, or not permitted. As discussed above, this improves the security and reliability of transactions involving clients of the payment service, since the identity of the payer entity and the integrity of the content of the request can be verified based on the steps described above. The applied digital signature may, in some embodiments, be based on lightweight Bitcoin message signatures, as discussed above in connection with the exemplary schema of a request associated with a payee.

[0203] If the result of step 806 is that the digital signature in the request is verified based on the public key obtained in step 804 for the payer entity bob@nchain.com, this confirms that the request is coordinated from the payer entity bob@nchain.com. In step 808, it is then determined whether the request satisfies the second of the two predetermined conditions of the payer verification capability. The second condition in step 808 checks whether the request includes a timestamp that is within a predetermined period of the receipt time at the payment service. The receipt time is based on the clock of the payment service. This period may be set in the payer verification capability. For example, this predetermined period may be two minutes to allow some time for synchronization and message transmission timing issues or delays. Other periods may be possible, and this step is not limited to a two-minute period.

[0204] If the request does not include a timestamp, or if the timestamp is not within a predetermined period, then in step 820 the request from the payer entity is rejected or deemed invalid. As noted above, this improves security and reliability by protecting clients of the payment system against message replay or man-in-the-middle attacks by verifying the timestamp. Thus, the request schema described above in connection with the third aspect includes at least the "dt" and "signature" fields if payer verification capabilities are implemented in accordance with this embodiment. In other embodiments, conformance or satisfaction of one of the above conditions is sufficient for payer verification, although it is often desirable for both conditions to be met.

[0205] In step 812, if both conditions are met, i.e., if the digital signature is associated with the obtained public key and the timestamp is within a predetermined period, the payer entity is considered to have been successfully verified, thereby indicating that the request for the payee can be processed.

[0206] An output script associated with the payee client alias, i.e., payee of alice@nchain.com, is then generated in step 814. This may be similar to the generation of the output script discussed in connection with Figure 5A.

[0207] In step 816, a digital signature associated with the payee client is applied to the Output Script. Similar to the signature described above for the payer entity in step 806, here the private key of the cryptographic key pair for alice@nchain.com is used to sign the Output Script, making it retrievable using the public key of the same key pair. This ensures that the Output Script has not been tampered with in transit and helps the payer entity verify the origin of the Output Script.

[0208] So the schema for the output script to be sent might be:

number

[0209] In step 818, the signed output script is sent to the payer entity bob@nchain.com, where once decrypted or retrieved or verified, the output script can be embedded into a transaction for the distributed ledger.

[0210] 9 is a flowchart illustrating a method according to a third implementation of the fourth aspect relating to implementing payer verification capabilities for one or more payment entity clients associated with a payment service. In this case, the illustrated method is performed by one or more processors associated with the requesting entity, the payer entity. Thus, the method relates to the first implementation of the fourth aspect discussed in FIG. 8, but continues from the same example, to implementation by the payer entity, i.e., bob@nchain.com.

[0211] In step 902, an alias-associated request is generated, the request relating to a payee client, i.e., a payee of alice@nchain.com, among one or more clients associated with the bsvalias payment service, where the request includes the alias of the payee client.

[0212] A digital signature associated with the public key of the payer entity bob@nchain.com is applied to the request in step 904. The process of applying the digital signature is similar to that described above with respect to steps 806 or 816 of Figure 8, or with respect to the lightweight Bitcoin message described in the third aspect above where the request schema was discussed, except that here the signature is applied using the payer entity's key, i.e., the private key of bob@nchain.com in the example above.

[0213] In step 906, the payer entity accesses a machine-readable resource associated with the payment service for the alias. Thus, in this step, a JSON document or machine-readable resource associated with bsvalias is accessed based on the alias alice@nchain.com. Methods associated with such access are described above in connection with the second aspect.

[0214] At step 908, the signed request is then transmitted based on one or more instructions and / or specifications in a machine-readable resource associated with the payee. In some embodiments, the request is an HTTP POST request, and the instructions and / or specifications are based on a payee request template such as discussed with respect to Figure 6 of the third aspect. The request, in some embodiments, includes a timestamp indicating the date and time of transmission. This is similar to Figure 8, where it was discussed that signature and timestamp fields are required to implement the payer entity verification capability.

[0215] An output script associated with the requested payee for alice@nchain.com is received by the payer entity at step 910. As described above with respect to step 806 of Figure 8, this output script includes a digital signature associated with the payee client alice@nchain.com.

[0216] In step 912, it is checked whether the digital signature verifies correctly or is associated with the recipient entity's public key. For this, the public key associated with the recipient client alice@nchain.com must first be obtained. In some embodiments, this is based on an HTTP GET request using the bsvalias machine-readable document as discussed in connection with Figure 4 of the second aspect. The digital signature is then verified based on this obtained public key.

[0217] In step 914, if the digital signature can be verified or validated or decrypted using the obtained public key, the Output Script is confirmed to have originated from the Payer Entity without tampering or malicious interference, in which case the Output Script is embedded in a transaction for the distributed ledger, and the transaction is associated with the Payer Entity and the Payee Client.

[0218] On the other hand, if the digital signature is not associated with the obtained public key or the output script cannot be obtained using the obtained public key, then in step 916 the output script is rejected, the transaction is not constructed, and neither the identity of the sender, in this case the recipient client alice@nchain.com, nor the integrity of the contents of the script can be verified.

[0219] Figure 10 is a flow diagram illustrating a method for implementing asynchronous request processing (or delayed or discontinuous processing) for a payment service such as bsvalias. The method is implemented based on one or more instructions, protocols, or rules specified in a capability entry for asynchronous request processing described above in Figure 7 when the capability is implemented by the payment service for its clients. The method is related to one or more of the second, third, or fourth aspects described above. This figure relates to a method implemented by one or more processors associated with the payment service described above in connection with the first implementation of the fifth aspect.

[0220] In step 1002, a request associated with an alias from a payer entity is received, the request relating to a payee of a payee client associated with the payment service. Continuing from the previous example, it is understood that the request from payer entity bob@nchain.com includes the alias alice@nchain.com (payee client), where alice@nchain.com is associated with the payment service bsvalias. In some embodiments, the request is an HTTP POST request, as described with respect to FIG. 6 of the third aspect, using a payee request template based on the machine-readable resource of bsvalias.

[0221] In step 1004, a token unique to the received request is generated. In some embodiments, the token is a unique identifier, such as one based on a random number generator, where no two requests are ever assigned the same token. The token may be based on a particular seed or function associated with the request. In some embodiments, the token may be a hash value of one or more components of the request itself.

[0222] In step 1006, this token is sent to the payer entity, just like an acknowledgment of receipt. In this embodiment, it is understood that a token is generated for every request received for a payment client, such as alice@nchain.com, where the payment service bsvalias implements asynchronous request processing capabilities. In other embodiments, such a token may be generated only if the payee client does not respond for a predetermined period of time, i.e., 5 or 10 minutes after receiving notification of the request. In some embodiments, as described above with respect to the fourth aspect, a digital signature may be applied based on the public key of the payee entity, i.e., alice@nchain.com, to ensure the origin and security and integrity of the token. A schema for the content sent to the payer entity, including the token, may be as follows:

number

[0223] At step 1008, a notification regarding the received request is sent to the payee client alice@nchain.com, which may be sent even if the payer client is not connected to the internet or is offline or powered down or inactive or unresponsive at the time the notification is sent.

[0224] In step 1010, it is determined whether alice@nchain.com has approved or rejected the notification using a user interface or indicator on the communication terminal, and accordingly sends a response indicating this to bsvalias. This response from the recipient entity may arrive immediately or some time after sending the notification. For example, in this embodiment, it could be up to two days, although the present disclosure is not limited in this respect, as the period of inactivity may be longer.

[0225] If a denial of the request is received in response from the payee client, a denial notice or record is generated for the request in step 1018. In some embodiments, the result, i.e., a denial notice, is sent to the payer client in step 1120. A notice may not be sent in some other situations where it is sufficient for the denial to simply be recorded in association with the request.

[0226] In step 1012, if authorization for the request is received, an output script associated with the payee client alice@nchain.com is generated. The steps for generating the output script may be similar to those described in connection with Figure 5A of the third embodiment.

[0227] At step 1014, a callback request is generated that includes the token and the generated output script. This is called a callback request because of the presence of a unique token that can be used to correlate the output script to the correct request, regardless of the range of numbers or time of other messages or requests processed in connection with bob@nchain.com or alice@nchain.com. In some embodiments, this callback request may be signed, i.e., a verifiable digital signature is applied based on alice@nchain.com's public key. In some embodiments, the callback request may be based on an HTTP POST request as discussed in FIG. 6 of the third aspect, but with the additional provision of a token in a template associated with the asynchronous request processing capability discussed with respect to FIG. 7. This may be obtained from a machine-readable resource for bsvalias, the payment service for alice@nchain.com and bob@nchain.com, although the payer entity may have a different payment service. For example, a capability entry for asynchronous processing may be:

number

[0228] Thus, here, the identifier for this capability may be a reference to a capabilities.da377cdc9ae7 object, which includes a callback property with a template endpoint URI for the payee request callback. The callback request is then based on this, in some embodiments, the payee request template of FIG.

[0229] In step 1016, the callback request is provided to the payer entity along with the token and the output script. The token is used to correlate the output script to the request, and further for this correlation, the output script can be embedded in a transaction for the distributed ledger. The schema of the callback request may be as follows:

number

[0230] The token here is the same token that was sent in step 1006 .

[0231] 11 is a flowchart illustrating a method according to a second implementation of the fifth aspect relating to implementing asynchronous request processing capabilities for one or more payment entity clients associated with a payment service. In this case, the illustrated method is performed by one or more processors associated with a requesting entity, the payer entity. Thus, the method relates to the first implementation of the fifth aspect discussed in FIG. 10, but continues from the same example, relates to implementation by the payer entity, i.e., bob@nchain.com. In some embodiments, the method discussed in connection with FIG. 9 for implementing payer entity verification capabilities may also be included.

[0232] In step 1102, an alias-associated request is generated, the request relating to a payee client, i.e., payee alice@nchain.com, among one or more clients associated with the payment service bsvalias. Here, the request includes the payee client's alias. In some embodiments, particularly if the payer verification capabilities of the fourth aspect are also implemented, the request may be digitally signed to include a signature as described above in the request schema. Once generated, the request is sent by the payer entity bob@nchain.com to the bsvalias payment service for the payee client alice@nchain.com. The request may be sent using an HTTP POST request as discussed in connection with FIG. 6 of the third aspect.

[0233] In step 1104, a token is received from the payment service bsvalias by one or more processors of a digital wallet or device for the payer entity bob@nchain.com. This token, in some embodiments, may be the same as or related to the token generated in steps 1004 and 1006 of Figure 10. Thus, the token is unique to the request and is associated with a digital signature that can be verifiable based on the public key of alice@nchain.com.

[0234] In step 1106, it is determined or verified whether the digital signature associated with the token is associated with the public key of the recipient client alice@nchain.com. In some embodiments, such verification includes retrieving the public key, for example, based on an HTTP GET request using a PKI template in the bsvalias machine-readable resource, and verifying that the retrieved key is associated with a digital signature (typically applied with the private key of the same key pair) that can be used to retrieve, decrypt, or decrypt the digital signature to obtain the token.

[0235] If the digital signature cannot be verified using the retrieved public key of alice@nchain.com, the token is rejected in step 1110 and the request is not processed.

[0236] If the digital signature is successfully verified, then in step 1108, a record or database associated with the payer entity bob@nchain.com is updated so that the token is linked to the respective request. This is so that any further messages or requests associated with this token can be correctly and quickly identified when they are received at a later time in an asynchronous manner. Such a record may be stored locally in one or more memory modules associated with the payer entity, or may be stored on a server or in association with the payer entity's payment service. Thus, the record may be located or stored anywhere before and after the update, as long as it is associated with the payer entity bob@nchain.com.

[0237] In step 1112, a callback request is received from the bsvalias payment service of the payee client alice@nchain.com. This callback request is provided after the payee client authorizes the request, and thus arrives asynchronously or in the order in which such authorization is received by bsvalias. The callback request includes the same token as in step 1104 and also includes an output script in response to the request, which is associated with the requested payee for alice@nchain.com. The callback request may be similar to the callback request generated in step 1014 of FIG. 10 and may also be associated with a digital signature. This callback request may be an HTTP POST request based on a template in a machine-readable resource for the bsvalias payment service of the payer entity bob@nchain.com.

[0238] In step 1114, the digital signature in the callback request is verified. Such verification may be similar to the process discussed in step 1106. Once verified, the output script and token can be obtained.

[0239] If verification based on the public key of alice@nchain.com fails, the callback request is rejected and no output script is generated in step 1120.

[0240] If the verification at step 1114 is successful, the token and output script are obtained by the payer entity. At step 1116, the token in the callback request is correlated with each request in the updated record discussed at step 1108. This therefore allows the correct request to be matched with the output script using the token.

[0241] Once the request is identified in the updated record based on the token, the output script can be used in step 1118 to compose a transaction by the payer entity for the distributed ledger, and the transaction is associated with the payer entity and the payee client.

[0242] 12 is a flowchart illustrating a method according to a third implementation of the fifth aspect relating to implementing asynchronous request processing capabilities for one or more payment entity clients associated with a payment service. In this case, the illustrated method is performed by one or more processors associated with a payer entity, which is the destination entity. Thus, the method relates to the first implementation of the fifth aspect discussed in FIG. 10, but continues from the same example, relates to implementation by a payee client, i.e., alice@nchain.com.

[0243] In step 1202, a notification related to a request associated with the alias of the payee client is received. Similar to the embodiment described above, the request related to the received notification is related to a payee of the payee client alice@nchain.com. The notification is sent by the payee client's payment service bsvalias. If the payee client is offline or unavailable or powered down, the notification is provided on an interface associated with the digital wallet for alice@nchain.com once it is online or operational again.

[0244] In step 1204, the recipient client interacts with the notification to approve or deny. Such interaction may be by clicking a button or displayed object on a user interface, or by using a particular combination of keys on an input interface associated with the recipient client's user interface to indicate that the response is one of approve or deny.

[0245] If the response is one of approval at step 1206, then this is sent by the payment service bsvalias. If the response is instead one of denial at step 1208, then such a denial response is sent to bsvalias, or alternatively, the payee simply remains unresponsive until the end of a predetermined period, e.g., two days, after which the payment service simply records that the notification was not responded to or approved. In some embodiments, this then prompts a denial at steps 1018 and 1020 of Figure 10.

[0246] FIG. 13 illustrates an exemplary sequence of instructions specified in a machine-readable resource associated with a payment service, such as bsvalias, described above, for performing public key verification. This is alternatively referred to as public key owner verification for cryptographic keys associated with an alias. This is based on the ability to check that the key in the request actually relates to the alias or the payment entity or digital wallet associated with the alias. Often, the key to be checked is the public key of an asymmetric key pair that further includes a private key to verify the owner of the public key. This public key may already be known or previously obtained or cached by the payment entity or client sending the request. The embodiment discussed in connection with FIG. 13 may be included in or related to any of the second through fifth aspects of the present disclosure described above.

[0247] In step 1302, a public key verification request template is obtained from a machine-readable resource associated with the payment service. This template is a template for requesting a key verification or verification endpoint identifier, which is a URI of a computing resource of the payment service configured to identify and / or verify keys of payment entities. For example, continuing from the example above, the template may be based on the following capabilities or instructions in the machine-readable resource for bsvalias associated with the public key owner verification endpoint:

number

[0248] In this example, the capabilities.a9f510c16bde reference is a template URL for verifying ownership of a "public key." The public key may already have been obtained using the method discussed in Figure 4.

[0249] Once the template is received in step 1302, in step 1304, the alias of the destination entity, i.e., payee client or payer entity, is included or substituted into the appropriate fields of the template to generate a complete public key verification request, which may also be referred to as a key verification request. For example, the template values ​​{name} and {domain.tld} are used to generate the alias, i.e., <name> @ <domain> . <tld>and must be populated before issuing a complete request based on the machine-readable resource, i.e., the recipient client's alias, alice@nchain.com. The result of this step is the provision of a public key verification endpoint identifier for alice@nchain.com's payment service, i.e., bsvalias.

[0250] In step 1306 , an HTTP GET request is generated based on the endpoint identifier obtained in step 1304 .

[0251] At step 1308, a response associated with the alias is then obtained in response to the GET request generated at step 1306. In many cases, this may simply be an indication that the public key matches or has been verified for the alias indicated in the request. In some embodiments, the verification process may be performed by a key management server associated with managing all cryptographic keys and key pairs for the payment service bsvalias. For example, the key management server may maintain an up-to-date record or lookup table containing details of all current and valid public keys for each client of the bsvalias payment service. As discussed above and in relation to FIG. 4, the public key may be an ECDSA (elliptic curve digital signature algorithm) public key.

[0252] If the key in the request is valid for the alias in the request, i.e. the owner of the key is indeed the payment entity associated with the alias in the request, the response from the host responsible for public key verification of the payment service may be in the following format:

number

[0253] If the "pubkey" in the request is not valid for the alias in the request, i.e., is not associated with that alias, or may have been valid in the past but is at least no longer valid for that alias, then the "match" field in the response message may indicate the value "false." In some embodiments, the response in this case may simply indicate that an error has occurred, or that the requested resource is not found or is not available or is not authorized.

[0254] Referring to FIG. 14 , an illustrative simplified block diagram of a computing device 2600 is provided that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems described above. For example, the computing device 2600 may be configured for use as a web server or one or more processors or computing devices associated with a payment service or payment client entity, i.e., to implement a host responsible for providing a payment service, or to implement a payer or payee payment client entity. Accordingly, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 14 , the computing device 2600 may include one or more processors with one or more levels of cache memory and memory controller (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read-only memory (ROM) 2620, as shown. The storage subsystem 2606 and cache memory 2602 may be used for storing information such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functionality of any embodiment as described in this disclosure.

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

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

[0257] The network interface subsystem 2616 may provide an interface to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may act as an interface to receive data from and send data to other systems on 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 without having to be in a remote location, such as a data center.

[0258] User interface input device(s) 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 touchscreen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to encompass all possible types of devices and mechanisms for inputting information into computing device 2600.

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

[0260] The storage subsystem 2606 may provide a computer-readable storage medium that stores the basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions), which, when executed by one or more processors, provide the 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 also provides a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage of programs and data and may include a magnetic hard disk drive, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blue-Ray) associated with 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 and data associated with the transactions and blocks described in this disclosure.

[0261] Computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device connectable to computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device connectable to 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 are transmitted to computing device 2600 through the ports connecting the device for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 14 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than the system shown in FIG. 14 .

[0262] It should be noted that the above-described embodiments illustrate, rather than limit, the present disclosure, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the present disclosure, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprising", "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, "comprising" means "having or consisting of", and "comprises" means "including or consisting of". A singular reference of an element does not exclude a plural reference 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.

[0263] The present disclosure will now be discussed based on the following sections relating to first to third aspects, which are provided as exemplary embodiments to better explain, describe, and understand the aspects and embodiments claimed herein. Item 1. A computer-implemented method for performing payment services for one or more clients for transactions associated with a distributed ledger, the method comprising: providing an alias for a given client among the one or more clients, the alias being unique to the given client, the alias including or associated with a network identifier; associating the alias with the network identifier in a directory; Including, The associating step includes: generating a service record based on the network identifier in the directory; updating the service record to indicate that the payment service is provided by the network or domain associated with the network identifier; updating the service record to indicate the location of a host computing resource responsible for the payment service, the host computing resource being configured to provide identification of a digital wallet associated with the alias in response to a request for a transaction related to the alias; A method comprising: (Item 2) The method of item 1, wherein each client of the one or more clients is associated with a digital wallet. (item 3) performing a search of the directory based on the alias in response to a request from a requesting entity related to a transaction associated with the alias; identifying the service record for the payment service in the directory associated with the network identifier; returning the location of the host computing resource for the payment service, wherein a public address of the client associated with the alias is determined based on the returned location, and the public address is used in the transaction; Item 3. The method according to item 1 or 2, comprising: (Item 4) A method relating to transactions for a distributed ledger, wherein an alias is provided for a given client among one or more clients, the alias being unique to the given client, and the alias including or associated with a network identifier, the method comprising: sending, from a requesting entity, a request related to a transaction, said request being associated with said alias; obtaining a location of a host computing resource associated with a payment service, said location based on a service record associated with said network identifier identified in a directory search; Including, A public address of the client associated with the alias is determined based on the location, and the public address is used in the transaction. (Item 5) The method of item 4, wherein each client of the one or more clients is associated with a digital wallet. (Item 6) A method described in any of Items 1 to 5, wherein the step of returning the location of the host computing resource includes a step of returning a target and port pair, wherein the target includes an identifier of the host computing resource and the port includes an identifier of an Internet Protocol communication port used by the payment service. (Item 7) A method according to any of items 1 to 6, wherein the host computing resource is associated with a payment network different from the network associated with the network identifier of the alias, and the payment services for one or more entities registered with the network are delegated to a payment domain associated with the payment network. (Item 8) A method according to any one of items 1 to 7, wherein the host computing resource is associated with a payment network, and the domain of the payment network is the same as the domain of the network associated with the network identifier of the alias. (Item 9) A computer-implemented method for performing payment services for one or more clients for transactions associated with a distributed ledger, the method comprising: generating a machine-readable resource associated with the payment service, the machine-readable resource comprising: at least one endpoint identifier associated with a host computing resource responsible for implementing the payment service for each client, wherein each client is associated with an alias, the alias including or related to a network identifier; and an entry associated with at least one capability among a plurality of capabilities supported by the payment service; instructions and / or specifications for accessing or obtaining a public address associated with said alias, said public address being used to effectuate transactions associated with said alias; and and providing the machine-readable resource at a predictable or known location associated with the payment service; A method comprising: (Item 10) The method of item 9, wherein each client of the one or more clients is associated with a digital wallet. (Item 11) The plurality of capabilities are as follows: Payer entity or payee entity verification; Multiple digital signatures for transactions, Recipient entity authorization for the transaction; Payment transactions related to email protocols; and / or a callback request or response, Item 11. The method according to item 9 or 10, comprising one or more of the following: (Item 12) A method according to any one of items 9 to 11, further comprising determining a location of a host computing resource by the method according to any one of items 1 to 5, wherein the endpoint identifier in the machine-readable resource is based on the determined location. (Item 13) In response to receiving a request from a requesting entity related to a transaction associated with the alias, the method includes: identifying the payment service associated with the alias based on the network identifier associated with the alias in the request; accessing the machine-readable resource from the predictable or known location based on the identified payment service; returning from the machine-readable resource an endpoint identifier of the host computing resource for the payment service in response to identifying whether one or more capabilities required for the transaction are present within the machine-readable resource; obtaining a public address associated with the alias based on one or more of the instructions and / or specifications in the machine-readable resource; A method comprising: (Item 14) A method associated with transactions for a distributed ledger, wherein an alias is provided for a given client among one or more clients, the alias being unique to the given client, and the alias including or associated with a network identifier, the method comprising: sending, from a requesting entity, a request related to a transaction, said request being associated with said alias; accessing the machine-readable resource from a location associated with the payment service, the payment service being identified based on the network identifier in the alias, and the machine-readable resource being generated in accordance with clause 9; receiving an endpoint identifier of the host computing resource for the payment service associated with the alias based on identifying whether one or more capabilities required for the transaction are present in the machine-readable resource; obtaining a public address associated with the alias using one or more of the instructions and / or specifications in the machine-readable resource; A method comprising: (Item 15) A method described in Item 13 or 14, wherein each digital wallet is associated with a user or entity registered for the payment service within the network, each digital wallet is a cryptocurrency wallet associated with a public key and a private key of an asymmetric cryptographic key pair for transactions on the distributed ledger, and the step of obtaining the public address includes a step of obtaining the public key of the digital wallet associated with the alias. (Item 16) The method of item 15, wherein the public address associated with the alias is based on a cryptographic hash of the public key of the digital wallet associated with the alias. (Item 17) The method of items 15 or 16, wherein the public key of the digital wallet is an elliptic curve digital signature algorithm (ECDSA) public key, and the public key is not part of any transaction previously stored or posted to the distributed ledger. (Item 18) The one or more instructions and / or specifications in the machine-readable resource: retrieving a public key infrastructure (PKI) request template from the machine-readable resource for a PKI endpoint identifier; generating a complete PKI request using the alias and the network identifier in the template; sending an HTTP GET request based on the complete PKI request to obtain a public key associated with the alias; Item 18. The method according to any one of Items 13 to 17, comprising: (Item 19) A method according to any of items 9 to 18, wherein the known or predictable location of the machine-readable resource is based on at least one of the endpoint identifier, an Internet Protocol communication port used by the payment service, and / or a configuration specification of the payment service contained in a publicly accessible, well-known domain repository. (Item 20) The method according to any one of Items 9 to 19, wherein the machine-readable resource is generated using a JSON (Java Script Object Notation) format. (Item 21) The step of obtaining the public address associated with the alias includes: obtaining a payee destination of a payee entity associated with the alias, the payee destination used in structuring a transaction to make a cryptocurrency payment from a payer entity to the alias; The step of configuring the transaction comprises: accessing the machine-readable resource based on identifying the payment service; returning a payee endpoint identifier based on one or more instructions and / or specifications in the machine-readable document; obtaining payment details of the transaction from the payer entity, the payment details including an alias associated with the payee entity client and an amount of cryptocurrency to be paid to the payee; obtaining a digital signature associated with the payment details to a cryptographic key associated with the payer entity; generating an output script associated with the payee endpoint identifier associated with the alias, the output script provided for embedding into a transaction for the distributed ledger; 21. The method according to any one of items 13 to 20, comprising: (Item 22) The step of obtaining the public address associated with the alias includes: obtaining a payee destination of a payee entity associated with the alias, the payee destination used in structuring a transaction to make a cryptocurrency payment from a payer entity to the alias; The step of configuring the transaction comprises: sending, from the payer entity, a request regarding the transaction, the request being associated with the alias; accessing the machine-readable resource from a location associated with the payment service; receiving a payee endpoint identifier based on the one or more instructions and / or specifications in the machine-readable resource; providing payment details for the transaction, the payment details including an alias associated with the payee entity client and an amount of cryptocurrency to be paid to the payee; providing a digital signature associating said payment details with an encryption key; receiving an output script associated with the payee endpoint identifier associated with the alias; generating transactions for the distributed ledger by embedding the received output script into the transactions; 21. The method according to any one of Items 14 to 20, comprising: (Item 23) The one or more instructions and / or specifications in the machine-readable resource: retrieving a payee request template from the machine-readable resource for a payee endpoint identifier; including the alias and the network identifier in the template to generate a complete payee request; sending an HTTP POST request based on the complete payee request to obtain a payee endpoint identifier associated with the alias; Item 23. The method according to Item 21 or 22, comprising: (Item 24) A method according to any of items 21 to 23, wherein the alias and the public address of the payer entity contain public keys of respective digital wallets associated with the payee entity and the payer entity, respectively, and the digital signature is used to verify the identity of the payer entity. (Item 25) A method according to any of items 21 to 24, wherein digital signatures associated with both the payer entity and the payee entity are required for verification by each entity before the generated transaction is stored or posted to the distributed ledger. (Item 26) A method according to any one of items 1 to 25, wherein the alias is a payment handle associated with the client. Item 27. A method of configuring a prefix for generating a request associated with a transaction from a requesting entity to an alias associated with a client, the method comprising: 27. A method comprising the step of triggering the steps of any of clauses 1 to 26 based on the alias in response to receiving a request from the requesting entity, the request including the prefix and the alias. (Item 28) A system, a processor; a memory containing executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method of any one of clauses 1 to 27; A system including: (Item 29) A non-transitory computer-readable storage medium storing executable instructions, the executable instructions, when executed by a processor of a computer system, causing the computer system to perform a computer-implemented method described in any one of items 1 to 28.

[0264] The present disclosure, with respect to the claimed subject matter, is now discussed under the following sections relating to the fourth and fifth aspects, which are provided to better explain, describe, and understand these aspects and embodiments. Item 1. A computer-implemented method for performing payment services for one or more clients for transactions associated with a distributed ledger, the method comprising: updating a machine-readable resource associated with the payment service, the machine-readable resource being provided at or accessible from a predictable or known location associated with the payment service; The machine-readable resource may be: at least one identifier associated with a host computing resource responsible for implementing the payment service for each client among the one or more clients, wherein each client is associated with an alias, the alias being unique to the client; and entries associated with at least one capability supported by the payment service, each capability associated with a protocol or instructions for implementing the respective capability for the one or more clients associated with the payment service; one or more instructions and / or specifications for accessing or obtaining a public address associated with said alias, said public address being used to effectuate transactions associated with said alias; and Including, the updating step includes adding at least one additional capability supported by the payment service; The at least one further capability is: Validating a payer entity requesting a payee for an alias, where a given client among the one or more clients is associated with the alias; and / or asynchronous processing of a request from a payer entity, the request being associated with an alias payee, and a given client among the one or more clients being associated with the alias; A method comprising: (Item 2) A computer-implemented method for performing a payment service for transactions associated with a distributed ledger, wherein clients among one or more clients associated with the payment service are provided with aliases, the aliases being unique to the clients, and each client being provided with a respective alias, the method comprising: receiving a request associated with an alias from a payer entity, the request relating to a payee of a payee client among the one or more clients associated with the payment service, the payee client being associated with the alias in the request; validating the payer entity based on at least one capability supported by the payment service, the at least one capability being included in a machine-readable resource associated with the payment service; Including, The verifying step includes: obtaining a public key associated with the payer entity; determining whether a predetermined condition is met based on the request from the payer entity; Including, Upon determining that the predetermined condition is satisfied, validating the payer entity and / or the request associated with the payer entity; generating an output script associated with the payee of the payee client; sending the output script to the payer entity, the output script being provided for embedding into a transaction in the distributed ledger; A method comprising: (Item 3) The method of item 2, wherein based on a determination that the predetermined condition is not met, the method includes generating and / or transmitting a response from the payer entity rejecting the received request. (Item 4) The method described in Items 2 or 3, wherein the payment service of the payee client is implemented according to the method described in Item 1, and the at least one capability supported by the payment service of the payee client is based on at least one further capability in the updated machine-readable resource of Item 1. (Item 5) The request associated with the alias from the payer entity includes: a timestamp indicating when the request was sent from the payer entity; and / or a digital signature associated with the public key of the payer entity; and / or a one-time token for said request; 5. The method according to any one of items 2 to 4, wherein the HTTP POST request includes: (Item 6) The specified conditions are: verifying that the timestamp included in the request is within a predetermined period of time of receipt of the request by the payment service associated with the payee client; and / or verifying that the digital signature in the request is associated with the payer entity's obtained public key; and / or verifying that the one-time token has not been used for a previous request; Item 6. The method according to Item 5, comprising: (Item 7) The method described in Item 6, wherein the predetermined period is a maximum of 2 minutes. (Item 8) The step of sending the output script includes: applying a digital signature associated with the recipient client's public key to the output script; sending a signed output script to the payer entity; Item 8. The method according to any one of Items 2 to 7, comprising: (Item 9) A method according to any of items 1 to 8, wherein the payer entity is associated with a payment service different from the payment service of the payee client and is assigned an alias associated with the different payment service, and the alias is included in the request from the payer entity. (Item 10) A method according to any of items 1 to 9, wherein the payer entity is associated with the same payment service as the payment service of the payee client and is assigned an alias associated with the same payment service, and the alias is included in the request from the payer entity. (Item 11) The step of obtaining the public key associated with the payer entity comprises: accessing a machine-readable resource from a location associated with the payment service of the payer entity; sending an HTTP GET request based on a public key infrastructure (PKI) request template in the machine-readable resource and based on the alias of the payer entity; in response, obtaining the public key associated with the alias; Item 11. The method according to Item 9 or 10, comprising: (Item 12) A method associated with transactions for a distributed ledger, the method comprising: providing an alias to a client among one or more clients associated with a payment service, the alias being unique to the client, and each client being associated with a respective alias; the method comprising: generating a request associated with an alias, the request relating to a payee of a payee client among the one or more clients associated with the payment service, the payee client being associated with the alias in the request; applying a digital signature associated with the payer entity's public key to the generated request to obtain a signed request; accessing a machine-readable resource associated with the payment service of the alias; transmitting the signed request based on one or more instructions and / or specifications in the machine-readable resource associated with the payee, the request including a timestamp indicating the date and time of transmission; receiving an output script associated with the requested payee; embedding the received output script into a transaction for the distributed ledger, the transaction being associated with the payer entity and the payee client; A method comprising: (Item 13) The received output script includes a digital signature based on a public key associated with the recipient client, and the method further includes verifying the signature by: sending an HTTP GET request based on a public key infrastructure (PKI) request template in the machine-readable resource and based on the alias of the recipient client; in response, obtaining the public key associated with the alias; verifying that the digital signature in the output script is associated with the obtained public key of the recipient client; Item 13. The method of item 12, comprising the step of verifying the signature by (Item 14) A computer-implemented method for implementing a payment service for transactions associated with a distributed ledger, wherein clients among one or more clients associated with the payment service are provided with aliases, the aliases being unique to the clients, and each client being provided with a respective alias, the method comprising: receiving a request associated with an alias from a payer entity, the request relating to a payee of a payee client among one or more clients associated with the payment service, the payee client being associated with the alias in the request; performing asynchronous processing of the request based on at least one capability supported by the payment service, the at least one capability being identified using a machine-readable resource associated with the payment service, the asynchronous processing comprising: generating a token that is unique to the received request; transmitting the token to the payer entity; generating an output script associated with the payee of the payee client in response to receiving authorization of the request; generating a callback request including the token and the generated output script; sending the callback request to the payer entity, wherein the output script in the callback request is provided for embedding into a transaction for the distributed ledger; A method comprising: (Item 15) The method of item 14, wherein in response to receiving a rejection of the request or upon expiration of a predetermined period of time, the method includes generating and transmitting a response rejecting the received request from the payer entity. (Item 16) The method described in Items 14 or 15, wherein the payment service of the recipient client is implemented by the method described in Item 1, and the at least one capability supported by the payment service of the recipient client is based on at least one further capability in the updated machine-readable resource of Item 1. (Item 17) A method according to any one of items 14 to 16, wherein the step of performing asynchronous processing of the request is performed in response to the recipient client not responding or being offline for a predetermined period of time after receiving the request from the recipient entity. (Item 18) sending a notification to the recipient entity regarding the request; receiving a grant or denial of the request from the recipient client; 18. The method according to any one of items 14 to 17, further comprising: (Item 19) The step of transmitting the token and / or the step of transmitting the callback request includes: applying a digital signature associated with the recipient client's public key to the token to obtain a signed token, or to a combination of the output script and the token in the callback request to obtain a signed callback request; sending the signed token or a signed callback request to the payer entity; 19. The method according to any one of items 14 to 18, comprising: (Item 20) A method according to any of items 14 to 19, wherein the payer entity is associated with a payment service that is the same as or different from the payment service of the payee client and is assigned an alias associated with the payment service, and the alias is included in the request from the payer entity. (Item 21) The method described in Item 20, wherein the callback request is an HTTP POST request based on a payee request template, the token, and the alias of the payer entity, and the payee request template is obtained by accessing a machine-readable resource associated with the payment service of the payer entity. (Item 22) The method of any one of items 14 to 21, further comprising the step of verifying the payer entity according to the method of any one of items 2 to 11. (Item 23) A method associated with transactions for a distributed ledger, the method comprising: providing an alias to a client among one or more clients associated with a payment service, the alias being unique to the client, and each client being associated with a respective alias; the method comprising: generating a request associated with an alias, the request relating to a payee of a payee client among the one or more clients associated with the payment service, the payee client being associated with the alias in the request; transmitting a request based on one or more instructions and / or specifications accessed from a machine-readable resource associated with the payee, the machine-readable resource being associated with the payment service; receiving a token from the payment service, the token being unique to the request, the token being associated with a digital signature; verifying that the digital signature associated with the token relates to the recipient client's public key; In response to successful validation, updating a record associated with the request based on the token; receiving a callback request, the callback request including the token and an output script associated with the requested payee, the callback request being associated with a digital signature; verifying that the digital signature associated with the callback request is associated with the recipient client's public key; In response to successful verification, correlating the token in the callback request with the updated record; embedding the received output script into a transaction for the distributed ledger, the transaction being associated with the payer entity and a payee client; A method comprising: (Item 24) The received token or callback request includes a digital signature based on a public key associated with the recipient client, and the step of verifying the digital signature includes: sending an HTTP GET request based on a public key infrastructure (PKI) request template in the machine-readable resource and based on the alias of the recipient client; in response, obtaining the public key associated with the alias; verifying that the digital signature associated with the token or the callback request is associated with the obtained public key of the recipient client; Item 24. The method according to Item 23, comprising: (Item 25) The method comprises: 14. The method according to any one of clauses 12 or 13, for validating the payer entity; 25. The method of any one of items 23 and 24, further comprising: (Item 26) A method associated with transactions for a distributed ledger, the method comprising: providing an alias to a client among one or more clients associated with a payment service, the alias being unique to the client, and each client being associated with a respective alias; the method comprising: receiving, by a payee client, notification of a request associated with an alias, the request relating to a payee client's payee destination among the one or more clients associated with the payment service, the payee client being associated with the alias in the request; when the recipient client is offline, approving or denying the request, the approval or denial being provided using an interface or based on a predefined record associated with an allowed or disallowed request property; sending a response to the payment service based on the authorization or denial; A method comprising: (Item 27) The method described in item 26, wherein the request is processed by the payment service by the method described in any one of items 14 to 22. (Item 28) One or more instructions and / or specifications in the machine-readable resource associated with the payment service may: obtaining a public key verification request template from the machine-readable resource for a PKI endpoint identifier; including the alias in the template to generate a complete public key verification request; sending an HTTP GET request based on the complete public key verification request to verify that the public key in the request is valid for the alias in the request; Item 28. The method according to any one of items 1 to 27, comprising: (Item 29) A computing device or system, at least one processor; a memory containing executable instructions that, upon execution by the at least one processor, cause the computing device or system to perform the computer-implemented method of any one of clauses 1 to 28; and 1. A computing device or system comprising: (Item 30) A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a system or computing device, cause the system or computing device to perform at least one of the computer-implemented methods described in any one of items 1 to 28. (Item 31) A method associated with transactions for a distributed ledger, comprising: sending a request from a payer entity, the request being based on an alias of a payee entity; verifying the payer entity based on a timestamp and signature included in the request; sending an output script to the payer entity in response to successful validation; generating transactions based on the output script, the transactions being posted to the distributed ledger; A method comprising: (Item 32) A method associated with transactions for a distributed ledger, comprising: sending a request from a payer entity, the request being based on an alias of a payee entity; providing an acknowledgment of receipt of the request to the payer entity; providing notification of said request to said recipient; obtaining authorization for the request when the recipient entity is online or available; sending an output script to the payer entity in response to the authorization; generating transactions based on the output script, the transactions being posted to the distributed ledger; A method comprising: (Item 33) The method according to Item 32, including the method according to Item 31. (Item 34) A system comprising a payer entity, a payee entity, and a payment service associated with at least the payee entity, wherein the payer entity, payee entity, and / or payment service each comprise at least one processor that executes computer-readable instructions for performing the steps of the method described in any one of items 31 to 33.< / tld> < / domain> < / name> < / tld> < / domain> < / name> < / tld> < / domain> < / name> < / host-discovery-target> < / tld> < / domain> < / name>

Claims

1. 1. A method associated with transactions for a distributed ledger, the method comprising: providing aliases to clients among one or more clients associated with a payment service, the aliases being unique to the clients, and each client being associated with a respective alias; the method comprising: generating a request associated with an alias, the request relating to a payee of a payee client among the one or more clients associated with the payment service, the payee client being associated with the alias in the request; applying a digital signature associated with the payer entity's public key to the generated request to obtain a signed request; accessing a machine-readable resource associated with the payment service of the alias; transmitting the signed request based on one or more instructions and / or specifications in the machine-readable resource associated with the payee, the request including a timestamp indicating the date and time of transmission; receiving an output script associated with the requested payee; embedding the received output script into a transaction for the distributed ledger, the transaction being associated with the payer entity and the payee client; A method comprising:

2. The received output script includes a digital signature based on a public key associated with the recipient client, and the method includes verifying the digital signature, the digital signature comprising: sending an HTTP GET request based on a public key infrastructure (PKI) request template in the machine-readable resource and based on the alias of the recipient client; in response, obtaining the public key associated with the alias; verifying that the digital signature in the output script is associated with the obtained public key of the recipient client; 2. The method of claim 1, further comprising verifying the digital signature by:

3. 1. A method associated with transactions for a distributed ledger, the method comprising: providing aliases to clients among one or more clients associated with a payment service, the aliases being unique to the clients, and each client being associated with a respective alias; the method comprising: generating a request associated with an alias, the request relating to a payee of a payee client among the one or more clients associated with the payment service, the payee client being associated with the alias in the request; sending a request based on one or more instructions and / or specifications accessed from a machine-readable resource associated with the payee, the machine-readable resource being associated with the payment service; receiving a token from the payment service, the token being unique to the request, the token being associated with a digital signature; verifying that the digital signature associated with the token relates to the recipient client's public key; In response to successful validation, updating a record associated with the request based on the token; receiving a callback request, the callback request including the token and an output script associated with the requested payee, the callback request being associated with a digital signature; verifying that the digital signature associated with the callback request is associated with the recipient client's public key; In response to successful verification, correlating the token in the callback request with the updated record; embedding the received output script into a transaction for the distributed ledger, the transaction being associated with a payer entity and a payee client; A method comprising:

4. the received token or callback request includes a digital signature based on a public key associated with the recipient client, and the step of verifying the digital signature comprises: sending an HTTP GET request based on a public key infrastructure (PKI) request template in the machine-readable resource and based on the alias of the recipient client; in response, obtaining the public key associated with the alias; verifying that the digital signature associated with the token or the callback request is associated with the obtained public key of the recipient client; The method of claim 3, comprising:

5. The method comprises: The steps of the method of claim 1 or 2 for validating the payer entity, 5. The method of claim 3, further comprising:

6. The one or more instructions and / or specifications in the machine-readable resource associated with the payment service include: obtaining a public key verification request template from the machine-readable resource for a PKI endpoint identifier; including the alias in the public key verification request template to generate a complete public key verification request; sending an HTTP GET request based on the complete public key verification request to verify that the public key in the request is valid for the alias in the request; The method according to any one of claims 1 to 5, comprising:

7. 1. A computing device or system comprising: at least one processor; a memory containing executable instructions that, upon execution by said at least one processor, cause said computing device or system to perform a method according to any one of claims 1 to 6; 1. A computing device or system comprising:

8. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a system or computing device, cause the system or computing device to perform a method according to any one of claims 1 to 6.

Images