阅读说明：本技术 用于为分布式账本实现基于别名的寻址的计算机实现的系统和方法 (Computer-implemented system and method for implementing alias-based addressing for distributed ledgers ) 是由 A·美 R·迪克赫伯 于 2020-01-29 设计创作，主要内容包括：本公开提供了一种为与分布式账本(例如,比特币区块链)关联的交易实现对于一个或多个客户端的支付服务的方法。该方法包括为客户端提供别名,将别名与目录中的网络关联,以及提供负责支付服务的主机计算资源的位置,其中,该主机计算资源被配置为促进与别名关联的客户端的标识。本公开还提供了一种方法,其包括：在与支付服务关联的位置创建机器可读资源,其中,该机器可读资源包括用于支付服务的端点标识符、与支付服务所支持的至少一个能力关联的条目以及用于访问公共地址以促进与别名关联的交易的指令和/或规范。本公开还讨论了一种为与支付服务关联的客户端实现简化支付协议的方法。(The present disclosure provides a method of enabling payment services for one or more clients for transactions associated with a distributed ledger (e.g., bitcoin blockchain). The method includes providing an alias for a client, associating the alias with a network in a directory, and providing a location of a host computing resource responsible for payment services, wherein the host computing resource is configured to facilitate identification of the client associated with the alias. The present disclosure also provides a method, comprising: creating a machine-readable resource at a location associated with the payment service, wherein the machine-readable resource includes an endpoint identifier for the payment service, an entry associated with at least one capability supported by the payment service, and instructions and/or specifications for accessing a public address to facilitate a transaction associated with the alias. The present disclosure also discusses a method of implementing a simplified payment protocol for a client associated with a payment service.)

1. A computer-implemented method of implementing a payment service for one or more clients for transactions associated with a distributed ledger, the method comprising the steps of:

providing an alias for a given client among the one or more clients, the alias being specific to the given client, the alias including or being related to a network identifier;

associating the alias with a network identifier in a directory, the step of associating comprising:

creating a service record based on the network identifier in the directory;

updating the service record to indicate that the payment service is provided by a network or domain associated with a network identifier; and

updating the service record to indicate a location of a host computing resource responsible for the payment service, wherein the host computing resource is configured to facilitate identification of a digital wallet associated with the alias in response to a request for a transaction related to the alias.

2. The method of claim 1, wherein each of the one or more clients is associated with a digital wallet.

3. The method of claim 1 or claim 2, comprising:

in response to a request from a requesting entity regarding a transaction associated with the alias, performing a search of the directory based on the alias;

identifying a service record for the payment service in a directory associated with the network identifier; and

returning a location of a host computing resource for the payment service, wherein a public address of a client associated with the alias is determined based on the returned location, the public address being used in the transaction.

4. A method associated with a transaction of a distributed ledger wherein a given client among one or more clients is provided with an alias, the alias being specific to the given client, the alias comprising or being related to a network identifier, the method comprising the steps of:

sending a request for a transaction from a requesting entity, the request associated with the alias;

obtaining a location of a host computing resource associated with a payment service, the location based on a service record related to a network identifier identified in a search of a directory; and wherein a public address of a client associated with the alias is determined based on the location, the public address being used in the transaction.

5. The method of claim 4, wherein each of the one or more clients is associated with a digital wallet.

6. The method of any of claims 3 to 5, wherein returning or obtaining the location of the host computing resource comprises returning or obtaining a target and a port pair, wherein the target comprises an identifier of the host computing resource, and wherein the port comprises an identifier of an internet protocol communication port used by the payment service.

7. The method of any preceding claim, wherein the host computing resource is associated with a payment network that is different from a network associated with the network identifier of the alias, and wherein payment services of one or more entities registered with the network are delegated to a payment domain associated with the payment network.

8. The method of claims 1-7, wherein the host computing resource is associated with a payment network, and wherein the domain of the payment network is the same as the domain of the network associated with the network identifier of the alias.

9. A computer-implemented method of implementing a payment service for one or more clients for transactions associated with a distributed ledger, the method comprising:

creating a machine-readable resource associated with the payment service, wherein the machine-readable resource comprises:

at least one endpoint identifier associated with a host computing resource responsible for conducting payment services for each client, each client associated with an alias that includes or is related to a network identifier;

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 the alias, the public address for facilitating a transaction associated with the alias; and

providing the machine-readable resource at a predictable or known location associated with the payment service.

10. The method of claim 9, wherein each of the one or more clients is associated with a digital wallet.

11. The method of claim 9 or 10, wherein the plurality of capabilities comprise one or more of:

the payer entity or the payee entity verifies,

a plurality of digital signatures for the transaction,

the payee entity approves the transaction,

a payment transaction associated with an e-mail agreement,

simplified payment protocol or flow for payment transactions, and/or

Callback requests or responses.

12. The method of any of claims 9 to 11, further comprising: determining a location of the host computing resource by the method of any of claims 1-3 and 6-8, wherein an endpoint identifier in the machine-readable resource is based on the determined location.

13. The method of any of claims 9 to 12, wherein in response to a request from the requesting entity for a transaction associated with an alias, the method further comprises the steps of:

identifying a payment service associated with the alias in the request based on a network identifier associated with the alias;

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 a host computing resource for the payment service in response to identifying whether one or more capabilities required for the transaction are present in the machine-readable resource; and

obtaining a public address associated with the alias based on one or more instructions and/or specifications in the machine-readable resource.

14. A method associated with a transaction of a distributed ledger wherein a given client among one or more clients is provided with an alias, the alias being specific to the given client, the alias comprising or being related to a network identifier, the method comprising the steps of:

sending a request for a transaction from a requesting entity, the request associated with the alias;

accessing a machine-readable resource from a location associated with the payment service, wherein the payment service is identified based on the network identifier in the alias, and wherein the machine-readable resource is created in accordance with claim 9;

receiving an endpoint identifier for a host computing resource of a 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; and

obtaining a public address associated with the alias using one or more instructions and/or specifications in the machine-readable resource.

15. The method of any of claims 13 or 14, wherein each client is associated with a digital wallet related to a user or entity that registers payment services in a network, wherein each digital wallet is a crypto-currency wallet associated with a public and private key of an asymmetric cryptographic key pair for transactions on a distributed ledger, and wherein the step of obtaining the public address comprises obtaining a public key of a digital wallet associated with the alias.

16. The method of claim 15, wherein the public address associated with the alias is based on a cryptographic hash of a public key of a digital wallet associated with the alias.

17. The method of any one of claims 15 or 16, wherein the public key of the digital wallet is an Elliptic Curve Digital Signature Algorithm (ECDSA) public key, wherein the public key is not part of any transaction previously stored on or published to the distributed ledger.

18. The method of any of claims 13-17, wherein the one or more instructions and/or specifications in the machine-readable resource comprise:

obtaining a public key infrastructure PKI request template for a public key infrastructure PKI endpoint identifier from the machine-readable resource;

including the alias and network identifier in the template to generate a complete PKI request; and

sending an HTTP GET request based on the complete PKI request to obtain a public key associated with the alias.

19. The method of any of claims 9 to 18, wherein the known or predictable location of the machine-readable resource is based on at least one of an endpoint identifier included in a publicly accessible well-known domain repository, an internet protocol communication port used by a payment service, and/or a configuration specification of a payment service.

20. The method of any of claims 9-19, wherein the machine-readable resource is generated using a javascript object notation (JSON) format.

21. The method of any one of claims 13 and 15 to 20, wherein the step of obtaining a public address associated with the alias comprises obtaining a payment destination of a payee entity associated with the alias, the payment destination being used to construct a transaction for making a cryptocurrency payment from a payer entity to the alias, the method comprising the steps of:

accessing the machine-readable resource for the payment service;

returning a payment destination endpoint identifier based on one or more instructions and/or specifications in the machine-readable document;

obtaining payment details for the transaction from the payer entity, the payment details including an alias associated with a payee entity client and an amount of cryptocurrency to be paid to a payee;

obtaining a digital signature for associating the payment details with an encryption key associated with the payer entity; and

generating an output script associated with a payment destination endpoint identifier associated with the alias, the output script provided for embedding into transactions of the distributed ledger.

22. The method of any one of claims 14 to 20, wherein the step of obtaining a public address associated with the alias comprises obtaining a payment destination of a payee entity associated with the alias, the payment destination being used to construct a transaction for making a cryptocurrency payment from a payer entity to the alias, wherein the step of constructing the transaction comprises:

sending a request from the payer entity for the transaction, the request being associated with the alias;

accessing the machine-readable resource from a location associated with the payment service;

receiving a payment destination endpoint identifier based on one or more instructions and/or specifications in a machine-readable document;

providing payment details for the transaction, the payment details including an alias associated with a payee entity client and an amount of cryptocurrency to be paid to a payee entity;

providing a digital signature for associating the payment details with an encryption key;

receiving an output script associated with a payment destination endpoint identifier associated with the alias; and

creating the transaction by embedding the received output script into a transaction of the distributed ledger.

23. The method of claim 21 or 22, wherein the one or more instructions and/or specifications in the machine-readable resource comprise:

obtaining a payment destination request template for a payment destination endpoint identifier from the machine-readable resource;

including the alias and the network identifier in the template to generate a complete payment destination request; and

sending an HTTP POST request based on the complete payment destination request to obtain a payment destination endpoint identifier associated with the alias.

24. The method of any one of claims 21 to 23, wherein the public address of the alias and the public address of the payer entity each comprise a public key of a respective digital wallet associated with the payee entity and payee entity, and wherein the digital signature is used to verify the identity of the payer entity.

25. The method of any of claims 21-24, wherein a digital signature associated with both the payer entity and the payee entity is required to verify each respective entity before the created transaction is stored or published on the distributed ledger.

26. A computer-implemented method of implementing a payment service 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 being created in accordance with claim 9, the step of updating comprising:

adding at least one additional capability supported by the payment service, wherein the at least one additional capability comprises implementing a simplified protocol for processing digital assets of a given client among the one or more clients.

27. A computer-implemented method of implementing a payment service for transactions associated with a distributed ledger, wherein a client associated with the payment service among one or more clients is provided with an alias, the alias being specific to the client, each client being provided with a respective alias, the method comprising the steps of:

receiving, from a payer entity, a payment indicator for a cryptocurrency payment associated with an alias, the indicator relating to a payee entity associated with the payment service among the one or more clients, the payee entity associated with the alias in the payment indicator;

providing a payment request template based on the machine-readable resource of claim 9, the machine-readable resource associated with the payment service, the payment request template including an output script for the payee entity;

receiving a complete payment transaction based on a payment template from the payer entity, the complete payment transaction being associated with the alias and network identifier;

providing the complete payment transaction to the distributed ledger.

28. The method of claim 27, wherein the payee entity's payment service is implemented by the method of claim 26, and wherein the at least one capability supported by the payee entity's payment service is based on the at least one additional capability in the updated machine-readable resource of claim 26.

29. The method of any of claims 27 or 28, wherein the output script in the payment request template includes a payment destination for building a transaction for a cryptocurrency payment from a payer entity to the alias, the output script provided by:

accessing a machine-readable resource for the payment service;

obtaining a payment destination endpoint identifier based on one or more instructions and/or specifications in the machine-readable document; and

generating an output script associated with a payment destination endpoint identifier of a payee entity to which the alias is associated.

30. The method according to any one of claims 27 or 29, comprising the steps of:

receiving a complete payment transaction in the form of an HTTPS POST request from the payer entity, the complete payment transaction including:

