System and method implemented by computer for implementing alias-based addressing for distributed ledger

Abstract

To provide a method for implementing a payment service for a client for a transaction associated with a distributed ledger as a blockchain.SOLUTION: The method includes the steps of: providing an alias to a client; associating the alias with a network in a directory; and providing a location of a host computing resource for the payment service in which the host computing resource realizes identification of the client associated with the alias. The method also includes the step of generating a machine-readable resource at a location associated with a payment service in which 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 an instruction or specification for accessing a public address to implement a transaction associated with an alias.SELECTED DRAWING: Figure 3A

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for implementing transactions associated with a distributed ledger, and more particularly to a method for destination addressing for one or more digital wallets. The present disclosure is particularly suitable for providing, but not limited to, a method for realizing cryptocurrency payments from a recipient to a payer.

Background Art

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

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

[0004] For a transaction to be written to the blockchain, it must be verified. Network nodes (miners) perform work to ensure that invalid transactions are rejected from the network and that each transaction is valid. The software client installed on the nodes performs this verification work on the unspent transaction outputs (UTXOs) by executing the lock and unlock scripts for the UTXOs. If the execution of the lock and unlock scripts evaluates to true (TRUE), the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it is necessary that (i) it is verified by the first node that receives the transaction and, if the transaction is valid, the node relays the transaction to other nodes within the network, (ii) it is added to a new block constructed by the miner, and (iii) it is mined, i.e., added to the public ledger of past transactions.

[0005] When stored on the blockchain as UTXOs, users can transfer control of the associated cryptocurrency to another address associated with an input within another transaction. This is often done using a digital cryptocurrency wallet. The digital wallet may be associated with a device, physical medium, program, application (app) on a mobile device, or a remotely hosted service on a network such as the Internet. The digital wallet may store public and private keys, track ownership of assets etc. associated with the user, and can be used to receive or spend cryptocurrency. The cryptocurrency itself does not exist within the digital wallet. In Bitcoin and cryptocurrencies derived therefrom, the cryptocurrency is stored and maintained decentralized in a publicly available ledger, i.e., within the blockchain. There are various forms of known cryptocurrency wallets, and the network of such wallets is called an ecosystem such as the ecosystem of the BitcoinSV (BSV) wallet. The digital wallet may be a Simplified Payment Verification (SPV) wallet.

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

[0007] Therefore, Alice needs to know or be provided with this type of address to send cryptocurrency to Bob. Further, for different types of transactions, more than one address may be used by an entity or wallet, and these addresses can only be used once to effectuate one transaction written to the blockchain. Clearly, these public addresses are not user-friendly or easy for users, or not memorable, and thus, these public addresses or keys for transactions need to be identified or obtained or derived for each transaction and further may need to be stored / cached for a specific period by an entity wishing to make a cryptocurrency payment to another entity.

[0008] Accordingly, while it is desirable to use blockchain technology to record data and events because blockchains offer advantages such as tamper resistance and permanent recording, it is difficult to identify or establish destination addresses for cryptocurrency payments. This is because the practical formats of these addresses recognized in the wallet ecosystem are not simple or user-friendly. One reason for this format may be security in line with a specific naming protocol for public IP addresses applied across digital payment networks. Another reason is that the Bitcoin blockchain allows data to be embedded in transactions (Tx) built into blocks. Identifying and accessing relevant data from the blockchain is based on the public address (linked to the private key) of the entity associated with the transaction. The present disclosure addresses these technical concerns by providing aspects and embodiments for improved destination identification and / or payment addressing for the cryptocurrency ecosystem.

[0009] Throughout this specification, variations such as the terms "comprise," "includes," "comprises," "comprising" are understood to mean including the stated element, integer or step, or group of elements, integers or steps, but do not exclude any other element, integer or step, or group of elements, integers or steps.

Brief Description of the Drawings

[0010] Aspects and embodiments of the present disclosure are described below by way of example only and with reference to the accompanying drawings.

Figure 1

Figure 2A

Figure 2B

Figure 3A

Figure 3B

Figure 4

Figure 5A

Figure 5B

Figure 6

Figure 7A

Figure 7B

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

[0011] According to a first aspect of the present disclosure, a computer-implemented method is provided for performing a payment service for one or more clients for transactions associated with a distributed ledger. The method includes providing an alias for a given client, the alias being unique to the given client and including or related to a network identifier. The method then includes associating the alias with the network identifier in a directory. This association is achieved by generating a service record based on the network identifier in the directory. The service record is then updated to indicate that the payment service is provided by a network or domain associated with the network identifier and the location of the host computing resources that perform the payment service. Here, the host computing resources are configured to realize the identification of the client associated with the alias in response to receiving a request regarding a transaction associated with the alias.

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

[0013] In the first aspect, one or more of the digital wallets described above is one of a plurality of digital wallets within a network sometimes referred to as an ecosystem of digital wallets, such as an ecosystem of multiple Bitcoin BSV cryptocurrency wallets. In other embodiments, the wallet need not be part of a network of wallets and may simply be a separate, stand-alone entity associated with a domain. In either case, the network identifier may be, or may include, the domain name of the network, such as nchain.com. In some embodiments, the directory may be a public type, such as the DNS (Domain Naming System), i.e., an accessible and / or decentralized system, and may be referred to as a global directory. The location of the host computing resources may be the location of a server responsible for providing payment services of the network. For example, this may be an endpoint URI (Universal Resource Identifier) and may include the URL (Universal Resource Location) of a web server from which payment services may be accessed by other entities. For example, the other entity may be a digital wallet that may or may not be associated with a network identifier, one or more payment servers or client entities, or a portion of the network associated with a payment application.

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

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

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

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

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

[0019] In some embodiments, the host computing resources are associated with a payment network different from the network identifier associated with one or more digital wallets, and the payment service for a plurality of entities registered in a domain associated with the network identifier is delegated to a domain associated with the payment network.

[0020] Advantageously, this enables the network to delegate the alias-based payment to be managed and provided by a third-party network associated with a completely different domain.