payment details for a payment transaction from the payer entity, the payment details including an alias associated with a payee entity and an amount of cryptocurrency to be sent to the payee entity; and

a digital signature for associating the payment particulars with an encryption key related to the payer entity; and

submitting the complete payment transaction to the distributed ledger.

31. The method of claim 30, comprising the step of sending a confirmation to the payer entity in response to receiving the complete payment transaction.

32. A computer-implemented method associated with transactions of a distributed ledger, wherein a client associated with a payment service among one or more clients is provided with an alias, the alias being specific to the client, each client being associated with a respective alias, the method comprising the steps of:

generating a payment indicator for a crypto-currency payment associated with an alias associated with a payee entity associated with the payment service among the one or more clients;

sending the payment indicator to the alias based on one or more instructions and/or specifications in the machine-readable resource of claim 9, the machine-readable resource associated with a payment service for the alias;

obtaining a payment request template from a payment service related to the alias, the payment request template including an output script for the payee entity;

generating a complete payment transaction based on the obtained payment request template by:

including an alias and a network identifier of the payee entity in the template;

applying a digital signature associated with a public key of a payer entity to sign the payment transaction; and

providing a payment comprising an amount of cryptocurrency to be paid to the alias; and

sending the complete payment transaction to a payee entity associated with the alias.

33. The method of claim 1, including the step of receiving confirmation of the cryptocurrency payment from a payment service associated with the payee entity.

34. The method of any preceding claim, wherein the alias is a payment handle associated with a client.

35. A method for configuring a prefix for a proposed request relating to a transaction from a requesting entity to an alias associated with a client, the method comprising, in response to receiving a request from the requesting entity comprising the prefix and the alias, triggering the steps of any of the preceding claims based on the alias.

36. A computer device or computer system comprising:

a processor; and

a memory comprising executable instructions that, as a result of being executed by the processor, cause the system to perform the computer-implemented method of any preceding claim.

37. A non-transitory computer readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of claims 1 to 35.

Technical Field

The present disclosure relates generally to methods and systems for facilitating transactions associated with distributed ledgers, and more particularly to methods for destination addressing of one or more digital wallets. The present disclosure is particularly suited to, but not limited to, providing a method for facilitating a cryptographic currency payment from a payee to a payer.

Background

In this document, we use the term "blockchain" to include all forms of electronic computer-based distributed ledgers (leggers). These include consensus-based blockchain and transaction chain techniques, licensed and unlicensed ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the bitcoin ledger. Although reference may be made herein to bitcoins for purposes of convenience and illustration, it should be noted that the present disclosure is not limited to use with bitcoin blockchains, and that alternative blockchain implementations and protocols fall within the scope of the present disclosure. The term "user" may refer herein to a human or processor-based resource. The term "bitcoin" as used herein includes any version or variation derived from or based on the bitcoin protocol.

A blockchain is a point-to-point electronic ledger implemented as a computer-based decentralized distributed system consisting of blocks that in turn consist of transactions. Each transaction is a data structure encoding a transfer of control of a digital asset between participants in a blockchain system and including at least one input and at least one output. Each block contains the hash value of the previous block to that block, so the blocks are linked together to create a permanent, unalterable record of all transactions that have been written into the chain of blocks since their beginning. The transaction contains applets, called scripts, embedded in its input and output that specify how and by whom the output of the transaction can be accessed. On bitcoin platforms, these scripts are written using a stack-based scripting language.

In order to write a transaction to a blockchain, it must be "verified". The network node (miners) performs work to ensure that each transaction is valid, while invalid transactions are rejected by the network. A software client installed on a node performs this verification work on the unspent transaction output (UTXO) by executing its lock script and unlock script. If the execution of the lock script and unlock script evaluates to TRUE (TRUE), the transaction is valid and the transaction is written to the blockchain. Therefore, in order to write a transaction to a blockchain, it is necessary to: i) validating the transaction by a first node receiving the transaction-if the transaction is validated, the node relays it to other nodes in the network; ii) adding the transaction to a new block built by the mineworker; and iii) the transaction is mined, i.e. added to the public ledger of past transactions.

Once stored as a UTXO in the blockchain, the user may transfer control of the associated cryptocurrency to another address associated with an input in another transaction. This is typically done using a digital crypto currency wallet. The digital wallet may be a device, physical medium, program, application (app) on a mobile terminal or a remotely hosted service associated with a domain on a network work (e.g., the internet). The digital wallet stores public and private keys and may be used to track ownership of assets, etc. associated with the user, receive or spend cryptocurrency. The cryptocurrency itself is not in the digital wallet. In the case of bitcoins and cryptocurrencies derived therefrom, the cryptocurrencies are stored scattered and maintained in publicly available ledgers (i.e., blockchains). There are many forms of cryptocurrency wallet known, and a network of such wallets is known as an ecosystem, for example that of bitcoin sv (bsv) wallets. The digital wallet may also be a Simplified Payment Verification (SPV) wallet.

Currently, to facilitate BSV cryptocurrency payment between users (i.e., from alice and bob), alice would need to own a digital wallet associated with its (private and public) cryptographic keys, and bob would need to know his public address for sending the cryptocurrency (i.e., bob's digital wallet address). The public address associated with the entity (in this case a digital wallet) is typically automatically generated by an address generation program. These public addresses are strings of numeric characters in a particular format that are identified by the cryptocurrency network and used for transactions. These may be, for example, bitcoin addresses of BSV-based cryptocurrency networks. This may be referred to as a hash of the public key or public key of an asymmetric private/key pair associated with the entity. The public address may be publicly shared so that other users know where to send payments in the cryptocurrency. However, the public address identified and used by the BSV wallet ecosystem or other cryptocurrency wallet takes, for example, the following format:

17Dx2iAnGWPJCdqVvRFr45vL9YvT86TDsn。

therefore alice would need to know or be provided with this type of address to send bob the cryptocurrency. In addition, an entity or wallet may use more than one type of address to conduct different types of transactions, and these addresses can only be used once to facilitate one transaction written on the blockchain. It is apparent that these public addresses are not in a user-friendly or easy-to-use or memorised format. Thus, these public addresses or keys for transactions would need to be identified or obtained or derived for each transaction, and may also need to be stored/cached for a particular period by an entity that wishes to make a crypto-currency payment to another entity.

Thus, while it is desirable to record data and events using blockchain techniques (as blockchains provide advantages such as tamper resistance and permanent recording), there are difficulties in paying identification (identification) for crypto currency or establishing destination addresses. This is because the operable format of these addresses identified in the wallet ecosystem is not simple or user friendly. One reason for this format may be the security with which it coexists, and the named protocol of the public IP address that applies across the digital payment network. Another reason is that bitcoin blockchains store data in transactions (Tx) that are built into blocks. Identifying the relevant data from the blockchain and then accessing the relevant data is based on the public address (linked to the private key) of the entity participating in the transaction. The present disclosure addresses these technical problems by providing various aspects and embodiments for improved destination identification and/or payment addressing for cryptocurrency ecosystems.

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

Drawings

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

fig. 1 is a flow chart depicting a method of updating a directory (directory) to include a payment service according to a first aspect.

Fig. 2a and 2b are flow diagrams depicting a method of identifying a host (host) responsible for a payment service according to a second aspect, the method being implemented by one or more processors of a payment service and a payment client entity, respectively.

Fig. 3a and 3b are flow diagrams depicting a method of identifying a public address associated with an alias, according to a second aspect, the method being implemented by one or more processors of a payment service and a payment client entity, respectively.

Fig. 4 is a flow diagram depicting a public key infrastructure sequence.

Fig. 5a and 5b are flow diagrams depicting a destination addressing method according to a third aspect, the method being implemented by one or more processors of a payment service and a payment client entity, respectively.

Fig. 6 is a flowchart depicting a payment destination endpoint resolution (end resolution) sequence.

Fig. 7a and 7b are flow diagrams depicting a method of implementing a simplified payment protocol or mechanism using a payment service of the second and/or third aspect as implemented by one or more processors of a payment service and payment client entity, respectively, according to the fourth aspect.

FIG. 8 is a schematic diagram that illustrates a computing environment in which various embodiments may be implemented.

Detailed description of the invention

According to a first aspect of the present disclosure, there is provided a computer-implemented method of implementing payment services for one or more clients for transactions associated with a distributed ledger. The method comprises providing the given client with an alias, the alias being specific to the given client, the alias comprising or being associated with a network identifier. The method then includes associating the alias with the network identifier in the directory. The association is achieved by the following steps: a service record is created based on the network identifier in the directory. The service record is then updated to indicate that the payment service is provided by the network or domain associated with the network identifier and a location of a host computing resource responsible for the payment service, wherein the host computing resource is configured to facilitate identification of the client associated with the alias in response to receiving the request for the transaction related to the alias.

In some embodiments, one or more of the clients mentioned above relate to one or more entities, such as computing resources, user terminals or applications associated with computing resources. In some embodiments, each client may be a digital wallet or may be an entity associated with a digital wallet, such as a user terminal having a digital wallet or an application for a digital wallet installed. While aspects and embodiments of the present disclosure relate to a digital wallet, it is understood that the client entity does not have a digital wallet or a separate application for a digital wallet, but is configured to provide functionality to operate as or with a digital wallet or to operate similarly to a digital wallet, which is also within the scope of the present disclosure. For ease of explanation alone, the following description refers to a digital wallet (a client entity associated with the digital wallet), but the disclosure is in no way limited to client entities having digital wallets.

The one or more digital wallets mentioned above in the first aspect are one of a plurality of digital wallets in the network, sometimes referred to as a wallet ecosystem of digital wallets, e.g. a multiple bit currency BSV crypto currency wallet. In other embodiments, the wallet may not be part of the wallet's network, but may simply be a separate and independent entity associated with the domain. In both cases, the network identifier may be or may include a domain name of the network, e.g., nchain. In some embodiments, the directory may be an open, i.e., accessible and/or decentralized, system (e.g., 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 Universal Resource Location (URL) of a web server from which other entities may access the payment service. For example, the other entity may be a digital wallet, which may or may not be part of a network associated with the network identifier, one or more payment server or client entities, or a payment application.

Advantageously, the first aspect enables a domain owner of one or more digital wallets to utilize a payment service to manage one or more functions that facilitate a transaction (e.g., a payment transaction) that is a one-time activity from a requesting (payer) entity to a destination (payee) entity associated with the digital wallet, i.e., by creating a service record (SRV record). While service records in DNS are known for identifying endpoints of services, such records have not been used or configured for effecting payment transactions associated with blockchains.

Advantageously, the above aspects enable a payee entity or digital wallet associated with a payee to be addressed using an alias for making a request relating to a payment transaction. Thus, the requesting party (payer entity) no longer needs to know, obtain or save/cache the complex public address of the digital wallet (i.e. 17Dx2 iangwjcdqvvrfr 45vL9YvT86TDsn) to enable or build a cryptocurrency transaction for the distributed ledger so that cryptocurrency payments can be made to the wallet. A forgotten alias for the payee or an alias associated with the payee's network (e.g., an alias that may be associated with the payee's electronic mail address format (name @ domain. com)) would be all that the requesting entity needs to know or send in requesting the payment transaction. Other formats of the identifying entity may also be used as aliases. This type of alias addressing provides a simpler and user-friendly technique for resolving the address of the payment destination. In some embodiments, even if there is no explicit network identifier in the alias, this may be sufficient to identify the payment service associated with the alias as long as the alias can be associated with the network identifier (i.e., by looking up a directory or database).

In some embodiments, the method includes performing a search of the directory based on the alias in response to a request for a transaction associated with the alias from a requesting entity. A request for a transaction refers to a request for information needed to generate or build a transaction to be published on a distributed ledger (i.e., blockchain). Thus, the request is not a request to generate a blockchain transaction itself, but rather a request for or relating to a future transaction, i.e., an off-block request for information to generate a transaction to be issued to the blockchain in the future. This is understood to be a request for future transactions of the blockchain. For ease of reference, the description hereafter discusses a request for a transaction to describe this step. It will be appreciated that the request relates to future transactions of the blockchain. The method includes identifying a service record for the payment service in a 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 may be determined. In some embodiments, this will correspond to a public address that may be associated with future transactions of the distributed ledger (i.e., bitcoin blockchain). In some embodiments, the step of returning the location of the host computing resource comprises returning a target and port pair, wherein the target comprises an identifier of the host computing resource, and wherein the port comprises an identifier of an internet protocol communication port used by the payment service.

Advantageously, this enables discovery of a host responsible for providing payment services to facilitate payment transactions to a payee entity based only on the alias of the payee entity, thereby significantly simplifying payment addressing for payment transactions of a digital ledger. Once the host is located, the public address associated with the payee entity's client or digital wallet may be determined, as the digital wallet is associated with a network or network identifier, and thus a payment service. The term public address as referred to herein relates to an identity (identity) or address of a digital wallet or client and, in some embodiments, is related to one or more (future) transactions of a distributed ledger. In some embodiments, the public address may be a payment address 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. The public address may be the same or different for each transaction associated with the digital wallet.

In some embodiments, the method according to the first aspect of the present disclosure comprises a method implemented on a payment client entity. This may be a requesting entity associated with a digital wallet encrypting currency. In this case, the method implemented by the payment client entity comprises the step of sending a request for the transaction from the requesting entity, the request being associated with the 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 search of the directory. The method then includes receiving a public address of the digital wallet associated with the alias, and thereafter using the public address in the requested transaction.

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

Advantageously, this allows the network to delegate alias-based payment to be managed and provisioned by third party networks associated with disparate domains.

In an alternative embodiment, the host computing resource is associated with the same domain as the network identifier. Alternatively, the domain owner may choose to implement the payment service within the network, in which case the endpoint identifier in the service record will be set or updated to reference the same domain of 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 simple for the payment service provider to add or modify a digital wallet or a network of digital wallets. Once the service record has been updated, the request or lookup search may continue seamlessly once a new host location is indicated in the service record.

According to a second aspect, the present disclosure is directed to a computer-implemented method of implementing payment services for one or more digital wallets for transactions using a distributed ledger, the method comprising creating a machine-readable resource associated with a payment service, wherein the machine-readable resource comprises an endpoint identifier of a host computing resource responsible for implementing payment services for each of one or more digital wallets (or networks), wherein each digital wallet is associated with an alias. The machine-readable resource also includes an entry (entry) associated with at least one capability among a plurality of capabilities supported by the payment service. The machine-readable resource also includes instructions and/or specifications for accessing a public address or location or one or more resources to facilitate a transaction associated with the alias. The method also includes providing the machine-readable resource at a predictable or known location associated with the host computing resource for the payment service.

In some embodiments, each capability is specified in the machine-readable resource as a pair of a name and a value. In some embodiments, the capabilities include one or more of payee entity or payer entity verification for some or all transactions, multiple digitally signed functions for transactions, payee entity or payment destination approval, and/or email-based payment transactions, such that the payment client may obtain the transaction script via email or the like.

Advantageously, the second aspect provides a way (means) to discover one or more capabilities or functions associated with a given payment service implemented for one or more digital wallets. As with the first aspect, all that is required by the requesting entity is the alias of the payer or destination entity, i.e. the alias associated with the payee's digital wallet, thereby providing a user-friendly and simplified addressing mechanism. This advantage is ensured by providing a publicly accessible machine-readable resource that specifies a function or capability provided by a digital wallet-implemented payment service. This second aspect's ability to discover payment services based on knowledge of only the payee entity's alias before making a request for a transfer is particularly useful when the payer entity associated with the digital wallet wishes to ensure the capabilities or functionality needed to support the transaction. Certain functions may be considered critical to facilitating cryptocurrency payment transactions associated with a distributed ledger, such as locating at least one endpoint identifier associated with a payment service, or implementing a secure communication mechanism based on Public Key Infrastructure (PKI), or the like. These functions are in most cases specified separately from the capability entries in the machine-readable resource. Advantageously, the capability entry can provide a specification, i.e., a record, of all supported functions that can be utilized. For example, detailed information for configuring a particular type of authentication, additional security for a specified type of transaction or network, encryption level, type of PKI architecture supported, addressing level, etc. may be provided in the capability object. Thus, the requesting entity can discover and ensure that: the required capabilities associated with the alias are firstly compatible with the resource of the requesting entity and secondly provide any transaction with the alias by accessing a machine-readable resource associated with the payment service of the alias.

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

Advantageously, this embodiment enables host discovery of directory-based lookups, i.e. DNS for service records first, followed by capability discovery of one or more functions supported by the payment service. Thus, upon receiving a request for a payment transaction associated with the alias, a service record matching the network identifier in the alias is identified, which in turn provides the location of the host and, in turn, enables the 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.

It will be appreciated that the method for host discovery according to the first aspect is but 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 the preferred implementation may include both host discovery and capability discovery as described above, this combination is not essential to the ability to establish a payment service associated with the alias. In addition to using service records to identify host locations in the first aspect, other methods of host discovery may also be compatible with the second aspect. For example, rather than using the implementation of service-based records discussed in the first aspect, text-based records at a specified network path of a host location may be used. Furthermore, in some embodiments, for the second aspect, host discovery for resolving endpoint identifiers may be skipped entirely, for example, if the location of the host is readily discoverable or has been disclosed, or is associated with the same domain as one or more digital wallets.

Accordingly, the following embodiments are set forth as being based solely on the second aspect, or on a combination of the first and second aspects discussed above.

In some embodiments, in response to receiving a request from a requesting entity for a transaction associated with an alias, the method further includes the step of identifying a payment service associated with the alias based on the network identifier. Then, based on identifying the payment service, the method includes accessing the machine-readable resource from a predictable or known network location. After 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 the host computing resource for the payment service, and based thereon, obtaining a public address associated with the alias according to one or more instructions and/or specifications in the machine-readable resource.

Advantageously, the above embodiments enable the public address associated with the alias to be obtained without knowing only the alias and without knowing other information to contact the payee entity. Further to determining that one or more capabilities in the machine-readable resource comply with one or more requirements of the requesting entity or transaction, the public address is obtained based on an endpoint identifier from the machine-readable resource associated with the payment service. This therefore provides a seamless, simplified and user-friendly technique to obtain the public address of only aliased entities, starting with it.

The above-described embodiments may also be implemented at a requesting client payment entity (i.e., a payer entity that made a request for payment). In this case, the method includes sending a request for the transaction from the requesting entity, the request being associated with the alias. The method includes accessing a machine-readable resource from a location associated with the payment service, wherein the payment service is identified based on the network identifier in the alias, and wherein the machine-readable resource is created as discussed above for the second aspect. The requesting entity then receives an endpoint identifier for a host computing resource for the payment service associated with the alias based on identifying whether one or more capabilities required for the requested transaction are present in the machine-readable resource. The method includes using one or more instructions and/or specifications in the machine-readable resource to obtain a public address associated with the alias.

In some embodiments, each digital wallet is associated with a user or entity that registers payment services in a network, wherein 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 a distributed ledger. In some embodiments, the step of obtaining the public address comprises obtaining a public key of a digital wallet associated with the alias. In some embodiments, the public address associated with the alias is based on a cryptographic hash of a public key of a digital wallet associated with the alias. In a related embodiment, the public key of the digital wallet is an Elliptic Curve Digital Signature Algorithm (ECDSA) public key, where the public key is not part of any transaction previously stored on or published to the distributed ledger.

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

It should be understood that while these instructions reside in a machine-readable resource associated with the payment service, these instructions are intended to be executed by one or more computing resources or applications associated with the payment client entity. One or more computing resources to execute the instructions may be associated with a payment client application installed in or associated with a digital wallet of a payment client entity.

Advantageously, providing a machine-readable document associated with the payment service enables generation of an appropriate request for the payment service in a specified format using a known alias to obtain the public key of the payee entity, which is required to sign a transaction of the distributed ledger.

In some embodiments, the known or predictable location of the machine-readable resource is based on at least one of a configuration specification of the payment service, an internet protocol communication port used by the payment service, and/or an endpoint identifier included in a publicly accessible well-known domain repository. Advantageously, the above enables easy location of machine-readable resources based on the name of the payment service or a domain name associated with the network identifier.

In some embodiments, the machine-readable resource is generated using a JavaScript object notation (JSON) format. This is advantageous because JSON is a lightweight data exchange format that, while primarily a machine readable language, is also easy for humans to read and write. Machines readily parse and generate JSON formats, making them ideal data exchange languages for generating machine-readable resources.

In a third aspect, the present disclosure provides a technique for payment destination addressing. This third aspect is related to the capability discovery of the second aspect in that the machine readable resource is used to resolve the addressing of the payment destination, i.e. for sending the payment. Optionally, the third aspect may also include the host discovery of the first aspect, although this is not required as other forms of host discovery may also be used in conjunction with the third aspect of the present disclosure.

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 discussed above further comprises the step of obtaining a payment destination for a payee entity associated with the alias, the payment destination being used to construct a transaction to make an encrypted currency payment from the payer entity to the alias. The step of building a transaction according to the third aspect comprises accessing the machine-readable resource based on identifying the payment service. This is followed by returning the payment destination 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 including at least an alias associated with the payee entity's digital wallet and an amount of cryptocurrency to be paid to the payee. A digital signature is then obtained that is used to associate the payment details with the encryption key of the payer entity. An output script associated with the payment destination endpoint identifier associated with the alias is then generated for provision to the payer entity. An output script is provided for embedding in a payment transaction for a distributed ledger.

Advantageously, the third aspect enables an output script for a digital wallet associated with an alias to be obtained or received, thereby enabling transactions to be automatically constructed in a suitable format for inclusion on a digital ledger. This is based on knowing only the alias of the payee, with the remaining details being established from a machine-readable resource associated with the host responsible for the payment service. Moreover, being able to leverage knowledge of aliases alone to provide output scripts ready for inclusion in transactions provides an overall simplified, seamless, efficient, automatic, easy to implement, and user-friendly alias-based payment addressing technique for digital wallets.

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

In some embodiments, the method of the third aspect comprises obtaining, from a machine-readable resource, a payment destination request template for a payment destination endpoint identifier. The alias and network identifier are then included in the template to generate a complete payment destination request. An HTTP POST request is then generated based on the complete payment destination request to obtain a payment destination endpoint identifier associated with the alias.

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

Advantageously, providing a machine-readable document associated with the payment service enables a request for the payment service in a specified format to be generated using a known alias in order to obtain a payment destination endpoint identifier or URI, such that this can be used to build a transaction for a distributed ledger.

In some embodiments, the public address of the alias and the public address of the payer entity each comprise a public key of a respective digital wallet associated with the payee entity and the payee entity, and wherein the digital signature is used to verify the identity of the payer entity requesting the transaction. In some related embodiments, a digital signature associated with both the payer entity and the payer entity is required to verify each respective entity before the transaction is stored or published on the distributed ledger.