[0021] In an alternative embodiment, the host computing resources are associated with the same domain as the domain of the network identifier. Alternatively, the domain owner may choose to implement the payment service within the network. In this case, the endpoint identifier in the service record is set to or updated to reference the same domain as the (digital wallet's) network. Advantageously, using the service record to indicate the host or endpoint responsible for the alias-based payment service directly adds or changes the payment service provider for the digital wallet or the digital wallet's network. When the service record is updated, the request or lookup search can continue seamlessly if the new host location is indicated within the service record.

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

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

[0024] Advantageously, the second aspect provides a means for discovering one or more capabilities or functions associated with a given payment service implemented for one or more digital wallets. Similar to the first aspect, all that is required by the requesting entity is the alias of the payer or payee entity, i.e., the alias associated with the recipient's digital wallet. Thus, a user-friendly and simplified addressing mechanism is provided. This advantage is ensured by the provision of a publicly accessible machine-readable resource that specifies the functions or capabilities provided by the payment service implemented for the digital wallet. This second aspect of discovering the capabilities of the payment service based solely on knowledge of the alias of the recipient entity is particularly useful when the payer entity associated with the digital wallet desires to ensure that the capabilities or functions for the transaction are supported when making a payment to the alias before a transfer request is made. Certain functions may be considered keys for implementing cryptocurrency payment transactions associated with a distributed ledger, for example, for identifying at least one endpoint identifier associated with the payment service, or for implementing a secure communication mechanism based on PKI (public key infrastructure), etc. These functions are often specified separately from the capability entries in the machine-readable resource. Advantageously, the capability entries enable the provision of specifications of all available supporting functions, i.e., records. For example, details for constituting a particular type of verification, additional security for a specified type of transaction or network, level of encryption, type of PKI architecture supported, level of addressing, etc. may be provided within the capability object. Thus, the requesting entity can discover and ensure that the requested capabilities associated with the alias are first compatible with the resources of the requesting entity and then provided to any transaction having the alias by accessing the machine-readable resource associated with the payment service of the alias.

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

[0026] Advantageously, this embodiment first enables discovery of the host based on a DNS lookup of a directory, i.e., a service record, and subsequently enables discovery of the capabilities of one or more functions supported by the payment service. Accordingly, upon receiving a request for a payment transaction associated with an alias, a service record that matches the network identifier within the alias is identified, which provides the location of the host and enables obtaining the endpoint identifier. The capabilities discovery according to the second aspect is then performed based on the endpoint identifier within the machine-readable resource.

[0027] It is understood that the method according to the first aspect for host discovery is just one of many host discovery methods that can be performed before capabilities discovery based on the machine-readable resource is performed according to the second aspect. Accordingly, the first aspect can be executed independently of the second aspect, and vice versa. A suitable implementation may include both the host and capabilities discovery described above, but this combination is not essential for establishing the capabilities of the payment service associated with the alias. Other methods of host discovery may also be compatible with the second aspect in addition to the use of service records in the first aspect for identifying the host location. For example, a text-based record in a specified network path of the host location may be used instead of the implementation based on service records discussed in the first aspect. Further, host discovery for resolving the endpoint identifier may be skipped together in the second aspect in some embodiments, for example, when the location of the host is easily discoverable or publicly available, or when it is associated with the same domain as one or more digital wallets.

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

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

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

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

[0032] In some embodiments, each digital wallet is associated with a user or entity registered for a payment service within a network, and each digital wallet is a cryptocurrency wallet associated with a public key and a private key of an asymmetric cryptographic key pair for a transaction on a distributed ledger. In some embodiments, the step of obtaining a public address includes obtaining the 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 the public key of the digital wallet associated with the alias. In related embodiments, the public key of the digital wallet is an elliptic curve digital signature algorithm (ECDSA) public key, and the public key is not part of any transaction previously stored or posted to the distributed ledger.

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

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

[0035] Advantageously, the provision of a machine-readable document associated with a payment service enables the generation of an appropriate request in a specified format for the payment service to obtain the public key of a recipient entity using a known alias. The public key is required to sign transactions for a distributed ledger.

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

[0037] In some embodiments, the machine-readable resource is generated using the JSON (JavaScript Object Notation) format. This is advantageous because JSON is first and foremost a machine-readable language but is also a lightweight data exchange format that is easy for humans to read and write. It is easy for machines to parse and generate, making it a useful data exchange language for generating machine-readable resources.

[0038] In a third aspect, the present disclosure provides techniques for payee addressing. This third aspect is related to the second aspect of capability discovery because the machine-readable resource is used to address the payee, i.e., to send a payment. Optionally, the third aspect may also include the first aspect of host discovery, although this is not qualitative as other means of host discovery may also be used in combination with the third aspect of the present disclosure.

[0039] A third aspect of the present disclosure provides a method that further includes, in addition to the step of obtaining a public address associated with an alias in the second aspect described above, the step of obtaining a payee of the recipient entity associated with the alias, where the payee is used when constructing a transaction for making a cryptocurrency payment from a payer entity to the alias. The step of constructing a transaction according to the third aspect includes accessing a machine-readable resource based on identifying a payment service. Subsequently, based on one or more instructions and / or specifications within the machine-readable document, a step of returning a payee endpoint identifier follows. Next, payment details regarding the transaction from the payer entity are obtained. The payment details include at least the alias associated with the recipient entity's digital wallet and the amount of cryptocurrency to be paid to the recipient. Next, a digital signature associating the payment details with the payer entity's cryptographic key is obtained. An output script associated with the payee endpoint identifier associated with the alias is then generated for providing to the payer entity. The output script is provided to be embedded within a payment transaction for a distributed ledger.

[0040] Advantageously, the third aspect enables receipt of an output script of a digital wallet associated with an alias, thereby automatically enabling construction of a transaction in a format suitable for inclusion in a digital ledger. This is based simply on knowledge of the recipient's alias, and the remaining details are established from machine-readable resources associated with the host responsible for the payment service. Further, enabling the provision of a ready-to-include output script in a transaction along with knowledge of the alias alone provides a seamless, efficient, automatic, easy-to-implement, user-friendly alias based solely on digital wallet payment addressing technology.

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

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

[0043] It should be understood that these instructions exist within machine-readable resources associated with the payment service, but the instructions may also be intended to be executed by one or more computing resources or applications associated with the payment client entity. One or more computing resources that execute these instructions may be associated with a payment client application installed with or associated with a digital wallet associated with the payment client entity.

[0044] Advantageously, the provision of a machine-readable document associated with the payment service enables the generation of a request in a specified format for the payment service to obtain a payee endpoint identifier or URI using a known alias. As a result, this may be used in the construction of a transaction for a distributed ledger.

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

[0046] In a fourth aspect, the present disclosure provides a process or protocol for when a payment client, i.e., a payer entity, desires to make a cryptocurrency payment to another payment client, i.e., a payee entity. The protocol according to this aspect is hereinafter referred to as the simplified payment protocol. The fourth aspect is related to the second aspect of capability discovery since the machine-readable resources of the second aspect are used to implement the simplified payment protocol. In some embodiments, the fourth aspect is related to the third aspect of payee addressing and provides an improved technique for implementing payee addressing, particularly for simplifying the processes for such addressing.

[0047] The fourth aspect relates to a computer-implemented method for implementing a payment service for one or more clients for transactions associated with a distributed ledger such as the Bitcoin blockchain. In a first implementation, the method is executed by one or more processors associated with the payment service. The method includes the step of updating a machine-readable resource associated with the payment service. This machine-readable resource in some embodiments is as described above with respect to the third aspect and is provided or accessible from a predictable or well-known location associated with the payment service.

[0048] In a fourth aspect, the step of updating the machine-readable resource includes the step of adding at least one further capability supported by the payment service, wherein the at least one further capability includes implementing the simplified payment protocol for a given client among one or more clients associated with an alias.

[0049] A fourth aspect provides all of the advantages associated with the above-described second aspect of discovering one or more capabilities or functions associated with a given payment service implemented for one or more clients that may each be associated with a digital wallet in some embodiments. In some embodiments, the digital wallet associated with the payer client and / or payee client is a simplified payment verification (SPV) wallet. Similar to the second aspect, all that is required by the requesting entity, i.e., the payer entity, is the alias associated with the payee's digital wallet. Thus, a user-friendly and simplified addressing mechanism is provided that can be easily dispatched by any entity wishing to participate in a transaction by such a client, providing a record of all support functions or capabilities available or supported by the client associated with the payer entity.

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

[0051] In some embodiments, in addition to the additional or further capabilities described above, there may be an indication for a further capability, or actually the originally generated capability, to specify whether it is true (on, or 1) or false (off, or 0). This toggle function is advantageous because it enables a payment service to perform or not perform one or more of the capabilities specified in a machine-readable resource for a particular type of transaction, or to correspondingly set this performance value for a particular period of time. Thus, any payment entity, such as a payer entity, can check whether a particular capability is actually performed for a type of transaction related to a request, or at the time when the request is generated. For example, if the requesting payment client, i.e., in this case the payer entity, is a client that does not support or cannot respond to messages or instructions regarding such capabilities, the request may be withdrawn or simply not sent.

[0052] In a first implementation of the fourth aspect, at least one new capability related to the implementation of the simple payment protocol is added for the payment service. In some embodiments, the instructions in the machine-readable resource for the payment service are based on the provision of a payment transaction template from a payee entity associated with the payment service to a payer entity. Here, the template includes an output script. In some embodiments, the template may include details of the requested payment (the amount of Bitcoin or digital asset required), a list of outputs (the endpoint URI for making a payment based on the template from a JSON document), a due date, and other metadata required for making the payment.

[0053] The second implementation of the fourth aspect is also executed by one or more processors associated with the payment service and relates to the implementation of the simplified payment protocol capabilities added in the first aspect. Here, a computer-implemented method is provided for implementing a payment service for transactions associated with a distributed ledger. Similar to the foregoing aspects and embodiments, an alias is provided for a client among one or more clients associated with the payment service, the alias is unique to the client, and each client is provided with its respective alias. The method includes receiving, from a payer entity, a payment indicator for a cryptocurrency payment associated with the alias, the indicator relating to a payee client among one or more clients associated with the payment service, and the payee client being associated with the alias within the payment indicator. In some embodiments, the indicator or payment indicator is a form or request or notification by which the payer entity desires to make a digital asset payment to the payee entity. In some embodiments, the indicator may be automatically provided to the payee entity when the payer entity requests or obtains one or more goods or services from the payee entity. The method includes obtaining a payment request template based on a machine-readable resource associated with the payment service of the payee entity, the payment request template including an output script of the payee entity. In some embodiments, at least one capability supported by the payee's payment service includes the simplified payment protocol described above. In some embodiments, the payment request template includes a payee endpoint, or URI, or a 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 includes receiving, from a payer entity, a complete payment transaction based on a payment template, the complete payment transaction being associated with an alias and a network identifier. In some embodiments, the alias may include the network identifier and is included in the template by one or more processors associated with a digital wallet of the payer entity, which may be an SPV wallet. The method then includes providing the complete payment transaction to a distributed ledger such as a blockchain. In some embodiments, the complete payment transaction includes a digital signature and the amount of digital assets or cryptocurrency to be transferred. In some embodiments, the method includes verifying the payer entity, as described in the second aspect above, prior to submission to the blockchain, i.e., checking the public key based on the PKI template above when the payer entity is associated with a payment service.

[0054] The method described above is associated with the same advantages as those described above in relation to adding new capabilities for a simple payment protocol in a first implementation of a fourth aspect. Further advantageously, the simple payment protocol capabilities for a payment service improve the security of the processing of digital asset payments, like cryptocurrency payments from a payer entity, and reduce the amount of online interaction required by the payer entity making the payment.

[0055] To achieve a simple payment protocol for processing cryptocurrency payments, security is enhanced as all details, metadata, and outputs for the payment are required to be added to a payment template that is sent to the payer entity. This improves the security of digital asset payments (since payments are made based on details sent from the bsvalias payment service). Thus, this aspect prevents a Man In The Middle (MITM) attack if the output script is encapsulated within the transaction template and sent directly from the payer entity to the payee entity. As discussed in relation to the second aspect, in some embodiments, the payment service specifies an instruction to obtain a public address that follows a PKI template for verification of the relevant public key, as described in relation to Figure 4.

[0056] Advantageously, the simple payment protocol capabilities according to the first implementation of a further aspect do not require the payer to be online, i.e., constantly connected to a communication network, to generate a digital asset transaction for the payee. Since the output script is provided within 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 endpoints and metadata of the payment transaction for the distributed ledger. Thus, the fourth aspect enables an offline implementation, which is useful for payer clients that are not constantly connected to a communication network or are not computationally very powerful, i.e., digital wallets associated with the payer, since they do not need to interact with the payment service to obtain payment endpoints.

[0057] Furthermore, advantageously, embodiments of the fourth aspect facilitate ensuring the retrieval and monitoring of payments or transactions associated with the recipient entity when the recipient entity is responsible for posting to the blockchain. Accordingly, the recipient entity no longer needs to monitor the blockchain for its own transactions. The payer client can also use the fourth aspect to identify the transactions of a given recipient entity. Accordingly, the fully signed transaction is not posted by the payer entity, but instead is provided to the recipient 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. Accordingly, the Simple Payment Protocol is similar to an invoice-based payment flow model and is more adoptable and interoperable for businesses or organizations that use traditional accounting systems that require purchase orders, etc. to execute digital asset payments.

[0058] In some embodiments, the output script within the payment request template includes a payee for use in constructing a transaction for the cryptocurrency payment from the payer entity to the alias, and the output script is provided by the recipient entity's payment service by accessing a machine-readable resource for the payment service and obtaining a payee endpoint identifier based on one or more instructions and / or specifications within the machine-readable document. In some embodiments, the payee is identified in a manner similar to that described with respect to the third aspect. The method then includes generating an output script associated with the payee endpoint identifier of the recipient entity associated with the alias.

[0059] In some embodiments, the method of the fourth aspect includes receiving a complete payment transaction in the form of an HTTPS POST request from a payer entity, the complete payment transaction including payment details of the payment transaction from the payer entity, the payment details including an alias associated with the payee entity, an amount of cryptocurrency to be sent to the payee entity, and a digital signature for associating the payment details with a cryptographic key associated with the payer entity. In some embodiments, the HTTPS POST request of the fourth aspect is similar to the payee HTTPS POST request flow of FIG. 6, except that in this case, since the output script is not included in the payment request template from the payment service, the payer entity does not need to access a machine-readable document. In some embodiments, the digital signature is verified based on the HTTPS GET request flow understood in connection with FIG. 4, and the public key of the payer entity is resolved if the payer entity is associated with the payment service. The method then includes submitting the complete payment transaction to a distributed ledger.

[0060] In some embodiments, the method of the fourth aspect includes sending an affirmative response to the payer entity for the receipt of the complete payment transaction. Thus, advantageously, this enables the payer entity to track the payment transaction it sent to a payee entity associated with the payment service and check the status of the transaction. In some embodiments, the affirmative response includes a transaction identifier (TxID) for each transaction.

[0061] To implement the fourth aspect, a method performed by a payer entity for a payment transaction to a payee entity includes the following steps, which are complementary to the above-described method of the fourth aspect performed by the payment service of the payee client. The method includes, here, generating a payment indicator for a cryptocurrency payment associated with an alias related to the payee client, and transmitting the payment indicator to the alias based on one or more instructions and / or specifications within a machine-readable resource associated with the payment service of the alias. The method then includes obtaining a payment request template from the payment service associated with the alias, the payment request template including an output script for the payee entity. The method includes generating a complete payment transaction based on the obtained payment request template. This generation includes including the alias and network identifier in the template, applying a digital signature associated with the public key of the payer entity to sign the payment transaction, and providing a payment including the amount of cryptocurrency to be paid to the alias. The complete payment transaction is then transmitted as an HTTP POST request to the payee entity associated with the alias.

[0062] The above-described method has the same advantages as those described above in relation to the method performed by the payment service according to the fourth aspect, except that the method is performed in the payer entity.

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

[0064] A further aspect of the present disclosure relates to a method of constructing a prefix for requesting a payment transaction from a requesting entity to an alias associated with a digital wallet within a network. As a result, in response to receiving a request from the requesting entity including the prefix and the alias, the first and / or second and / or third aspect of the present disclosure may be automatically executed by a payment service based on the alias.

[0065] Advantageously, a fourth aspect enables the automatic triggering of the above-described aspects and embodiments by presenting a simple prefix such as "payto:" or "bsvto:" following the alias of the recipient entity known to the requesting entity. This 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 above-described aspects and embodiments. All that is required of the requesting entity is to append the known alias to the prefix.

[0066] The present disclosure also provides a computing device including a processor and a memory including instructions executable by the processor that, as a result of execution by the processor, cause the computing device to execute any aspect or embodiment of the computer-implemented methods described herein. The present disclosure also provides a system including a plurality of such devices operable together to implement any of the above-described aspects or embodiments.

[0067] The present disclosure also provides a non-transitory computer-readable storage medium storing executable instructions that, as a result of being executed by a processor of a computing device or system, cause the computing device or system to execute at least one aspect or embodiment of the computer-implemented methods described herein.

[0068] Several specific embodiments are described herein by way of example with reference to the accompanying drawings. Like reference numerals indicate like functions herein.

[0069] FIG. 1 relates to a first aspect of the present disclosure and shows a method of implementing a payment service for one or more digital wallets associated with an alias. In FIG. 1, the method is understood to be implemented by one or more processors associated with the provision of the payment service. 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 within a digital wallet network or may be an individual stand-alone cryptocurrency wallet for transactions associated with a distributed ledger. For example, the method may be implemented within a network of Bitcoin wallets for the BSV cryptocurrency. For simplicity of explanation and ease of understanding, the alias associated with the digital wallet within the digital wallet network is hereinafter referred to in the description of the figures. However, as described above, the present disclosure is not often limited to digital wallets connected to other wallets within the network.

[0070] Step 102 is related to assigning or providing an alias to a given digital wallet within the digital wallet network. This is related to providing a mapping or correlation of the alias with each respective public address associated with the digital wallet. As a result, the alias can be used instead of the public address. Such an assignment may be made, for example, when a particular payment client or entity signs onto the network. In this regard, a pair of "alias:public address" may be provided for each wallet. The alias is unique to a particular wallet and includes either a network identifier such as a domain name of the network, or a name identifying the network. For example, the alias may be in a well-known email format such as clientname@domainname.com. Here, clientname may be simply the name or identifier of an individual or company that signs onto or is registered with the digital wallet network, such as Alice or Bob. Domainname indicates an organization or domain owner, for example, "nChain". In this case, Alice's alias is alice@nchain.com. If Bob signs onto a different network with a digital wallet having a domain name "notnchain" that implements one or more aspects and / or embodiments of the present disclosure, Bob's alias may be assigned as bob@notnchain.com. Other alias formats such as AliceNC or BobBSV etc. may also be used as long as the alias is associated with a network identifier.

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

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

[0073] Step 106 relates to updating the service record generated in step 104 or including in it an entry or field indicating a payment service provided by a network or domain associated with the network identifier. The step of updating the service record in the DNS indicates that a specific network identifier, such as nchain.com, provides or uses a service identified as a specific payment service, such as "bsvpay" or "bsvalias". This step of updating indicates to the entity performing the DNS lookup that the identified payment service can execute payment transactions for an alias associated with the nChain domain, taking into account, for example, "bsvalias".

[0074] Step 108 relates to the step of updating the service record to indicate the location of the host computing resources responsible for the payment service indicated in step 106. Thus, if the payment service is associated with a different network or domain to the digital wallet network, this entry in the service record will point to the web server location or IP address of the host computer or server providing the service. Continuing from the above example, if the bsvalias payment service is associated with a separate network or separate domain (bsvalias.com), the location or instruction identifying the host server of bsvalias.com is indicated in the service record. This is to identify where the host computing resources configured to realize the identification of the digital wallet associated with the alias can be found.

[0075] An example of a service record (srv record) in the DNS defining the location of a server for a specified service is shown below.

[0076] The service record for the domain name (nchain) associated with the payment service (bsvalias) may have fields or entries such as the following, in the following format: · service: Symbolic name of the desired service. · proto: Transport protocol of the desired service, which is usually TCP (transmission control protocol) or UDP (User datagram protocol). · name: Domain name for which this record is valid, ending with a dot. · TTL: Standard DNS survival time field, which sets the expiration period or deadline associated with the record. · class: Standard DNS class field. · priority: Priority of the target host. · weight: Relative weight for records having the same priority. · port: TCP or UDP port on which the service should be discovered. · target: Standard host name of the machine providing the service.

[0077] For example, the domain owner of nchain may generate an SRV (service) record having the following parameters.

Table 1

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

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

[0080] In step 206a, when the service record, and thus the payment service, i.e., bsvalias, is identified, the location of the host computing resources for the payment service is obtained. In some embodiments, this is returned to the requesting entity. In the example above, this location of the host corresponds to the target:port pair in the srv record of nchain. The target:port pair provides the location where the host responsible for the service bsvalias is used or operates.

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

[0082] FIG. 2B, as described above, pertains to steps corresponding to FIG. 2A and is implemented in a computing device or digital wallet of the payer or requesting entity.

[0083] Accordingly, step 202b is related to sending a request for a transaction from the requesting entity, where the request is associated with an alias.

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

[0085] In step 208b, the public address of the digital wallet associated with the alias is obtained. As a result, this may be used for transactions associated with the digital ledger.

[0086] FIGS. 3A and 3B are flow diagrams showing a method according to a second aspect of the present disclosure for identifying a public address associated with an alias within a request for a transaction. FIG. 3A shows a method implemented by one or more processors associated with a payment service. FIG. 3B shows a method implemented by one or more processors associated with a payment client entity.

[0087] In step 302a of FIG. 3A, a machine-readable resource is generated for the payment service. The machine-readable resource is provided to ensure that the functions or capabilities provided or supported by the payment service, and / or any instructions for utilizing these capabilities, can be identified. Thus, this process is referred to as capability discovery related to the payment service. Accordingly, a machine-readable document is generated for the capability discovery process. Thereby, a payment client entity or digital wallet or application desiring to use or request the service can learn or discover the functions supported by the payment service, and any respective endpoints and configurations related to the use of the payment service. In some embodiments, the machine-readable resource is a pre-generated file or document associated with and stored for the payment service, i.e., a static document. In some embodiments, for example, in an enterprise-class service implementation, the machine-readable resource may be dynamic and can be generated on demand, rather than as a static file stored on a web server. Advantageously, a resource generated dynamically in this way provides simplification in service deployment, migration, maintenance, and any upgrades required to be performed.

[0088] In some embodiments, JSON (JavaScript Object Notation), a lightweight data interchange format, is used to generate machine-readable resources. JSON is a text format that is completely language-independent and uses conventions familiar to programmers accustomed to C-family languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data interchange language. Additionally, JSON is built on two structures: a collection of name / value pairs and an ordered list of values. In many languages, this is realized by arrays, vectors, lists, or sequences. Since these are general-purpose data structures, virtually all modern programming languages support them respectively. Therefore, it is desirable to use JSON for machine-readable resources because JSON provides a data format that is interchangeable with other programming languages based on these same structures.

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

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

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

[0092] For example, the machine-readable resource may indicate the following file or entry for the payment service “bsvalias”:

Number

[0093] The template values {name} and {domain.tld} are in alias format <name> @ <domain> . <tld>Represents the components. Here, tld is the 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 alice@nchain.com.

[0094] Regarding step 304a, it relates to the step of storing a machine-readable resource at a predictable or known location associated with the payment service. For example, for the payment service operator or processor for the payment service "bsvalias", following the generation of the text document in JSON format described above in step 302a, the document may be provided at the following locations: https: / / <host-discovery-target> : <host-discovery-port> / .well-known / bsvalias

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

[0096] In step 306a, a request for a transaction from a payment client entity is received, and the request includes an alias to which the payment is to be directed. Continuing from the above example, this includes requests such as payto:alice@nchain.com.

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

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

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

[0100] Assuming at step 314a that the machine-readable resource has at least one supported capability for the transaction (if this is specified by the requesting entity), once this is identified, an endpoint identifier associated with the host computing resource of the payment service is returned from the machine-readable resource. In the example above, this may be the location of the host responsible for bsvalias. Next, using one or more of the instructions and / or specifications within the machine-readable resource for the payment service "bsvalias", the public address for the digital wallet associated with the alias can be obtained.

[0101] Figure 3B, as described above, relates to the steps corresponding to Figure 3A but is implemented in the computing device or digital wallet of the payer or the requesting entity.

[0102] Accordingly, step 306b is related to sending a request for a transaction from the requesting entity, where the request is associated with an alias, i.e., continuing with the example above, related to sending payto:alice@nchain.com.

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

[0104] Step 312a determines whether one or more capabilities of the requested transaction exist within the machine-readable resource. This step includes checking a JSON document, similar to step 312a of FIG. 3A, to identify whether one or more entries related to common or specified supported capabilities are appropriate or necessary for the requested transaction.

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

[0106] In step 314b, the requesting client then obtains the public address associated with the alias. This can be obtained by the requesting client that executes functions according to one or more of the instructions and / or specifications within the machine-readable resource.

[0107] FIG. 4 shows an exemplary sequence of instructions specified within a machine-readable resource implementing a second aspect of PKI (public key infrastructure) technology for obtaining an encryption key associated with an alias.

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

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

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

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

Number

[0112] The ECDSA public key is a valid point on the secp256k1 curve, compressed, and hex-encoded. This means that the "pubkey" string is 66 bytes long (33 bytes of binary, each byte encoded as two hexadecimal characters).

Table 2

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

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

[0115] Step 502a of Figure 5A relates to accessing a machine-readable resource of the payment service following the step of identifying the payment service within the alias. The identity of the payment service can be obtained as described above in connection with Figures 1, 3A, and / or 3B, along with the location of the machine-readable resource.

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

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

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

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

[0120] In step 512a, following the output of successful verification in step 510a, an output script based on the payee endpoint identifier associated with the alias is generated. This output script is provided to be embedded in the payment transaction for the distributed ledger to automatically resolve the payee in the transaction for the distributed ledger.

[0121] For example, the output script returned for the construction of a transaction before the distributed ledger, i.e., the Bitcoin blockchain, may follow the following formula:

Number

[0122] The value of the output field may be a hexadecimal-encoded Bitcoin script, which is used by the payer entity during the construction of the payment transaction.

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

[0124] Given a key pair with a public key of the following formula:

Number

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

Number

[0126] This can be decomposed as follows:

Number

[0127] The service response body, that is, the script for embedding in the transaction in step 512a, is thus as follows:

Number

[0128] FIG. 5B, as described above, is related to the steps corresponding to FIG. 5A and is implemented in the computing device or digital wallet of the payer or requester entity.

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

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

[0131] Step 506b is related to the step of transmitting or providing details of the payment regarding the transaction. The details of the payment include an alias associated with the recipient entity's digital wallet and the amount of cryptocurrency to be paid to the recipient.

[0132] Steps 508b and 510b are related to the step in which the payer entity provides a digital signature to associate the details of the payment with a cryptographic key, followed by verification as discussed in the corresponding steps of FIG. 5A.

[0133] Step 512b is related to the step in which the payer entity receives an output script based on the payee endpoint identifier associated with the alias. This was explained in relation to FIG. 5A above.

[0134] Step 514b is related to the step in which the payer entity constructs a payment transaction for the distributed ledger by embedding the received output script into the transaction.

[0135] FIG. 6 shows an exemplary sequence of instructions specified within a machine-readable resource that implements a payee endpoint resolution sequence associated with an alias for a digital wallet.

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

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

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

[0139] In step 608, an output script based on the payee endpoint identifier associated with the alias is returned. This is also used in the construction of payment transactions for the distributed ledger, as discussed in FIGS. 5A and 5B.

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

Number

[0141] The fields of the schema described above are briefly explained in the following table, and further explanations of some fields will be provided later.

Table 3

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

[0143] In some embodiments, the timestamp field indicated by "dt" in the above table, and the payerHandle may be required in the schema for the request. In other embodiments, the timestamp, payerHandle, and signature field may be required to operate according to one or more capabilities that may exist within a machine-readable resource associated with a particular request or with the recipient client.

[0144] The remaining fields may be optional as long as the function or operation of the request is relevant. However, in many situations, usually an amount is indicated (which may be zero). However, an optional field or a non-zero value of an optional field may be present in the request if it is known or if the information is available to the payment entity, in this case the payer entity. The timestamp and signature fields may be considered essential for the particular payment service capabilities specified within the machine-readable resource and are described below.

[0145] The timestamp field "dt" may include the current time in the accepted standard ISO-8601 format when the payer starts a payee request. From JavaScript, this can be constructed using commands or instructions related to machine-readable resources such as JSON.stringify(). For example, this may return: [Number]

[0146] 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. This functionality is, in many cases, basically a standard ECDSA implementation, but has an additional piece of information provided to allow the client to verify the message signature against a P2PKH address (the hash of the public key) rather than directly against the public key, having a (r, s) signature pair for integers r and s.

[0147] In some embodiments, the signature may be the raw (r, s) field calculated for the double-SHA256 hash of the message which is the requirement as described above in this case. Existing signature and verification protocols may be suitable for some embodiments, for example, to utilize existing Bitcoin client libraries such as the BSV library of MoneyButton, or other similar cryptocurrency libraries.

[0148] In some embodiments, the implementation of the MoneyButton BSV library is designated as the standard message digest composition and signature encoding method for the signatures included in the payee requests. The message or request to be signed may start with the traditional or known preamble of the Bitcoin signature scheme (as may be documented in the source code of the BSV library), followed by the concatenation of the UTF8 strings of the fields payerHandle and dt, and optionally, the amount and purpose fields discussed in the exemplary schema above.

[0149] Regarding the specification of the amount within the request, based on the schema above, in some embodiments, the following rules may apply.

[0150] If the amount exists, it is converted to a string (without leading zeros).

[0151] If the amount does not exist, the string "0" is used.

[0152] If the purpose does not exist, an empty string "" is used (effectively, the purpose is not included in the message).

[0153] Figures 7A and 7B are flow diagrams showing a method of implementing a simple payment protocol for cryptocurrency payments to a payee client associated with a payment service such as the bsvalias payment service described above in connection with the second and third aspects according to a fourth aspect of the present disclosure. Figure 7A shows a method implemented by one or more processors associated with a payment service for a payee entity. Figure 7B shows a method implemented by one or more processors associated with a payment client entity, which may be associated with the same or a different payment service as the payment service for the payee entity, in this case the payer entity.

[0154] In some embodiments, the simplified payment protocol of the fourth aspect is based on the payee associated with the alias discussed in connection with FIGS. 5A and 5B. In some embodiments, the payee is associated with an address that should be encoded or included within the output script, such that the transaction may be configured for a distributed ledger, i.e., a blockchain, based on this address. In some embodiments, the payee is an endpoint identifier. In other embodiments, the payee endpoint identifier may be different from the public address associated with the alias, or may be a portion of or associated with the public address for a digital wallet associated with the alias. In some embodiments, the public address associated with the alias and / or the payee endpoint identifier may be assigned statically or dynamically. Embodiments of the fourth aspect described in connection with FIGS. 7A and 7B may be implemented by a digital wallet that is an SPV for the payee entity and / or the payer entity. However, this is not essential if a payment service such as bsvalias can be implemented for any type of computing device or wallet implementation as described in the above aspects.

[0155] In a non-limiting description of a fourth aspect for a payment transaction between two payment entities, continuing with the above example, assume that Alice (the payer) wishes to pay Bob (the payee), and both parties use the same type of SPV wallet. An SPV wallet is known to store a user's private and public keys, unspent transactions, and block headers. Such a wallet also has the ability to connect to a blockchain. The term "block header" is conventionally known and is used to represent data provided at the top of a block of blockchain transactions. Since the block header uniquely identifies the block, it can be placed on the blockchain. It has a field of data that provides a unique summary or fingerprint of the contents of the entire block. The block header includes a Merkle Root, which is the hash of all the transactions within the block. A user can then search a Merkle tree having that root to check (i.e., verify) whether a particular transaction is included in a particular block on the blockchain, without having to download the entire blockchain. The advantage of an SPV wallet is that devices with limited power and memory, such as phones and laptops, do not have to perform a full check of the blockchain for every other form of digital wallet, but only have to check that a transaction has been verified (and thus is called "Simplified Payment Verification"), enabling such devices to operate within a blockchain network. An improved security solution for verification on a blockchain network using a low bandwidth SPV system is described in detail in the following UK patent applications by nChain Holdings Limited filed on 5 February 2019: GB1902086.6, GB1902088.2, GB1902090.8, GB1902089.0, and GBGB1902092.4. The SPV wallet implementations in these applications may be used to implement the fourth aspect of the present disclosure, but the present disclosure is not limited to such SPV wallets.

[0156] Embodiments of the fourth aspect are discussed below with respect to FIG. 7A. Here, the method is implemented by one or more processors associated with a payment client, in this case a payment service for the payee entity.

[0157] Step 702a shows the step of receiving, from the payer entity, a payment indicator for a cryptocurrency payment associated with the alias of the payee client. Thus, continuing with the example of the foregoing embodiment, this step includes obtaining a request from Alice to pay Bob. Here, Alice indicates that a cryptocurrency payment, namely 3BSV, is to be made to the alias that Alice recognizes for Bob, namely bob@nchain.com. In this case, the alias includes the name "bob" and the network identifier "nchain". However, as mentioned in the foregoing aspect, the name within the alias may be or indicate a network identifier. The network identifier may be a tld, i.e., a top-level domain name. This may be in the form of a message of a notification sent or generated by the payer client based on or by the use of the goods or services provided by Bob or the intention to purchase such use. In this case, Bob is considered a merchant and Alice is considered a customer.

[0158] In step 704a, upon receiving the payment indicator, the payment service, which is bsvalias in the above example, accesses a machine-readable resource, namely a JSON document, to identify the capabilities available to Bob, namely the payee client, with respect to such a payment. Assuming that bsvalias supports the above-described simple payment protocol capabilities for the alias bob@nhain.com, such capabilities may be specified as follows within the JSON document of bsvalias:

Number

[0159] The template values {name} and {domain.tld} are the recipient's alias, that is <name> @ <domain> . <tld>represents a component. This should be substituted by the user or another payment client before issuing a request related to this capability. 3b585cdaa4cd may be an entry identifier representing the simple payment capability within a machine-readable document in this example.

[0160] In step 706a, when the simple payment protocol capability is expressed for the alias bob@nchain.com, the payment service for the recipient client generates an output script for the payment to be made to Bob based on the payment indicator received from Alice in step 702a. This output script should be included in the payment request template. This can be directly sent to the payment client, which is Alice in this example.

[0161] In this step, the capability identified as 3b585cdaa4cd in step 704a returns a path from the well-known / bsvalias document, i.e., the machine-readable resource of bsvalias, in the form of a URI template that is now referenced as the payment request template. The output script is associated with the payment destination endpoint for the payment and may also indicate other metadata such as the end time / date of the output script. The payment request template generated based on the output script may include the following example.

Number

[0162] In the above example, the use of the "transactions" array indicates a transaction template or a pseudo-transaction. In some embodiments, this enables the submission of a batch, i.e., the addition to the blockchain, without having multiple HTTP requests.

[0163] The txid, scriptSig, and scriptPubKey fields all represent unprocessed Bitcoin binary encoded in hexadecimal in this example. The exemplary value field is an integer representing satoshis. However, it is understood that the present disclosure and its related embodiments are not limited to Bitcoin or BSV or satoshis.

[0164] In step 708a, the payment request template is sent directly by the payment service to the payer entity along with the output script generated in step 706a. In some embodiments, when 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.

[0165] In step 710a, a complete payment transaction based on the template of step 706a is received from the payee entity. This is received as an HTTPS POST request and is similar to the request flow described for the payee addressing in FIG. 6. Here, the alias, i.e., the name and network identifier, is added to the template along with the details of the cryptocurrency payment to be made. The received complete payment transaction is in a format ready to be submitted to the blockchain since the output script is already included in the template. The received complete payment transaction is signed by the payer entity. This is, in this step, a digital signature associated with the public key of the payer entity and may be verified, for example, using the HTTPS GET request related to the PKI template described in FIG. 4.

[0166] In step 712a, the complete transaction from step 710a is submitted by the payee entity to the distributed ledger.

[0167] The methods and embodiments of the fourth aspect advantageously make it much easier for a wallet, processor, and / or computing device associated with a recipient entity to track incoming transactions, without scanning all transactions and all blocks in the blockchain or relying on a Bloom filter to do the same. Thus, for a node, i.e., the recipient entity, in this example Bob, as the number of incoming payments and transactions increases, this embodiment ensures that all and any amount of such transactions can be easily tracked, thereby ensuring the reliability and scalability of the blockchain-based payment service.

[0168] Aspects of the present invention also increase the security of payment transactions made to a recipient client, and the digital signature of the payer must be verified before being submitted to the blockchain. This is an additional security measure. The payment service for the recipient client may choose to reject unsigned transactions that are not paid against the key associated with the alias in the payment request template. When rejecting a request, the payment service may choose any HTTP status code such as 401 (Unauthorized), 204 (No Content), or 404 (Not Found).

[0169] FIG. 7B corresponds to the steps of FIG. 7A, but is implemented in the computing device or digital wallet of the payer or requesting entity.

[0170] Step 702b relates to generating a payment indicator for a cryptocurrency payment associated with an alias related to the recipient client, where the recipient client is associated with the payment service. Continuing with the description in Step 702a, in the illustrated non-limiting embodiment, the recipient's alias is bob@nchain.com and the payment service is bsvalias. As described above, the indicator may be automatically generated or may be a message or notification sent by the payer entity, i.e., Alice, that a payment in BSV should be made to Bob. In some embodiments, since the payer Alice only recognizes Bob's alias, i.e., bob@nchain.com, the payment indicator may be sent using an HTTPS GET request as described in relation to FIG. 4, but this is not essential.

[0171] In Step 704b, the payment request template is received from the payment service associated with the recipient client. As described above in Step 704a, the payment request template includes all the details of the blockchain transaction and the output script for making a payment to the recipient entity.

[0172] In Step 706b, one or more processors associated with the payer entity or its wallet include, based on the obtained payment request template, a network identifier associated with the alias in the template, i.e., by receiving the template values {name} and {domain.tld} within the URI received from the recipient's alias, i.e., the recipient entity <name> @ <domain> . <tld>By replacing it to represent, a complete payment transaction is generated. Further, the details of the payment including the amount of cryptocurrency are added to complete the transaction template from the recipient entity.

[0173] In step 708b, to sign the complete payment transaction, a digital signature associated with the public key of the payer entity is applied. As described above with respect to step 710a, this is to enable the identity of the payer identity to be verified.

[0174] In step 710b, the complete signed payment transaction is sent to the recipient entity associated with the alias based on the output script in the template received in step 704b. This is provided as an HTTPS POST request after substituting the recipient's alias as shown in step 710a. In some embodiments, when the complete payment transaction is sent, an affirmative response for the cryptocurrency payment from the payment service associated with the recipient entity may be received by the payer entity. This may be used to track or monitor the payment associated with the payer entity, i.e., Alice.

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

[0176] The processor 2602 can 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.

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

[0178] The network interface subsystem 2616 may provide an interface to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and transmitting data to other systems of the computing device 2600. For example, the network interface subsystem 2616 enables a data technician to connect the device to a network. As a result, the data technician can transmit data to and receive data from the device even if located at a remote location such as a data center.

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

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

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

[0182] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described hereinafter. Further, the computing device 2600 may include another device connectable to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). The device connectable to the computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Accordingly, this device may be configured to convert an optical signal into an electrical signal transmitted to the computing device 2600 through a port connecting the devices for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 2600 shown in FIG. 8 is intended only as a specific example for the purpose of explaining a preferred embodiment of the device. Many other configurations with more or fewer components than the system shown in FIG. 8 are possible.

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