In a fourth aspect, the present disclosure provides a process or protocol for a case where a payment client (i.e., payer entity) wishes to make a cryptocurrency payment to another payment client (i.e., payee entity). The protocol according to this aspect is hereinafter referred to as a reduced payment protocol. A fourth aspect is related to the capability discovery of the second aspect in that the machine-readable resource of the second aspect is used to implement a simplified payment protocol. In some embodiments, the fourth aspect relates to the payment destination addressing of the third aspect, and provides improved techniques for enabling payment destination addressing, in particular for simplifying the process of such addressing.

A fourth aspect relates to a computer-implemented method of implementing payment services for one or more clients for transactions associated with a distributed ledger (e.g., bitcoin blockchain). In a first implementation, the method is performed by one or more processors associated with a payment service. The method includes updating a machine-readable resource associated with the payment service. In some embodiments, the machine-readable resource is as discussed above with respect to the second aspect and is provided at or accessible from a predictable location or a known location associated with the payment service.

In a fourth aspect, the step of updating the machine-readable resource comprises adding at least one additional capability supported by the payment service, wherein the at least one additional capability comprises: a simplified payment protocol is implemented for a given client associated with the alias among the one or more clients.

A fourth aspect provides all the advantages associated with the second aspect discussed above for discovering one or more capabilities or functions associated with a given payment service implemented for one or more clients, where each client may be associated with a digital wallet in some embodiments. In some embodiments, the digital wallet associated with the payer client and/or the payee client is a Simplified Payment Verification (SPV) wallet. As with the second aspect, all that is required by the requesting entity (i.e. the payer entity) is simply an alias associated with the payee's digital wallet, providing a user-friendly and simplified addressing mechanism and providing a record of all supporting functions or capabilities that may be utilized, or supported by a client associated with the payment entity in a manner that is easily discoverable by any entity wishing to conduct a transaction with such a client.

Another advantage provided by the first implementation of the fourth aspect is that it is easy to provide or add one or more new capabilities to be supported by the payment service. By updating the machine-readable resources provided at predictable or known publicly accessible locations associated with the payment service, the added new capabilities can be automatically pushed out or applied to the payment service for all clients, and the requesting entity will be able to establish such new capabilities now supported upon or as the machine-readable resources are accessed. Thus, new or updated capabilities may be discovered directly and applied to process one or more requests for future transactions associated with the payment service by one or more payment clients.

In some embodiments, in addition to the added capabilities or additional capabilities discussed above, there is an indication specifying whether the additional capabilities, or indeed even the originally created capabilities, are true (on or 1) or false (off or 0). This switching function is advantageous because it enables the payment service to enforce or not enforce one or more capabilities specified in the machine-readable resource for certain types of transactions, or set the enforcement value for certain durations accordingly. Thus, any payment entity (e.g., payer entity) will be able to check whether a particular capability is actually enforced for the type of transaction associated with the request or whether it is enforced when the request is made. For example, if the requesting payment client (i.e., the payer entity in this case) is a client that does not support or respond to messages or instructions regarding such capabilities, the request may be revoked or not sent at all.

In a first implementation of the fourth aspect, at least one new capability is added to the payment service that involves implementing a simplified payment protocol. In some embodiments, the instructions in the machine-readable resource for the payment service are based on provision of a payment transaction template from a payee entity to a payer entity associated with the payment service, wherein the template includes the output script. In some embodiments, the template may include details of the payment required (the amount of bitcoin or digital asset required), including an output list (the endpoint URI for making a payment based on the template from the JSON document), expiration data, and other metadata required to make a payment.

A second implementation of the fourth aspect is also performed by one or more processors associated with the payment service and is related to the implementation of the simplified payment protocol capability added in the first implementation. Here, a computer-implemented method for implementing payment services for transactions associated with a distributed ledger is provided. As with the previous aspects and embodiments, a client associated with a payment service, among one or more clients, is provided with an alias that is specific to the client, each client being provided with a respective alias. The method includes the step of receiving a payment indicator (indicator) from a payer entity for a cryptocurrency payment associated with an alias, the indicator relating to a payee client associated with a payment service among one or more clients, the payee client associated with the alias in the payment indicator. In some embodiments, the indicator or payment indicator is in the form of, or is a request or notification that the payer entity wishes to make a payment for the digital asset to the payee entity. In some embodiments, the indicator may be automatically provided to the payee entity when the payer entity requests the one or more goods or services from the payee entity or obtains the one or more goods or services from the payee entity. The method comprises the following steps: a step of providing a payment request template based on a machine-readable resource associated with a payment service of a payee entity, the payment request template including an output script for the payee entity. In some embodiments, the at least one capability supported by the payee's payment service includes a simplified payment protocol as described above. In some embodiments, the payment request template includes a payment destination endpoint or URI or public address of a digital wallet associated with the payee entity and/or other metadata for the payment. In some embodiments, the payee entity is associated with a digital wallet managed by the payment service. In some embodiments, the digital wallet is a lightweight or SPV wallet. The method comprises the following steps: a complete payment transaction is received based on the payment template from the payer entity, the complete payment transaction being associated with the alias and the network identifier. In some embodiments, the alias may include a network identifier and be included in the template by one or more processors associated with a digital wallet of the payer entity, which may also be an SPV wallet. The method then comprises: the complete payment transaction is provided to a distributed ledger (e.g., blockchain). In some embodiments, the complete payment transaction includes the digital signature and the amount of digital assets or cryptocurrency to be transferred. In some embodiments, the method comprises: before submission to the blockchain, the payer entity is verified as explained in the second aspect above, i.e. the public key is checked to see if the payer entity is associated with the payment service based on the PKI template as described above.

The method set forth above is associated with the same advantages as explained above with respect to adding a new capability for the simplified payment protocol of the first implementation of the fourth aspect. Further, advantageously, processing of digital asset payments (e.g., cryptocurrency payments from payer entities) improves security and reduces the amount of online interaction required to make payments with the payer entities through simplified payment protocol capabilities for payment services.

Security is improved because the simplified payment protocol requires that all details, metadata and output of the payment be added to the payment template to be sent to the payer entity for completion in order to process the cryptocurrency payment. This improves the security of the payment of the digital asset (since the payment is made based on the details sent from the bsvalias payment service). Thus, the present aspect prevents man-in-the-middle (MITM) attacks, given that the output script is encapsulated in the transaction template and sent directly by the payee entity to the payer entity. As discussed with respect to the second aspect, in some embodiments, the payment service specifies instructions for obtaining a public address that is subject to a PKI template to verify an associated public key, as explained with respect to fig. 4.

Advantageously, the simplified payment protocol capability of the first implementation according to another aspect does not require that the payer be online, or in other words always connected to a communication network, to conduct a digital asset transaction to the payee. Because the output script is provided in the template, the payer client does not need to access the payee client's payment service (i.e., the bsvalias payment service) to obtain the endpoint and metadata for the payment transaction for the distributed ledger. Thus, the fourth aspect allows for an offline implementation, which is useful for payer clients (i.e. digital wallets associated with payers) that are not always connected to the communication network, or which is computationally inexpensive, as no interaction with the payment service is required to obtain the payment endpoint.

Further, advantageously, embodiments of the fourth aspect ensure that payments or transactions associated with payee entities are easily searched and monitored, as the payee entity is responsible for issuing to the blockchain. Thus, the payee entity no longer needs to monitor the blockchain with respect to its transactions. The payer client will also be able to use the fourth aspect to identify transactions for a given payee entity. Thus, the complete signed transaction is not issued by the payer entity, but instead is provided to the payee entity by including the alias and network identifier in a payment request template provided in JSON format from a machine readable resource of the payment service. Thus, the simplified payment protocol is similar to the familiar invoice-based payment flow model, which makes it more adaptable and interoperable for businesses or organizations using traditional accounting systems that require purchase orders and the like to perform digital asset payments.

In some embodiments, the output script in the payment request template includes a payment destination that is used to construct a transaction for an encrypted monetary payment from the payer entity to the alias, the output script provided by the payment service of the payee entity by: a machine-readable resource for a payment service is accessed and a payment destination endpoint identifier is obtained based on one or more instructions and/or specifications in a machine-readable document. In some embodiments, the payment destination is identified in a similar manner as explained in relation to the third aspect. The method then comprises: an output script associated with a payment destination endpoint identifier of a payee entity to which the alias belongs is generated.

In some embodiments, the method of the fourth aspect comprises: receiving a complete payment transaction from a payer entity in the form of an HTTPS POST request, the complete payment transaction including payment details of the payment transaction from the payer entity including an alias associated with a payee entity client and an amount of cryptocurrency to be sent to the payee entity, and a digital signature for associating the payment details with an encryption key related to the payer entity. In some embodiments, the HTTPS POST request of the fourth aspect is similar to the HTTPS POST request flow for payment destination in fig. 6, but in this case, the payer entity does not have to access the machine-readable document because the export script is included in the payment request template from the payment service. In some embodiments, if the payer entity is associated with the payment service, the digital signature is verified based on the HTTPS GET request flow to resolve the public key of the payer entity, as seen with respect to fig. 4. The method then comprises: the complete payment transaction is submitted to the distributed ledger.

In some embodiments, the method of the fourth aspect comprises the step of sending a confirmation to the payer entity in response to receiving the complete payment transaction. Advantageously, therefore, this enables the payer entity to track the payment transaction it sends to the payee entity associated with the payment service, and may check the status of the transaction. In some embodiments, the confirmation includes a transaction identifier (TxID) for each transaction.

To implement the fourth aspect, the method performed by the payer entity for a payment transaction to the payee entity comprises the following steps, which are complementary to the above-mentioned method of the fourth aspect implemented by the payment service for the payee client. The method herein comprises: the method may include generating a payment indicator for a cryptocurrency payment associated with an alias associated with the payee client, and sending the payment indicator to the alias based on one or more instructions and/or specifications in a machine-readable resource associated with a payment service for the alias. The method then comprises: a payment request template is obtained from a payment service related to the alias, the payment request template including an output script for the payee entity. The method comprises the following steps: a complete payment transaction is generated based on the obtained payment request template. The generation comprises the following steps: including the alias and the network identifier in a template, applying a digital signature associated with a public key of the payer entity to sign the payment transaction; and providing for payment of an amount including the cryptocurrency to be paid to the alias. The complete payment transaction is then sent as an HTTP POST request to the payee entity associated with the alias.

The above method has the same advantages as discussed above in relation to the method implemented by the payment service according to the fourth aspect, except that it relates to a method taking place at the payer entity.

In some embodiments, the alias is referred to as a payment handle (payment handle) associated with a digital wallet in the network.