[0184] The processor 2602 can 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.

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

[0186] The network interface subsystem 2616 may provide an interface to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and transmitting data to other systems of the computing device 2600. For example, the network interface subsystem 2616 enables a data technician to connect the device to a network. As a result, the data technician can transmit data to and receive data from the device even if located at a remote location such as a data center.

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

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

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

[0190] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described hereinafter. Further, the computing device 2600 may include another device connectable to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). The device connectable to the computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Accordingly, this device may be configured to convert an optical signal into an electrical signal transmitted to the computing device 2600 through a port connecting the device for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 2600 shown in FIG. 8 is only intended as a specific example for the purpose of explaining a preferred embodiment of the device. Many other configurations having more or fewer components than the system shown in FIG. 8 are possible. <Exemplary embodiments recited> (Item 1) A computer-implemented method for performing a payment service for one or more clients for transactions associated with a distributed ledger, the method comprising: providing an alias for a given client among the one or more clients, the alias being unique to the given client and the alias including or related to a network identifier; associating the alias with the network identifier in a directory; comprising, wherein the associating step comprises: generating a service record based on the network identifier in the directory; updating the service record to indicate that the payment service is provided by a network or domain associated with the network identifier; Updating the service record to indicate the location of the host computing resources responsible for the payment service, wherein the host computing resources are configured to realize the identification of the digital wallet associated with the alias in response to a request related to a transaction associated with the alias, step; A method including. (Item 2) The method according to item 1, wherein each of the one or more clients is associated with a digital wallet. (Item 3) Executing a search of the directory based on the alias in response to a request from a request-side entity related to a transaction associated with the alias; Identifying the service record of the payment service in the directory related to the network identifier; Returning the location of the host computing resources for the payment service, wherein the public address of the client associated with the alias is determined based on the returned location, and the public address is used in the transaction, step; The method according to item 1 or 2 including. (Item 4) A method related to a transaction for a distributed ledger, wherein an alias is provided for a given client among one or more clients, the alias is unique to the given client, the alias includes or is related to a network identifier, and the method includes: Sending a request related to a transaction from a request-side entity, the request being associated with the alias, step; Obtaining the location of the host computing resources associated with the payment service, the location being based on a service record related to the network identifier identified in a directory search, step; Including, A method in which a public address of the client associated with the alias is determined based on the location, and the public address is used in the transaction. (Item 5) For each client among the one or more clients, the method according to Item 4, wherein the client is associated with a digital wallet. (Item 6) The step of returning or obtaining the location of the host computing resource includes the step of returning or obtaining a target and port pair, the target includes an identifier of the host computing resource, and the port includes an identifier of an Internet protocol communication port used by the payment service. The method according to any one of Items 3 to 5. (Item 7) The host computing resource is associated with a payment network different from the network associated with the network identifier of the alias, and the payment service of one or more entities registered in the network is delegated to a payment domain associated with the payment network. The method according to any one of Items 1 to 6. (Item 8) The host computing resource is associated with a payment network, and the domain of the payment network is the same as the domain of the network associated with the network identifier of the alias. The method according to any one of Items 1 to 7. (Item 9) A method implemented by a computer for implementing a payment service for one or more clients for a transaction associated with a distributed ledger, the method comprising: generating a machine-readable resource associated with the payment service, the machine-readable resource comprising: at least one endpoint identifier associated with a host computing resource responsible for implementing the payment service for each client, each client being associated with an alias, the alias including or related to a network identifier, and at least one endpoint identifier; An entry associated with at least one of a plurality of capabilities supported by the payment service, Instructions and / or specifications for accessing or obtaining the public address associated with the alias, wherein the public address is used to effect a transaction associated with the alias, instructions and / or specifications, Including steps, Providing the machine-readable resource at a predictable or known location associated with the payment service, A method including. (Clause 10) The method according to clause 9, wherein each of the one or more clients is associated with a digital wallet. (Clause 11) The plurality of capabilities are as follows: Payer entity or payee entity verification, Multiple digital signatures for transactions, Payee entity authorization for transactions, Payment transactions related to the email protocol, Simple payment protocol or flow for payment transactions, and / or, Callback requests or responses, The method according to clause 9 or 10, including one or more of. (Clause 12) Further including the step of determining the location of the host computing resources by the method according to any of clauses 1 to 3, 6 to 8, wherein the endpoint identifier in the machine-readable resource is based on the determined location, the method according to any of clauses 9 to 11. (Clause 13) In response to receiving a request from a requesting entity related to a transaction associated with an alias, the method Identifying the payment service associated with the alias based on the network identifier associated with the alias in the request, Based on the identified payment service, accessing the machine-readable resource from the predictable or known location; In response to identifying whether one or more capabilities required for the transaction exist within the machine-readable resource, returning an endpoint identifier of the host computing resource for the payment service from the machine-readable resource; Based on one or more of the instructions and / or specifications within the machine-readable resource, obtaining a public address associated with the alias; The method according to any one of items 9 to 12, including. (Item 14) A method associated with a transaction for a distributed ledger, wherein an alias is provided for a given client among one or more clients, the alias is unique to the given client, the alias includes or is related to a network identifier, and the method includes: Sending a request related to a transaction from a requesting entity, the request being associated with the alias; Accessing the machine-readable resource from a location associated with the payment service, the payment service being identified based on the network identifier within the alias, and the machine-readable resource being generated according to item 9; Receiving an endpoint identifier of the host computing resource for the payment service associated with the alias based on identifying whether one or more capabilities required for the transaction exist within the machine-readable resource; Using one or more of the instructions and / or specifications within the machine-readable resource to obtain a public address associated with the alias; A method including. (Item 15) Each client associated with the digital wallet is associated with a registered user or entity for the payment service within the network, and each digital wallet is a cryptocurrency wallet associated with a public key and a private key of an asymmetric cryptographic key pair for transactions on the distributed ledger. The step of obtaining the public address includes the step of obtaining the public key of the digital wallet associated with the alias, according to the method described in Item 13 or 14. (Item 16) The public address associated with the alias is based on the cryptographic hash of the public key of the digital wallet associated with the alias, according to the method described in Item 15. (Item 17) The public key of the digital wallet is an elliptic curve digital signature algorithm (ECDSA) public key, and the public key is not part of any transaction previously stored or entered in the distributed ledger, according to the method described in Item 15 or 16. (Item 18) The one or more instructions and / or specifications in the machine-readable resource obtain a PKI request template from the machine-readable resource for a PKI (public key infrastructure) endpoint identifier; include the alias and the network identifier in the template to generate a complete PKI request; send an HTTP GET request based on the complete PKI request to obtain the public key associated with the alias; and include, according to the method described in any one of Items 13 to 17. (Item 19) The known or predictable location of the machine-readable resource is based on at least one of the endpoint identifier, the Internet protocol communication port used by the payment service, and / or the configuration specifications of the payment service included in a well-known publicly accessible domain repository, according to the method described in any one of Items 9 to 18. (Item 20) The machine-readable resource is generated using the JSON (JavaScript Object Notation) format, and is the method according to any one of Items 9 to 19. (Item 21) The step of obtaining the public address associated with the alias is a step of obtaining the payment destination of the recipient entity associated with the alias, where the payment destination is used when constructing a transaction for making a cryptocurrency payment from the payer entity to the alias, and includes the step. The method is a step of accessing the machine-readable resource for the payment service; a step of returning a payment destination endpoint identifier based on one or more instructions and / or specifications within the machine-readable document; a step of obtaining details of the payment of the transaction from the payer entity, where the details of the payment include the alias associated with the recipient entity client and the amount of cryptocurrency to be paid to the recipient; a step of obtaining a digital signature associating the details of the payment with the cryptographic key associated with the payer entity; a step of generating an output script associated with the payment destination endpoint identifier associated with the alias, where the output script is provided for embedding in a transaction for the distributed ledger; and is the method according to any one of Items 13, 15 to 20. (Item 22) The step of obtaining the public address associated with the alias is a step of obtaining the payment destination of the recipient entity associated with the alias, where the payment destination is used when constructing a transaction for making a cryptocurrency payment from the payer entity to the alias, and includes the step. The step of constructing the transaction is sending, from the payer entity, a request regarding the transaction, the request being associated with the alias; accessing the machine-readable resource from a location associated with the payment service; receiving a payee endpoint identifier based on the one or more instructions and / or specifications within the machine-readable resource; providing payment details for the transaction, the payment details including the alias associated with the payee entity client and the amount of cryptocurrency to be paid to the payee entity; providing a digital signature associating the payment details with a cryptographic key; receiving an output script associated with the payee endpoint identifier associated with the alias; generating the transaction by embedding the received output script into a transaction for the distributed ledger; The method according to any one of clauses 14 to 20, comprising. (Clause 23) The one or more instructions and / or specifications in the machine-readable resource are obtaining a payee request template from the machine-readable resource for a payee endpoint identifier; generating a complete payee request by including the alias and the network identifier in the template; sending an HTTP POST request based on the complete payee request to obtain a payee endpoint identifier associated with the alias; The method according to clause 21 or 22, comprising. (Item 24) The alias and the public address of the payer entity each include the public key of the respective digital wallet associated with the payee entity and the payer entity, and the digital signature is used to verify the identity of the payer entity. The method according to any one of Items 21 to 23. (Item 25) The digital signatures associated with both the payer entity and the payee entity are required for verification of each entity before the generated transaction is stored or entered into the distributed ledger. The method according to any one of Items 21 to 24. (Item 26) A method implemented by a computer for providing a payment service for one or more clients for a transaction associated with a distributed ledger, the method comprising: updating a machine-readable resource associated with the payment service, the machine-readable resource being provided or accessible from a predictable or known location associated with the payment service, the machine-readable resource being generated according to Item 9; wherein the updating step comprises adding at least one additional capability supported by the payment service, the at least one additional capability comprising implementing a simple protocol for processing digital assets of a given client among the one or more clients. (Item 27) A method implemented by a computer for providing a payment service for a transaction associated with a distributed ledger, wherein an alias is provided to a client among one or more clients associated with the payment service, the alias being unique to the client, and each client is provided with its respective alias. The method comprises: Receiving, from a payer entity, a payment indicator for a cryptocurrency payment associated with an alias, wherein the indicator is associated with a payee entity among the one or more clients associated with the payment service, and the payee entity is associated with the alias in the payment indicator; Providing, in accordance with item 9, a payment request template based on a machine-readable resource, wherein the machine-readable resource is associated with the payment service, and the payment request template includes an output script for the payee entity; Receiving, from the payer entity, a complete payment transaction based on the payment template, wherein the complete payment transaction is associated with the alias and the network identifier; Providing the complete payment transaction to the distributed ledger; A method comprising the above steps. (Item 28) The payment service of the payee client is implemented by the method described in item 26, and at least one capability supported by the payment service of the payee client is based on at least one further capability in the updated machine-readable resource of item 26. The method described in item 27. (Item 29) The output script in the payment request template includes a payee for use in constructing a transaction for a cryptocurrency payment from the payer entity to the alias. The output script is as follows: Accessing the machine-readable resource for the payment service; Obtaining a payee endpoint identifier based on the one or more instructions and / or specifications in the machine-readable document; Generating the output script associated with the payee endpoint identifier for the payee entity associated with the alias; The method described in item 27 or 28 provided by the above steps. (Item 30) Receiving the complete payment transaction in the form of an HTTPS POST request from the payer entity, wherein the complete payment transaction comprises: Payment details of the payment transaction from the payer entity, the payment details including the alias associated with the payee entity and the amount of cryptocurrency to be sent to the payee entity, and A digital signature associating the payment details with a cryptographic key associated with the payer entity; and Submitting the complete payment transaction to the distributed ledger; and The method according to any one of Items 27 or 29. (Item 31) The method according to Item 30, further comprising sending an affirmative response to the payer entity for receiving the complete payment transaction. (Item 32) A computer-implemented method associated with a transaction for a distributed ledger, wherein an alias is provided to a client among one or more clients associated with a payment service, the alias being unique to the client, each client being associated with its respective alias, and the method comprises: Generating a payment indicator for a cryptocurrency payment associated with an alias associated with a payee entity among the one or more clients associated with the payment service; and Sending the payment indicator to the alias based on one or more instructions and / or specifications within the machine-readable resource according to Item 9, the machine-readable resource being associated with the payment service of the alias; and Obtaining a payment request template from the payment service associated with the alias, the payment request template including an output script for the payee entity; and Based on the obtained payment request template, the following: To sign the payment transaction, apply a digital signature associated with the public key of the payer entity, Provide a payment that includes the amount of cryptocurrency to be paid to the alias, Thereby generating a complete payment transaction; and Sending the complete payment transaction to the payee entity associated with the alias. A method including the above. (Clause 33) The method according to clause 1, further comprising receiving an affirmative response to the cryptocurrency payment from the payment service associated with the payee entity. (Clause 34) The method according to any one of clauses 1 to 25, wherein the alias is a payment handle associated with the client. (Clause 35) A method of constructing a prefix for generating a request related 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 including the prefix and the alias, triggering the steps according to any one of clauses 1 to 34 based on the alias. (Clause 36) A computing device or computer system, comprising: A processor; A memory including executable instructions that, as a result of execution by the processor, cause the system to execute the computer-implemented method according to any one of clauses 1 to 35; and A computing device or computer system including the above. (Clause 37) A non-transitory computer-readable storage medium storing executable instructions that, as a result of execution by a processor of a computer system, cause the computer system to execute the computer-implemented method according to any one of clauses 1 to 35.

[0191] The above embodiments are not intended to limit the present disclosure. It should be noted that the present disclosure can be described and those skilled in the art can devise many alternative embodiments without departing from the scope of the present disclosure defined by the appended claims. In the claims, any reference signs in parentheses should not be construed as limiting the claims. Terms such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprising" means "comprising or consisting of", and "comprises" means "comprises or consists of". A reference to a single element does not exclude a reference to a plurality of such elements. Vice versa. The present disclosure can be implemented by means of hardware including several distinct elements and by a computer appropriately programmed. In apparatus claims listing several means, some of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used advantageously.< / tld> < / domain> < / name> < / tld> < / domain> < / name> < / tld> < / domain> < / name> < / tld> < / domain> < / name> < / host-discovery-target> < / tld> < / domain> < / name>

Claims

1. A computer-implemented method for performing a payment service for one or more clients for a transaction associated with a decentralized ledger, the method comprising: providing an alias for a given client among the one or more clients, the alias being unique to the given client and the alias including or being related to a network identifier; associating the alias with the network identifier in a directory; including: wherein the associating step includes: generating a service record based on the network identifier in the directory; updating the service record to indicate that the payment service is provided by a network or domain associated with the network identifier; updating the service record to indicate the location of a host computing resource responsible for the payment service, the host computing resource being configured to implement identification of a digital wallet associated with the alias in response to a request regarding a transaction associated with the alias; a method.

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