Another aspect of the present disclosure relates to a method of configuring a prefix (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, the request comprising the prefix and the alias, the first and/or second and/or third aspects of the present disclosure may be performed automatically by a payment service based on the alias.

Advantageously, this fourth aspect enables the display of only those objects that present a visual representation such as "payto: "or" bsvto: "such prefixes, for example, are automatically triggered when followed by an alias for the payee entity that is known to the requesting entity. The prefix advantageously enables a request for a payment transaction to be generated and sent to a payment service based on one or more of the aspects and embodiments discussed above. All the requesting entity needs to do is to add a known alias to the prefix.

The present disclosure also provides a computing device comprising: a processor; and a memory comprising executable instructions that, as a result of being executed by the processor, cause the computing device to perform any aspect or embodiment of the computer-implemented method described herein.

The present disclosure also provides a system comprising a plurality of such computing devices operable together to implement any of the aspects or embodiments discussed above.

The present disclosure also provides a non-transitory computer-readable storage medium having stored thereon executable instructions that, as 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 a computer-implemented method described herein.

Some specific embodiments are now described by way of illustration with reference to the accompanying drawings, in which like reference numerals refer to like features.

Fig. 1 relates to a first aspect of the present disclosure and depicts a method of implementing payment services for one or more digital wallets associated with aliases. In fig. 1, the method is understood to be implemented by one or more processors associated with providing payment services. In the present disclosure, the payment service may be one or more executable rules or protocols that perform the functions described below. The wallet may be located in a network of digital wallets, or may be a separate stand-alone cryptocurrency wallet for transactions associated with the distributed ledger. For example, the method may be implemented in a network of bitcoin purses for BSV cryptocurrency. For simplicity of explanation and ease of understanding, the alias associated with a digital wallet in a network of digital wallets will be referred to in the following description of the figures. However, as noted above, the present disclosure is not limited in many respects to digital wallets being connected to other wallets in the network.

Step 102 involves assigning or providing an alias for a given digital wallet in a network of digital wallets. This involves providing a mapping or association of the alias with a corresponding public address associated with the digital wallet so that the alias can be used in place of the public address. Such allocation may be made, for example, when a particular payment client or entity registers with the network. At this point, each wallet may be provided with an "alias: public address pair. The alias is unique or unique to a particular wallet and includes a network identifier, such as a domain name of the network, or a name identifying the network. The alias may be, for example, in a well-known email format, such as,[email protected]where the clientname may simply be the name or identifier of the network in which the digital wallet is registered or of the person or company with which the network is registered, e.g., alice or bob. The domain name represents an organization or domain owner, such as "nChain". In this case, Alice would be an alias name[email protected]. If bob registers a different network of digital wallets, possibly with the domain name "notnchain" and also implements one or more aspects and/or embodiments of the present disclosure, bob registersMay be assigned as[email protected]. Other alias formats may also be used, for example, AlicenC or BobBSV, etc., as long as the alias is associated with the network identifier.

Step 104 involves creating a service record for the payment service based on the network identifier in the directory. This step is required to associate the alias with a network identifier that provides the payment service in the directory. The directories referred to herein are typically decentralized directories that are open, i.e., publicly accessible to all users. For example, a global directory such as DNS can be used that is decentralized and open so that any entity or user can access it from anywhere through the Internet. While an open, accessible, and decentralized directory is a preferred implementation, the disclosure is not so limited. In some embodiments, the referenced directory may also be a centralized directory. In other embodiments, the directory may be a closed directory, i.e., a directory accessible by users or entities registered with the network or service. Hereinafter, for convenience of explanation, a global directory such as DNS will be referred to in the description. Those skilled in the art will appreciate that other types of directories are also within the scope of the present disclosure.

For example, when an alias is provided in an input or request in the format described above, a directory such as DNS is searched (c DNS 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 alias-based payment services is entered, one or a combination of the following implementations may be used to handle this situation. In one implementation, the DNS does not return any results to indicate that payment using the alias cannot be made. If no service record exists, the requesting entity would have to obtain the public address through other known techniques before any transaction associated with the distributed ledger could be conducted. In another implementation, for example, when the service may be provided by a parent domain (dame domain) as the network identifier, the result returned may be the location of the host responsible for the network or domain associated with the alias. For example, based on the example discussed above, if there is no service record in the directory for the payment service associated with the network identifier in the alias, the location or URI of the host responsible for the domain "nchain" may be provided, or the requesting entity may be directed to the host of the domain "nchain". Thus, the host responsible for the domain indicated in the alias may further process the request.

Step 106 involves updating or including an entry or field in the service record created in step 104 to indicate the payment service provided by the network or domain associated by the network identifier. Com may indicate that a particular network identifier (e.g., nchain.com) provides or uses a particular payment service, such as a payment service identified as "bsvpay" or "bsvalias. This update step indicates to the entity performing the DNS lookup: the identified payment service (i.e., consider "bsvalias") is able to conduct payment transactions against aliases associated with the nChain domain.

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 network or domain other than the network of the digital wallet, the entry in the service record will point to the network server location or IP address of the host computer or server responsible for the service. Following the example described above, if the bsvalias payment service is associated with a separate network or a separate domain (bsvalias.com), a location or an instruction to locate a hosting server for bsvalias.com is indicated in the service record. This is to identify where a host computing resource configured to facilitate identification of a digital wallet associated with an alias can be found.

An example of a service record (srv record) in DNS that defines the location of a server for a specified service is as follows:

the service record for the domain name (nchain) related to the payment service (bsvalias) may be in the form of, for example:

service: symbolic name of the desired service.

Proto: a transport protocol of the desired service; this is usually the transmission control protocol TCP or the user datagram protocol UDP

Name: the domain name for which the record is valid, ends with a dot.

TTL: a standard DNS time-to-live field that sets an expiration period or limit associated with the record.

Category: a standard DNS category field.

Priority: priority of the target host.

Weight: relative weights of records having the same priority.

Port: the TCP or UDP port on which the service is to be found.

Target: the canonical hostname of the machine that provided the service.

For example, the domain owner of nchain may create an SRV (service) record with the following parameters:

fig. 2a and 2b are flow charts describing a method of identifying a host responsible for a payment service. Fig. 2a illustrates a method implemented by one or more processors associated with a payment service, while fig. 2b illustrates a method implemented by one or more processors associated with a payment client entity.

In step 202a of fig. 2a, the payment service receives a request for a transaction associated with an alias from a requesting entity. The request may be in the form of an input from an interface of a computing device of the requesting entity (i.e., a digital wallet that may be installed). For example, the request may include an indication of payto from the payer entity[email protected]The request of (1).

In step 204a, in response to the request or input in step 202, a search or lookup of the global directory, such as a DNS lookup, is performed based on the alias input. This is to locate a service record for the payment service in the global directory associated with the network identifier in the alias. Thus, using the same example as discussed above for fig. 1, this step would identify the service record for the domain nchain, as shown above, because the nchain in the network identifier in the alias was received. This service record for nchain would then identify bsvalias as a payment service for nchain.

In step 206a, once the service record and thus the payment service, 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 target in the srv record for nchain: a port (target: port) pair. The target is as follows: the port pair provides a location for the service bsvalias that is responsible for host usage or from which to operate.

In step 208a, based on the location of the host, i.e., the target, obtained in step 206 a: the port pair, then, may determine the public address of the digital wallet associated with the alias. In some embodiments, this may be based on a mapping when registering for a payment service or network, such as discussed with respect to fig. 1. Once the public address is obtained, this can be used for bitcoin blockchain transactions between digital wallets.

As noted above, fig. 2b involves steps corresponding to fig. 2a, but implemented on a computing device or digital wallet of the payer or requesting entity.

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

Step 206b involves obtaining a location of a host computing resource associated with the payment service, the location based on the service record associated with the network identifier. This is performed, for example, in steps 204a and 206a of fig. 2 a. Thus, the location obtained here will be the target of the host for the "bsvalias" payment service: a pair of ports.

In step 208b, the public address of the digital wallet associated with the alias is then obtained so that this can be used for transactions associated with the digital ledger.

Fig. 3a and 3b are flow diagrams depicting a method for identifying a public address associated with an alias in a request for a transaction according to a second aspect of the present disclosure. Fig. 3a illustrates a method implemented by one or more processors associated with a payment service, while fig. 3b illustrates a method implemented by one or more processors associated with a payment client entity.

In step 302a of FIG. 3a, a machine-readable resource is created for a payment service. The machine-readable resource is provided to ensure that the functions or capabilities provided or supported by the payment service can be identified and/or any instructions to use those capabilities. This process is hereinafter referred to as capability discovery in relation to payment services. Thus, a machine-readable document is created for the capability discovery process, by which a payment client entity or digital wallet or application wishing to use or request a service can learn or discover the features supported by the payment service, any corresponding endpoints, and configurations associated with using the payment service. In some embodiments, the machine-readable resource is a file or document that was previously generated and saved in association with the payment service, i.e., is a static document. In some embodiments, such as in an enterprise-level service implementation, the machine-readable resources may be dynamic and may be generated on-demand, rather than, for example, as static files saved to a network server. Advantageously, such dynamically generated resources provide a simplification to service deployment, migration, maintenance, and any upgrades that may need to be performed.

In some embodiments, JSON (JavaScript Object Notation), which is a lightweight data exchange format, is used to generate the machine-readable resource. JSON is a text format that is completely language independent, but is familiar to programmers using the C family of languages (including C, C + +, C #, Java, JavaScript, Perl, Python, and many others). These properties make JSON an ideal data exchange language. Furthermore, JSON builds on two structures (a collection of name/value pairs and an ordered list of values). In most languages, this is implemented as an array, vector, list, or sequence. Since these are common data structures, almost all modern programming languages support them in one form or another. Therefore, using JSON for machine readable resources is preferable because it provides a data format that is interchangeable with other programming languages that are also based on these same structures.

The machine-readable resource may include the following information related to 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 the server or computing resource responsible for one or more functions of the payment service, i.e. the target: a pair of ports.

-an entry associated with at least one capability among a plurality of capabilities supported by the payment service. This may be one or more functions such as requesting entity or payer entity verification, multiple digital signatures for the transaction, payee entity or payment destination approval of the transaction, and/or e-mail based payment transaction to send the transaction to an e-mail address associated with the alias before issuing it to a distributed ledger, payer, and/or payee callback function in relation to requests or responses that may be supported by the payment service, etc.

Instructions and/or specifications for accessing a public address (of an entity or digital wallet) that can be used to facilitate transactions 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 the payment service based on the alias. In some embodiments, once obtained, the address in the public address may be used in an output script that is used to build transactions for the distributed ledger. In some embodiments, accessing the public address may include resolving the entity's public key and/or resolving the payment destination, i.e., the payee digital wallet, based on the PKI program.

For example, the machine-readable resource may indicate the following file or entry for the payment service "bsvalias":

the template values { name } and { domain.tld } refer to the alias format<name>@<domain>.<tld>Wherein 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. Thus, in the example above, this would be[email protected]。

Step 304a involves storing the machine-readable resource at a predictable or known location associated with the payment service. For example, the payment service operator or processor of the payment service "bsvalias" may, after creating the JSON formatted text document described in step 302a above, provide the document at the following locations:

https://<host-discovery-target>:<host-discovery-port>/.well-known/ bsvalias。

it is useful to provide a JSON formatted document at a well-known predictable location so that all entities that know the payment service can publicly access it (e.g., based on a network identifier). The above example location is based on the well-known URI resource of the Internet Assigned Numbers Authority (IANA). Thus, the machine-readable resource is placed in a predictable location on the web server for capability discovery related to the payment service bsvalias.

In step 306a, a request for a transaction is received from a payment client entity, the request including an alias to which payment is to be directed. Following the example discussed above, this includes a request, e.g., payto: alice @ nchain.

In step 308a, the payment service associated with the alias is identified. This is based on the network identifier in the alias, i.e. nchain. In which the payment service associated with the identifier, bsvalias, is identified. Host discovery to identify service records according to the first aspect may also be performed before this, although this is not necessary for the embodiment shown in fig. 3. For example, instead of the service record in the first aspect, a mapping stored in a database or a text document based service discovery process may also be used to identify a host for bsvalias.

In step 310a, based on the identified payment service, machine-readable resources of the payment service are accessed from a predictable or known network location. For example, the JSON document for the service bsvalias is obtained from the well-known location specified in step 304 a.

Step 312a determines whether one or more capabilities exist in the machine-readable resource for the requested transaction. This step involves identifying whether one or more entries relating to the supported functionality are appropriate for the request. This may include, for example, checking generic capabilities of payment service support of the requesting client entity and capabilities in JSON documents for bsvalias, i.e., payment services for payee alice @ nchain. In some cases, the requesting entity may not specify or require additional capabilities, in which case the payment transaction may proceed regardless of whether generic capabilities exist.

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

As noted above, fig. 3b involves steps corresponding to fig. 3a, but implemented on a computing device or digital wallet of the payer or requesting entity.

Thus, step 306b involves sending a request for a transaction from the requesting entity, the request being associated with the alias, i.e. sending the payto: alice @ nchain.

In step 310b, after identifying the payment service based on the network identifier in the alias, as described, for example, in step 308a of FIG. 3a, this step includes requesting the client to access the machine-readable resource from a well-known location associated with the identified payment service, as described, for example, in step 304a of FIG. 3 a.

Step 312b involves the requesting entity determining whether one or more capabilities for the requested transaction are present in the machine-readable resource. This step involves checking the JSON document to identify whether one or more entries associated with the generic or specified supported capabilities are appropriate for or required by the requested transaction, similar to step 312a of fig. 3 a.

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

The requesting client then obtains the public address associated with the alias in step 314 b. This may be achieved by requesting the client to perform a function according to one or more instructions and/or specifications in a machine-readable resource.

Fig. 4 depicts an example sequence of instructions specified in the machine-readable resource of the second aspect for implementing Public Key Infrastructure (PKI) techniques to obtain an encryption key associated with an alias.

In step 402, a PKI request template from a machine-readable resource associated with the payment service must be obtained from the machine-readable resource. In some embodiments, the template is a template for requesting a PKI endpoint identifier, which is a URI of a computing resource of a payment service configured to identify and/or verify a public key of a payment client entity. For example, following the example above, the template may be:

"pki":"https://bsvalias.example.org/{name}@{domain.tld}/id

in step 404, once the template has been received, the alias and associated network identifier are included or replaced in the appropriate fields of the template to generate a complete PKI request. For example, the template values { name } and { domain.tld } refer to components of the alias (i.e., < name > @ < domain > < tld >), and must be replaced before issuing a complete request based on the machine-readable resource. The result of this step is to provide the PKI endpoint identifier for "bsvalias".

In step 406, an HTTP GET request is made based on the PKI endpoint identification obtained in step 404.

In step 408, in response to the request set forth in step 406, the public key associated with the alias may then be obtained. In most cases, the public key is a stable Elliptic Curve Digital Signature Algorithm (ECDSA) public key that has not been used as part of any on-chain transaction. If a request for a valid alias (i.e., an alias associated with the payment service and having been assigned a public key) has been received, a return message from the host of the PKI responsible for the payment service may be in the following format to return the public key.

The ECDSA public key will be the compressed and hexadecimal encoded valid point on the secp256k1 curve. This means that the "pubkey" string is 66 bytes long (33 bytes binary, each byte encoded as two hexadecimal characters):

starting length value

0002 "odd/even" indicator, "02" or "03"

0264 elliptic curve point x coordinate

If the request is based on an invalid alias, i.e. an alias not associated with the payment service and/or the public key, the return message will indicate that an error has occurred or that the requested resource is not found or available or authorized.

Fig. 5a and 5b are flow diagrams depicting a method for identifying a payment destination associated with an alias in a request for a transaction according to a third aspect of the present disclosure. The payment destination is used to build transactions for the distributed ledger. Fig. 5a illustrates a method implemented by one or more processors associated with a payment service, while fig. 5b illustrates a method implemented by one or more processors associated with a payment client entity. In some embodiments, obtaining the payment destination is based on obtaining, or is part of, the public address associated with the alias in fig. 3a and 3 b. In some embodiments, the payment destination endpoint identifier is related to an address to be encoded or included in the output script, so that a transaction can be built for the blockchain based on the address. In some embodiments, the payment destination endpoint identifier is the same as the public address described above. In other embodiments, the payment destination endpoint identifier may be different from the public address associated with the alias, or may be part of or associated with the public address of the digital wallet. In some embodiments, the public address and/or payment destination endpoint identifier associated with the alias may be static or dynamically assigned.

Step 502a of fig. 5a involves accessing a machine-readable resource for a payment service, followed by identifying the payment service in the alias. The identity of the payment service and the location of the machine-readable resource may be obtained as described above with respect to fig. 1, 3a, and/or 3 b.

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

In step 506a, payment details for the payment transaction are obtained from the payer entity. This may include, for example, 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 a computing resource or application of the payer entity.

In step 508a, a digital signature for the request is obtained with the payment details in step 506a and an encryption key associated with the payer entity. In most cases, the private key of the requesting party (i.e., the payer entity) is used to apply a signature associated with the request associated with the transaction.

In step 510a, the digital signature may be verified so that the identity of the payer entity may be authenticated. This may be performed using one or more known techniques. In some embodiments, it is assumed that using an ECDSA key, the public key of the payer entity, obtained for example using the PKI sequence in fig. 4, may be used to verify the identity of the signing entity (payer entity). If the verification fails, the digital signature may need to be provided again, or one or more error messages may be generated.

In step 512a, following a successful validation result in step 510a, an output script based on the payment destination endpoint identifier associated with the alias is generated. The output script is provided for embedding in a payment transaction of a distributed ledger to automatically resolve a payment destination in the transaction of the distributed ledger.

For example, an output script returned for a transaction to build a distributed ledger (i.e., a chain of bitcoin blocks) might conform to the following pattern:

{

"output":"..."

}

the value of the output field may be a hexadecimal encoded bitcoin script that the payer entity will use during construction of the payment transaction.

Various possible types of output scripts may be generated, but for ease of illustration, the generation of a pay-to-public key hash (P2PKH) output script is discussed in the following example.

Given a public key of

027c1404c3ecb034053e6dd90bc68f7933284559c7d0763367584195a8796d9b0e, then the P2PKH output script for it might be hexadecimally encoded as:

76a9140806efc8bedc8afb37bf484f352e6f79bff1458c88ac

this can be broken down as follows:

76 ；OP_DUP

a9 ；OP_HASH160

14; push the next 20 bytes into the stack

08 06 ef c8；ripemd160(sha256(compressed_public_key))

be dc 8a fb

37 bf 48 4f

35 2e 6f 79

bf f1 45 8c

88 ；OP_EQUALVERIFY

ac ；OP_CHECKSIG

The service response agent (i.e., the script embedded in the transaction in step 512 a) will then be:

{

"output":"76a9140806efc8bedc8afb37bf484f352e6f79bff1458c88ac"

}

fig. 5b, as described above, involves steps corresponding to fig. 5a, but implemented on a computing device or digital wallet of the payer or requesting entity.

In step 502b, based on a request for a transaction from a payer entity, where the request is associated with an alias, the payer entity accesses a machine-readable resource from a location associated with the payment service.

In step 504b, the payee entity obtains a payment destination endpoint identifier based on one or more instructions and/or specifications in the machine-readable document.

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

Steps 508b and 510b involve the payer entity providing a digital signature for associating the payment details with the encryption key, followed by verification as discussed in the corresponding steps in fig. 5 a.

Step 512b involves receiving, by the payer entity, the output script based on the payment destination endpoint identifier associated with the alias. This is explained above with respect to fig. 5 a.

Step 514b involves a payment transaction by the payer entity building a distributed ledger by embedding the received export script in the transaction.

Fig. 6 depicts an example sequence of instructions specified in a machine-readable resource for implementing a payment destination endpoint resolution sequence associated with an alias for a digital wallet.

In step 602, a payment destination request template from a machine-readable resource associated with a payment service is obtained from the machine-readable resource. In some embodiments, this is a template for requesting the payment destination endpoint identifier discussed in fig. 5a and 5 b. For example, following the example discussed above for payment service bsvalias, the template may be:

"paymentDestination":

https://bsvalias.example.org/{name}@{domain.tld}/payment-destination

in step 604, once the template in step 602 has been received, the alias and associated network identifier are included or replaced in the appropriate fields of the template to generate a complete payment destination request. For example, the template values { name } and { domain.tld } refer to components of the target alias (i.e., < name > @ < domain > < tld >), and must be replaced before issuing a complete request based on the machine-readable resource. The result of this step is to provide a payment destination endpoint identifier, which in some embodiments may be a URI of a computing resource responsible for identifying a payment address to be used for generating an output transaction script associated with the alias.

In step 606, an HTTP POST request is made based on the payment destination endpoint identifier obtained in step 604.

In step 608, an output script associated with the alias and based on the payment destination endpoint identifier is returned, which in turn is used to build a payment transaction for the distributed ledger, as discussed in fig. 5a and 5 b.

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

the following table briefly explains the fields of the above-described schema, with further explanation of some fields given below.

In some embodiments, in addition to including the payee entity's alias, it may be sufficient if the field identified as payerHandle in the above schema exists or is associated with the request. In some embodiments, the payersandle may be associated only with the public identifier or IP or bitcoin address of the payer if the payer entity or digital wallet associated with the payer client does not have an alias for the payment transaction. In the following, payersandle in the present disclosure is described as an alias associated with a payer client entity. Thus, in such embodiments, the payer entity has an alias and is associated with a payment service for facilitating the alias-based payment transaction. The payer's payment service may be the same as or different from the payee's payment service.

In some embodiments, a timestamp field as indicated by "dt" in the table above, along with the payersandle, may be required in the schema for the request. In other embodiments, the timestamp, payerHandle, and signature fields may be requested for certain requests or may be requested to operate according to one or more capabilities present in a machine-readable resource associated with the payee client.

The remaining fields may be optional in terms of the function or operation of the request of interest. However, in many cases, the amount of money (even 0) is usually indicated. But the optional field or non-zero value of the optional field may be present in the request if the optional field or non-zero value of the optional field is known or if information is available to the payment entity (i.e., the payer entity in this case). As explained below, the timestamp and signature fields may be considered necessary for certain payment service capabilities specified in the machine-readable resource.

The timestamp field "dt" may contain the current point in time at which the payer of accepted standard ISO-8601 format initiated the payment destination request. According to JavaScript, this can be built using commands or instructions related to machine-readable resources, e.g., json. This may return, for example, the following:

in some embodiments, the signature field may be based on the ability of the payment entity or client to sign the message and verify the message signature. In most cases this functionality is essentially an implementation of standard ECDSA, but in the case of an (r, s) signature pair of integers r and s, additional information is provided to allow the client to verify the message signature against the P2PKH address (hash of the public key) rather than directly against the public key.

In some embodiments, the signature may be the original (r, s) field computed over the double SHA256 hash of the message, in this case the request discussed above. To utilize an existing bitcoin client library, for example, a BSV library such as MoneyButton or other similar cryptocurrency library, existing signature and authentication protocols may be suitable for some embodiments.

In some embodiments, the implementation of the MoneyButton BSV library is specified as a standard message digest construction and signature encoding method for the signature included in the payment destination request. The message or request to be signed may start with a legacy or known preamble of a bitcoin signature scheme (as recorded in the source code of the BSV library), followed by a Unicode Transformation Format (Unicode Transformation Format) -8-bit (UTF8) string concatenation of the fields payerHandle and dt, and optional money and destination fields discussed in the example modes above.

With respect to the specification of the amount in the request, based on the schema discussed above, the following rules may be applied to some embodiments:

if there is an amount, convert it to a string (zero without leading)

If there is no amount, then the string "0" is used "

If there is no purpose, use the null string "" (in fact the purpose is not included in the message)

Fig. 7a and 7b are flow diagrams depicting a method for implementing a simplified payment agreement for a cryptocurrency payment to a payee client associated with a payment service (e.g., the bsvalias payment service as described with respect to the second and third aspects), in accordance with a fourth aspect of the disclosure.

Fig. 7a illustrates a method implemented by one or more phase processors associated with a payment service for a payee entity, while fig. 7b illustrates a method implemented by one or more processors associated with a payment client entity (i.e., in this case, a payer entity), which may be associated with the same or different payment service as the payment service for the payee entity.

In some embodiments, as discussed with respect to fig. 5a and 5b, the simplified payment protocol of the fourth aspect is based on a payment destination associated with the alias. In some embodiments, the payment destination refers to an address to be encoded or included in the output script so that a transaction can be built for a distributed ledger (i.e., blockchain) based on the address. In some embodiments, the payment destination is an endpoint identifier. In other embodiments, the payment destination endpoint identifier may be different from, or may be part of or associated with, the public address of the digital wallet associated with the alias. In some embodiments, the public address and/or payment destination endpoint identifier associated with the alias may be static or dynamically assigned. Embodiments of the fourth aspect as explained with respect to fig. 7a and 7b may be implemented with a digital wallet being an SPV wallet of a payee entity and/or a payer entity. However, this is not required in view of the payment services, such as bsvalias set forth in the above aspects, which may be implemented for any type of computing device or wallet.

In the present non-limiting illustration of the fourth aspect for a payment transaction between two payment entities, following the above example, let us assume that alice (the payer) wants to make a payment to bob (the payee), where both parties use the same type of SPV wallet. It is well known that SPV wallets store private and public keys of users, unconsumed transactions and block headers. Such wallets also have the ability to connect to a blockchain. The term "blockhead" is known in the art and is used to refer to data provided at the top of a block of a blockchain transaction. The block header uniquely identifies the block so it can be located on the block chain. It includes a data field that provides a unique digest or fingerprint of the entire chunk's content. The chunk header includes a Merkle Root (Merkle Root), which is the hash value of all transactions in the chunk. The user can then search the mercker tree with the root to check (i.e., verify) whether a particular transaction is included in a particular tile on the blockchain without downloading the entire blockchain. An advantage of the SPV wallet is that it enables power and storage limited devices such as cell phones and laptops to operate in a blockchain network, as it only needs to check whether the transaction has been verified (hence the term "simplified payment verification"), rather than a full check of the blockchain as with other forms of digital wallets. The following applicant's uk patent application for blockchain Holdings Limited (nChain Holdings Limited) describes in detail an improved security scheme for verification over blockchain networks using low bandwidth SPV systems: GB1902086.6, GB1902088.2, GB1902090.8, GB1902089.0 and GB1902092.4, all of which were filed on 2/5/2019. The SPV wallet implementations in these applications may also be used to implement the fourth aspect of the present disclosure, but the present disclosure is not limited to the use of such SPV wallets.

An embodiment of the fourth aspect will now be discussed with respect to fig. 7a, where the method is implemented by one or more processors associated with a payment service for a payment client (in this case, a payee entity).

Step 702a depicts receiving a payment indicator from a payer entity for a cryptocurrency payment associated with an alias for a payee client. Thus, following the example in the previous embodiment, this step involves getting a request from alice to pay bob, where alice indicates that a cryptocurrency payment (i.e., 3BSV) is to be made to alice's known alias to bob (i.e., bob @ nchain. In this case, the alias comprises the name "bob" and the network identifier "nchain". However, as described in the above aspect, the name in the alias may be a network identifier or a representation of a network identifier. The network identifier may be tld, the top level domain name. This may be in the form of a notification message that the payer client sends or generates when it intends to use or purchase the goods or services provided by bob, or when such use is made of the goods or services provided by bob. In this case, bob may be considered a merchant, and alice may be considered a customer.

In step 704a, upon receiving the payment indicator, the payment service (which is bsvalias in the example discussed above) accesses a machine-readable resource (i.e., a JSON document) to identify bob's (i.e., payee client's) capabilities available with respect to such payment. Com, this capability may be specified in JSON documents for bsvalias by:

the template values { name } and { domain.tld } refer to components of the payee alias (i.e., < name > @ < domain > < tld >). This will be replaced by the user or another payment client before issuing a request for the capability. In this example, 3b585cdaa4cd may be an entry identifier, which refers to a reduced payment capability in a machine-readable document.

Com, the payment service for the payee client generates an output script for payments made to bob based on the payment identifier received from alice in step 702 a. The output script will be included in the payment request template, which may be sent directly to the payer client (i.e., alice in this example).

In this step, the capability identified as 3b585cdaa4cd in step 704a returns a path from a well-known/bsvalias document (i.e., a machine-readable resource for bsvalias) in the form of a URI template, referred to herein as a payment request template. The output script will be associated with the payment destination endpoint for the payment and may indicate other metadata of the output script, such as an expiration time/date, etc. The payment request template generated based on the output script may include the following examples:

in the above example, the use of the "transactions" array indicates that it is a transaction template or pseudo transaction. In some embodiments, this allows batch commit, i.e., batch addition to the blockchain, without requiring multiple HTTP requests.

In this example, the txid, scriptSig, and scriptPubKey fields all refer to hexadecimally encoded raw bitcoin binaries. The example value field is an integer representing satoshis. However, it will be understood that the present disclosure and associated embodiments are not limited to bitcoins or BSVs or satoshes.

In step 708a, the payment request template is sent by the payment service directly to the payer entity along with the output script generated in step 706 a. In some embodiments, if the payer entity uses a payment service such as bsvalias, the payment request template is sent to the alias of the payer entity (i.e., alice @ nchain.com or alice @ notnchain.com).

In step 710a, a complete payment transaction based on the template in step 706a is received from the payee entity. This is received as an HTTPS POST request, similar to the request flow set forth in fig. 6 with respect to payment destination addressing, where the alias (i.e., name and network identifier) is added to the template along with the details of the crypto-currency payment to be made. The complete payment transaction received is in a format ready for submission to the blockchain because the output script is already included in the template. The received complete payment transaction is signed by the payer entity. In this step, the digital signature associated with the public key of the payer entity may be verified, for example using an HTTPS GET request associated with a PKI template as set forth in fig. 4.

In step 712a, the payee entity submits the complete transaction from step 710a to the distributed ledger.

Advantageously, the methods and embodiments of the fourth aspect enable wallets, processors and/or computing devices associated with payee entities to more easily track upcoming transactions, rather than scanning each transaction and each tile in a chain of tiles, or relying on bloom filtered connections (bloom filtered connections) to do those things. Thus, as the number of upcoming payments and transactions of a node (i.e., payee entity bob in this example) increases, the present embodiments ensure that all and any number of such transactions can be easily tracked, thereby ensuring reliability and scalability of the blockchain-based payment service.

This aspect also increases the security of payment transactions made for payee clients, which must be verified before the payer's digital signature is submitted to the blockchain, an additional security measure. The payment service for the payee client may choose to deny signed transactions that are not paid to the key associated with the alias in the payment request template. When the request is denied, the payment service may select any HTTP status code, such as 401 (unauthorized), 204 (no content), or 404 (not found)

Fig. 7b relates to steps corresponding to fig. 7a but implemented on a computing device or digital wallet of a payer or requesting entity.

Step 702b involves generating a payment indicator for a crypto-currency payment associated with an alias associated with a payee client associated with the payment service. Following the explanation in step 702a, in the non-limiting embodiment shown, the payee's alias is bob @ nchain. As described above, this indicator may be automatically generated, or may be a message or notification sent from the payer entity (i.e., alice) that BSV payment should be made to bob. In some embodiments, the payment indicator may be sent using an http GET request as set forth with respect to fig. 4, since the payer alice only knows the alias of bob (i.e., bob @ nchain.com), but this is not required.

In step 704b, a payment request template is received from a payment service associated with the payee client. As described above in step 704a, the payment request template includes all the particulars and output scripts for the blockchain transaction to make a payment to the payee entity.

In step 706b, one or more processors associated with the payer entity or their wallet generate a complete payment transaction based on the obtained payment request template by: the alias and associated network identifier are included in the template, replacing the template values { name } and { domain.tld } for components that refer to the payee alias (i.e., < name > @ < domain > < tld > in the URI received from the payee entity). In addition, payment details including the amount of the cryptocurrency are added to complete the transaction template from the payee entity.

At step 708b, a digital signature associated with the public key of the payer entity is applied to sign the complete payment transaction. This is so that the identity of the payer entity may be verified, as described with respect to step 710 a.

In step 710b, the complete and signed payment transaction is sent to the payee entity associated with the alias based on the output script in the template received in step 704 b. This is provided as an HTTPS POST request after replacing the payee's alias, as shown in step 710 a. In some embodiments, once the complete payment transaction is sent, the payer entity may receive confirmation of the cryptocurrency payment from the payment service associated with the payee entity. This may be used to track or monitor payments associated with a payer entity (i.e., alice).

Turning now to fig. 8, an illustrative simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure is provided. In various embodiments, computing device 2600 may be used to implement any of the systems shown and described above. For example, computing device 2600 may be configured to function 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 payment services, or to implement a payer or payee payment client entity. Computing device 2600 may thus be a portable computing device, a personal computer, or any electronic computing device. As shown in fig. 8, computing device 2600 may include one or more processors (collectively 2602) having one or more levels of cache memory and a memory controller, which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a persistent storage 2610. As shown, main memory 2608 may include a Dynamic Random Access Memory (DRAM)2618 and a Read Only Memory (ROM) 2620. Storage subsystem 2606 and cache 2602 may be used to store information, such as details associated with transactions and blocks described in this disclosure. The processor(s) 2602 may be used to provide the steps or functions of any of the embodiments described in this disclosure.

The processor(s) 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.

Bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of computing device 2600 to communicate with one another as intended. Although bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface to receive data from and transmit data to other systems, different from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network such that the data technician may transmit data to and receive data from the device while located at a remote location (e.g., a data center).

The user interface input devices 2612 may include one or more user input devices, such as a keypad; a pointing device such as an integrated mouse, trackball, touchpad, or tablet; a scanner; a bar code scanner; a touch screen incorporated into the display; audio input devices such as voice recognition systems, microphones, etc.; and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to computing device 2600.

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 be a Cathode Ray Tube (CRT), a flat panel device such as a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, or a projector, or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications that perform the described processes and variations therein, when such interaction is appropriate.

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

Computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device that may be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, lightning connector, etc.). Devices that can connect to the computing device 2600 can include a plurality of ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals to electrical signals that may be transmitted for processing through a port connecting the device to the computing device 2600. Due to the ever-changing nature of computers and networks, the description of computing device 2600 depicted in fig. 8 is intended only as a specific example for purposes of illustrating the preferred embodiments of the device. Many other configurations are possible with more or fewer components than the system depicted in fig. 8.

Illustrative example embodiments

1. A computer-implemented method of implementing a payment service for one or more clients for transactions associated with a distributed ledger, the method comprising the steps of:

providing an alias for a given client among the one or more clients, the alias being specific to the given client, the alias including or being associated with a network identifier;

associating the alias with a network identification in a directory, the step of associating comprising:

creating a service record based on the network identifier in the directory;

updating the service record to indicate that the payment service is provided by a network or domain associated with a network identifier; and

updating the service record to indicate a location of a host computing resource responsible for the payment service, wherein the host computing resource is configured to facilitate identification of a digital wallet associated with the alias in response to a request for a transaction related to the alias.

2. The method of clause 1, wherein each of the one or more clients is associated with a digital wallet.

3. The method of clause 1 or clause 2, comprising:

in response to a request from a requesting entity for a transaction related to the alias, performing a search of the directory based on the alias;

identifying a service record for the payment service in a directory associated with the network identifier; and

returning a location of a host computing resource for the payment service, wherein a public address of a client associated with the alias is determined based on the returned location, the public address being used in the transaction.

4. A method associated with a transaction of a distributed ledger wherein a given client among one or more clients is provided with an alias, the alias being specific to the given client, the alias comprising or being associated with a network identifier, the method comprising the steps of:

sending a request for a transaction from a requesting entity, the request associated with the alias;

obtaining a location of a host computing resource associated with a payment service, the location based on a service record related to a network identifier identified in a search of a directory; and wherein a public address of a client associated with the alias is determined based on the location, the public address being used in the transaction.

5. The method of clause 4, wherein each of the one or more clients is associated with a digital wallet.

6. The method of any of clauses 3-5, wherein returning or obtaining the location of the host computing resource comprises returning or obtaining a target and a port pair, wherein the target comprises an identifier of the host computing resource, and wherein the port comprises an identifier of an internet protocol communication port used by the payment service.

7. The method of any preceding clause, wherein the host computing resource is associated with a payment network that is different from a network associated with the network identifier of the alias, and wherein payment services of one or more entities registered with the network are delegated to a payment domain associated with the payment network.

8. The method of clauses 1-7, wherein the host computing resource is associated with a payment network, and wherein the domain of the payment network is the same as the domain of the network associated with the network identifier of the alias.

9. A computer-implemented method of implementing a payment service for one or more clients for transactions associated with a distributed ledger, the method comprising:

creating a machine-readable resource associated with the payment service, wherein the machine-readable resource comprises:

at least one endpoint identifier associated with a host computing resource responsible for conducting payment services for each client, each client associated with an alias that includes or is related to a network identifier;

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 the alias, the public address for facilitating a transaction associated with the alias; and

providing the machine-readable resource at a predictable or known location associated with the payment service.

10. The method of clause 9, wherein each of the one or more clients is associated with a digital wallet.

11. The method of clause 9 or 10, wherein the plurality of capabilities comprise one or more of:

the payer entity or the payee entity verifies,

a plurality of digital signatures for the transaction,

the payee entity approves the transaction,

a payment transaction associated with an e-mail agreement,

simplified payment protocol or flow for payment transactions, and/or

Callback requests or responses.

12. The method of any of clauses 9-11, further comprising: a step of determining a location of the host computing resource by the method according to any of clauses 1-3 and 6-8, wherein an endpoint identifier in the machine-readable resource is based on the determined location.

13. The method according to any of clauses 9 to 12, wherein in response to a request from the requesting entity regarding a transaction associated with an alias, the method further comprises the steps of:

identifying a payment service associated with the alias in the request based on a network identifier associated with the alias;

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 a host computing resource for the payment service in response to identifying whether one or more capabilities required for the transaction are present in the machine-readable resource; and

obtaining a public address associated with the alias based on one or more instructions and/or specifications in the machine-readable resource.

14. A method associated with a transaction of a distributed ledger wherein a given client among one or more clients is provided with an alias, the alias being specific to the given client, the alias comprising or being associated with a network identifier, the method comprising the steps of:

sending a request for a transaction from a requesting entity, the request associated with the alias;

accessing a machine-readable resource from a location associated with the payment service, wherein the payment service is identified based on a network identifier in the alias, and wherein the machine-readable resource is created according to clause 9;

receiving an endpoint identifier for a host computing resource of a 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; and

obtaining a public address associated with the alias using one or more instructions and/or specifications in the machine-readable resource.

15. The method of any of clauses 13 or 14, wherein each client is associated with a digital wallet related to a user or entity that registers payment services in a network, wherein each digital wallet is a cryptographic money wallet associated with a public and private key of an asymmetric cryptographic key pair for transactions on a distributed ledger, and wherein the step of obtaining the public address comprises obtaining a public key of a digital wallet associated with the alias.

16. The method of clause 15, wherein the public address associated with the alias is based on a cryptographic hash of a public key of a digital wallet associated with the alias.

17. The method of any of clauses 15 or 16, wherein the public key of the digital wallet is an Elliptic Curve Digital Signature Algorithm (ECDSA) public key, wherein the public key is not part of any transaction previously stored on or published to the distributed ledger.

18. The method of any of clauses 13-17, wherein the one or more instructions and/or specifications in the machine-readable resource comprise:

obtaining, from the machine-readable resource, a Public Key Infrastructure (PKI) request template for a Public Key Infrastructure (PKI) endpoint identifier;

including the alias and network identifier in the template to generate a complete PKI request; and

sending an HTTP GET request based on the complete PKI request to obtain a public key associated with the alias.

19. The method of any of clauses 9-18, wherein the known or predictable location of the machine-readable resource is based on at least one of an endpoint identifier included in a publicly accessible well-known domain repository, an internet protocol communication port used by a payment service, and/or a configuration specification of a payment service.

20. The method of any of clauses 9-19, wherein the machine-readable resource is generated using a javascript object notation (JSON) format.

21. The method of any of clauses 13 and 15 to 20, wherein the step of obtaining the public address associated with the alias comprises obtaining a payment destination of a payee entity associated with the alias, the payment destination being used to construct a transaction for making a cryptocurrency payment from a payer entity to the alias, the method comprising the steps of:

accessing the machine-readable resource for the payment service;

returning a payment destination endpoint identifier based on one or more instructions and/or specifications in the machine-readable document;

obtaining payment details for the transaction from the payer entity, the payment details including an alias associated with a payee entity client and an amount of cryptocurrency to be paid to a payee;

obtaining a digital signature for associating the payment details with an encryption key associated with the payer entity; and

generating an output script associated with the payment destination endpoint identifier associated with the alias, the output script provided for embedding into transactions of the distributed ledger.

22. The method of any of clauses 14 to 20, wherein the step of obtaining the public address associated with the alias comprises obtaining a payment destination of a payee entity associated with the alias, the payment destination being used to construct a transaction for making a cryptocurrency payment from a payer entity to the alias, wherein the step of constructing the transaction comprises:

sending a request from the payer entity for the transaction, the request being associated with the alias;

accessing the machine-readable resource from a location associated with the payment service;

receiving a payment destination endpoint identifier based on one or more instructions and/or specifications in a machine-readable document;

providing payment details for the transaction, the payment details including an alias associated with a payee entity client and an amount of cryptocurrency to be paid to a payee entity;

providing a digital signature for associating the payment details with an encryption key;

receiving an output script associated with the payment destination endpoint identifier, the payment destination endpoint identifier associated with the alias; and

creating a transaction by embedding the received output script into a transaction of the distributed ledger.

23. The method of clause 21 or 22, wherein the one or more instructions and/or specifications in the machine-readable resource comprise:

obtaining a payment destination request template for a payment destination endpoint identifier from the machine-readable resource;

including the alias and the network identifier in the template to generate a complete payment destination request; and

sending an HTTP POST request based on the complete payment destination request to obtain a payment destination endpoint identifier associated with the alias.

24. The method of any of clauses 21-23, wherein the public address of the alias and the public address of the payer entity each include a public key of a respective digital wallet associated with the payee entity and payee entity, and wherein the digital signature is used to verify the identity of the payer entity.

25. The method of any of clauses 21-24, wherein a digital signature associated with both the payer entity and the payee entity is required to verify each respective entity before the created transaction is stored or published on the distributed ledger.

26. A computer-implemented method of implementing a payment service 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 being created according to clause 9, the updating step comprising:

adding at least one additional capability supported by the payment service, wherein the at least one additional capability comprises implementing a simplified protocol for processing digital assets of a given client among the one or more clients.

27. A computer-implemented method of implementing a payment service for transactions associated with a distributed ledger, wherein a client associated with the payment service among one or more clients is provided with an alias, the alias being specific to the client, each client being provided with a respective alias, the method comprising the steps of:

receiving, from a payer entity, a payment indicator for a cryptocurrency payment associated with an alias, the indicator relating to a payee entity associated with the payment service among the one or more clients, the payee entity associated with the alias in the payment indicator;

providing a payment request template based on a machine-readable resource according to clause 9, the machine-readable resource associated with a payment service, the payment request template including an output script for a payee entity;

receiving a complete payment transaction based on a payment template from a payer entity, the complete payment transaction being associated with an alias and a network identifier;

providing the complete payment transaction to a distributed ledger.

28. The method of clause 27, wherein the payee entity's payment service is implemented by the method of clause 26, and wherein the at least one capability supported by the payee entity's payment service is based on the at least one additional capability in the updated machine-readable resource of clause 26.

29. The method of any of clauses 27 or 28, wherein the output script in the payment request template includes a payment destination for building a transaction for a cryptocurrency payment from a payer entity to an alias, the output script provided by:

accessing a machine-readable resource for the payment service;

obtaining a payment destination endpoint identifier based on one or more instructions and/or specifications in the machine-readable document; and

generating an output script associated with a payment destination endpoint identifier of a payee entity to which the alias belongs.

30. The method of any of clauses 27 or 29, wherein the method comprises the steps of:

receiving a complete payment transaction in the form of an HTTPS POST request from the payer entity, the complete payment transaction including:

payment details of a payment transaction from the payer entity, the payment details including an alias associated with a payee entity and an amount of cryptocurrency to be sent to the payee entity, an

A digital signature for associating the payment particulars with an encryption key associated with the payer entity; and

submitting the complete payment transaction to a distributed ledger.

31. The method of clause 30, including the step of sending a confirmation to the payer entity in response to receiving the complete payment transaction.

32. A computer-implemented method associated with transactions of a distributed ledger, wherein a client associated with a payment service among one or more clients is provided with an alias, the alias being specific to the client, each client being associated with a respective alias, the method comprising the steps of:

generating a payment indicator for a crypto-currency payment associated with an alias associated with a payee entity associated with the payment service among the one or more clients; (ii) a

Sending the payment indicator to the alias based on one or more instructions and/or specifications in a machine-readable resource associated with a payment service for the alias as set forth in clause 9;

obtaining a payment request template from a payment service associated with the alias, the payment request template including an output script for the payee entity;

generating a complete payment transaction based on the obtained payment request template by:

including the alias and network identifier of the payee entity in a template;

applying a digital signature associated with a public key of a payer entity to sign the payment transaction; and

providing a payment comprising an amount of cryptocurrency to be paid to the alias; and

sending the complete payment transaction to a payee entity associated with the alias.

33. The method of clause 1, including the step of receiving confirmation of the cryptocurrency payment from a payment service associated with the payee entity.

34. The method of any preceding clause, wherein the alias is a payment handle associated with the client.

35. A method for configuring a prefix for a proposed request relating to a transaction from a requesting entity to an alias associated with a client, the method comprising, in response to receiving a request from a requesting entity comprising the prefix and the alias, the step of triggering any of the preceding terms based on the alias.

36. A computer device or computer system comprising:

a processor; and

a memory comprising executable instructions that, as a result of being executed by the processor, cause the system to perform the computer-implemented method of any of the preceding clauses.

37. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any one of clauses 1 to 35.

It should be noted that the above-mentioned embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, "comprising" means "including" or consisting of … … (containing of) ", and" comprising "means" including "or consisting of … … (containing of)". The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the 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 measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.