3. executing a search of the directory based on the alias in response to a request from a requesting entity related to a transaction associated with the alias; identifying the service record of the payment service in the directory related to the network identifier; returning the location of the host computing resource for the payment service, wherein a public address of the client associated with the alias is determined based on the returned location and the public address is used in the transaction; The method according to claim 1 or 2, including:

4. A method related to transactions for a decentralized ledger, wherein an alias is provided for a given client among one or more clients, the alias being unique to the given client, the alias including or related to a network identifier, the method comprising: sending, from a requesting entity, a request related to a transaction, the request being associated with the alias; obtaining a location of host computing resources associated with a payment service, the location being based on a service record related to the network identifier identified in a directory search; comprising: a public address of the client associated with the alias being determined based on the location, the public address being used in the transaction. **Claim 5** The method according to claim 4, wherein each of the one or more clients is associated with a digital wallet. **Claim 6** The step of returning or obtaining the location of the host computing resources includes returning or obtaining a pair of a target and a port, the target including an identifier of the host computing resources, and the port including an identifier of an Internet protocol communication port used by the payment service. The method according to any one of claims 3 to 5. **Claim 7** The host computing resources are associated with a payment network different from the network associated with the network identifier of the alias, and the payment service of one or more entities registered in the network is delegated to a payment domain associated with the payment network. The method according to any one of claims 1 to 6. **Claim 8** The host computing resources are associated with a payment network, and the domain of the payment network is the same as the domain of the network associated with the network identifier of the alias. The method according to any one of claims 1 to 7. **Claim 9** receiving, from the payment service associated with the recipient entity, an affirmative response to a cryptocurrency payment. The method according to claim 1. **Claim 10** The method according to any one of claims 1 to 9, wherein the alias is a payment handle associated with the client. **Claim 11** A method for constructing a prefix for generating a request related to a transaction from a requesting entity to an alias associated with a client, the method comprising: responding to receiving a request from the requesting entity including the prefix and the alias, and triggering the method according to any one of claims 1 to 10 based on the alias. **Claim 12** A computer system comprising: a processor; a memory including executable instructions that, as a result of execution by the processor, cause the computer system to execute the method according to any one of claims 1 to 11; The system including the above. **Claim 13** A non-transitory computer-readable storage medium storing executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to execute the method according to any one of claims 1 to 11.

Images