Computer-based systems and methods for implementing alias-based addressing for distributed ledgers.

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 a method and system for implementing transactions associated with a distributed ledger, and in particular to a method for destination addressing for one or more digital wallets. The present disclosure is particularly, but not exclusively, suitable for providing a method of implementing cryptocurrency payments from a payee to a payer. [Background Art]

[0002] In the present specification, we use the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. It should be noted that Bitcoin may be referenced herein for convenience and illustrative purposes, but 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 refer herein to a human or processor-based resource. The term "Bitcoin" is considered herein to include any protocol derived from or a variation of the Bitcoin protocol.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset among participants in the blockchain system, and it contains at least one input and at least one output. Each block contains the hash of the previous block, and these blocks are concatenated together to produce a permanent, immutable record of all transactions written to the blockchain since its origin. A transaction contains a small program known as a script. The script embeds its inputs and outputs and specifies how and by whom the transaction's output is accessible. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be verified. Network nodes (miners) perform tasks to ensure that invalid transactions are rejected from the network and that each transaction is valid. Software clients installed on the nodes perform this verification on unspent transactions (UTXOs) by executing lock and unlock scripts for the UTXOs. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must (i) be verified by the first node that receives the transaction, and if the transaction is valid, the node relays the transaction to other nodes in the network, (ii) be added to a new block built by miners, and (iii) be mined, that is, added to the public ledger of past transactions.

[0005] When stored on the blockchain as a UTXO, a user can transfer control of the associated cryptocurrency to another address associated with an input in another transaction. This is often done using a digital cryptocurrency wallet. This digital wallet may be a device, physical medium, program, application (app) on a mobile device, or a remotely hosted service associated with a domain on a network such as the internet. A digital wallet stores public and private keys, tracks ownership of assets associated with the user, and can be used to receive or use cryptocurrency. The cryptocurrency itself does not reside in the digital wallet. In Bitcoin and its derivatives, cryptocurrency is stored and maintained decentralized on a publicly accessible ledger, i.e., the blockchain. There are various forms of known cryptocurrency wallets, and a network of such wallets is called an ecosystem, such as the BitcoinSV (BSV) wallet ecosystem. A digital wallet may also be a Simplified Payment Verification (SPV) wallet.

[0006] Currently, for a BSV cryptocurrency payment to be made between users, i.e., from Alice to Bob, Alice needs to have a digital wallet associated with her (private and public) cryptographic keys and know Bob's public address, i.e., Bob's digital wallet address, to send the cryptocurrency to. Public addresses associated with entities, in this case digital wallets, are usually automatically generated by address generation programs. These public addresses are sequences 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 called the public key or public key hash of the asymmetric private / key pair associated with the entity. Public addresses can be publicly shared, and as a result, other users know where to send their cryptocurrency payments. However, public addresses recognized and used by the BSV wallet ecosystem or other cryptocurrency wallets are in the following format: 17Dx2iAnGWPJCdqVvRFr45vL9YvT86TDsn

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

[0008] Therefore, while it is desirable to use blockchain technology to record data and events because blockchain offers advantages such as tamper resistance and permanent record-keeping, there are difficulties in identifying or establishing destination addresses for cryptocurrency payments. This is because the workable format of these addresses recognized within the wallet ecosystem is not simple or user-friendly. One reason for this format may be the security it provides, along with the specific naming protocol for public IP addresses that applies across digital payment networks. Another reason is that the Bitcoin blockchain allows data to be placed into each transaction (Tx) built into a block. Identifying and accessing relevant data from the blockchain is based on the public address (linked to a private key) of the entity associated with the transaction. This disclosure addresses these technical concerns by providing improved forms and embodiments for destination identification and / or payment addressing for cryptocurrency ecosystems.

[0009] Throughout this specification, variations of the terms "comprise," "includes," "comprises," and "comprising" are understood to mean the elements, integers, or steps described, or groups of elements, integers, or steps, but not to exclude any other elements, integers, or steps, or groups of elements, integers, or steps. [Brief explanation of the drawing]

[0010] Aspects and embodiments of this disclosure are described below by mere examples and with reference to the accompanying drawings. [Figure 1] This is a flowchart illustrating how to update a directory to include payment services according to the first aspect. [Figure 2A] This flowchart illustrates a method for identifying a host responsible for a second type of payment service, which is implemented by one or more processors of the payment service. [Figure 2B]This flowchart illustrates a method for identifying a host responsible for a second type of payment service, which is performed by one or more processors of a payment client entity. [Figure 3A] This is a flowchart illustrating a method for identifying a public address associated with an alias, which is performed by one or more processors of a payment service, according to a second aspect. [Figure 3B] The second aspect is a flowchart illustrating a method for identifying a public address associated with an alias, which is performed by one or more processors of a payment client entity. [Figure 4] This is a flowchart illustrating the public key infrastructure sequence. [Figure 5A] This is a flowchart illustrating a method of destination addressing performed by one or more processors of a payment service, according to a third aspect. [Figure 5B] This is a flowchart illustrating a method of destination addressing performed by one or more processors of a payment client entity, according to a third aspect. [Figure 6] This is a flowchart showing the payment destination endpoint resolution sequence. [Figure 7A] This flowchart illustrates a method for implementing a simplified payment protocol or mechanism according to a fourth aspect using a payment service according to a second and / or third aspect, which is implemented by one or more processors of the payment service. [Figure 7B] This flowchart illustrates a method for implementing a simplified payment protocol or mechanism according to a fourth aspect using a payment service according to a second and / or third aspect, which is performed by one or more processors of a payment client entity. [Figure 8] This is a schematic diagram showing a computing environment in which various embodiments can be implemented. [Modes for carrying out the invention]

[0011] A first aspect of this disclosure provides a computer-implemented method for providing a payment service for one or more clients for transactions associated with a distributed ledger. The method includes the step of providing an alias for a given client, the alias being unique to the given client, and the alias including or relating to a network identifier. The method then includes the step of associating the alias with a 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 the network or domain associated with the network identifier and the location of the host computing resource responsible for providing the payment service, where the host computing resource is configured to identify the client associated with the alias in response to receiving a request for a transaction associated with the alias.

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

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

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

[0015] Advantageously, the above-described embodiment allows requests for payment transactions to be generated using aliases in order to address a recipient entity or a digital wallet associated with a recipient. Thus, the requesting party (paying entity) does not need to know, obtain, or store / cache the complex public address for the digital wallet, i.e., 17Dx2iAnGWPJCdqVvRFr45vL9YvT86TDsn, in order to accomplish or configure a cryptocurrency transaction for the distributed ledger. As a result, cryptocurrency payments can be made to this wallet. Only an alias of the network or related to it, which is easy for the recipient to remember, such as one related to the recipient's email address (name@domain.com), needs to be known or sent by the requesting entity to request the payment transaction. Other formats that identify entities may also be used as aliases. This type of alias addressing provides a much simpler and more user-friendly technique for resolving the address to which a payment is due. In some embodiments, even if the network identifier is not explicitly stated in the alias, as long as the alias is associated with a network identifier, i.e., through a directory or database search, this is sufficient to identify the payment service associated with the alias.

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

[0017] Advantageously, this enables discovery of a host responsible for providing a payment service based only on an alias of a recipient entity, and enables a payment transaction to the recipient entity. This significantly simplifies payment addressing of payment transactions for digital ledgers. Once the host is identified, the digital wallet is associated with a network or a network identifier, and thereby associated with the payment service, so that a public address associated with a client of the recipient entity or the digital wallet can be determined. The term "public address" referred to herein relates to an 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 a payment address or destination address of a client or a 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 be different for each transaction associated with the digital wallet.

[0018] In some embodiments, a 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 cryptocurrency. In this case, the method implemented by the payment client entity comprises the step of transmitting a request for a transaction from the requesting entity, the request being associated with an alias. The method comprises the step of obtaining a location of a host computing resource 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 comprises the step of receiving a public address of the digital wallet associated with the alias, the public address being subsequently used in the requested transaction.

[0019] In some embodiments, the host computing resource is 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 the domain associated with the network identifier is delegated to the domain associated with the payment network.

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

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

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

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

[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, the requesting entity only requires the alias of the payer or destination entity, i.e., the alias associated with the recipient's digital wallet. Thus, it provides a user-friendly, simplified addressing mechanism. This advantage is ensured by the provision of a publicly accessible, machine-readable resource specifying the capabilities or functions provided by the payment service implemented for the digital wallet. This second aspect, which discovers the capabilities of the payment service based solely on knowledge of the recipient entity's alias, is particularly useful when a payer entity associated with a digital wallet wishes to ensure that the capabilities or functions for a transaction are supported when making a payment to the alias before a transfer request is made. Specific capabilities may be key to realizing cryptocurrency payment transactions associated with a distributed ledger, for example, to identify at least one endpoint identifier associated with the payment service, or to implement a secure communication mechanism based on PKI (public key infrastructure), etc. These capabilities are often specified separately from capability entries in the machine-readable resource. Advantageously, capability entries allow for the provision of specifications, or records, of all available supported capabilities. For example, details for configuring specific types of validation, additional security for a given type of transaction or network, encryption levels, supported PKI architecture types, addressing levels, etc., may be provided within the capability object. Thus, the requesting entity can discover and assure that the requested capability associated with the alias is first compatible with the requesting entity's resources, and then provided to any transaction having the alias by accessing the machine-readable resources associated with the alias's payment service.

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

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

[0027] It is understood that the method according to the first embodiment for host discovery is just one of many host discovery methods that can be performed before capability discovery based on machine-readable resources is performed according to the second embodiment. Thus, the first embodiment can be performed independently of the second embodiment, and vice versa. A preferred implementation may include both the host and capability discovery described above, but this combination is not essential for establishing the capability of the payment service associated with the alias. Other methods of host discovery may also be compatible with the second embodiment, in addition to the use of service records in the first embodiment 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 service record-based implementation discussed in the first embodiment. Furthermore, host discovery that resolves endpoint identifiers may be skipped in the second embodiment if, for example, the host location is easily discoverable or public, or is associated with the same domain as one or more digital wallets.

[0028] Accordingly, the embodiments described below are understood to be based either on the second embodiment alone or on a combination of the first and second embodiments 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 the step of identifying a payment service associated with the alias based on a network identifier. Next, based on identifying the payment service, the method includes the step of accessing a machine-readable resource from a predictable or known network location. Having determined whether one or more capabilities required for the requested transaction exist within the machine-readable resource, the method includes the step of returning an endpoint identifier for a host computing resource for the payment service, and based thereon, the step of obtaining a public address associated with the alias in accordance with one or more instructions and / or specifications within the machine-readable resource.

[0030] Advantageously, the embodiments described above enable obtaining the public address associated with an alias without knowing only the alias and without knowing any further information to contact the recipient entity. Furthermore, the public address is obtained from a machine-readable resource associated with the payment service based on an endpoint identifier in order to determine that 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, and user-friendly technique for obtaining and initiating the use of the public address of an entity that has only an alias.

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

[0032] In some embodiments, each digital wallet is associated with a user or entity registered for a payment service within the network, and each digital wallet is a cryptocurrency wallet associated with the public and private keys of an asymmetric cryptographic key pair for transactions on the distributed ledger. In some embodiments, the step of obtaining a public address includes the step of obtaining the public key of the digital wallet associated with the alias. In some embodiments, 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. In relevant 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 on or posted to the distributed ledger.

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

[0034] It should be understood that while these instructions reside within machine-readable resources associated with the payment service, they may be intended to be executed by one or more computing resources or applications associated with the payment client entity. The one or more computing resources executing these instructions may be associated with a payment client application installed in or associated with the payment client entity's digital wallet.

[0035] Advantageously, the provision of machine-readable documentation associated with the payment service allows for the generation of appropriate requests to the payment service in a specified format, utilizing known aliases, to obtain the public key of the recipient entity. This public key is required to sign transactions for the distributed ledger.

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

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

[0038] In a third aspect, the Disclosure provides a technique for payee addressing. This third aspect relates to the second aspect of capability discovery, as it is used to resolve that a machine-readable resource addresses a payee, i.e., to transmit a payment. Optionally, the third aspect may also include the first aspect of host discovery, but this is not qualitative, as other means of host discovery may also be used in combination with the third aspect of the Disclosure.

[0039] A third aspect of this disclosure provides a method comprising the step of obtaining a public address associated with an alias in the second aspect described above, further comprising the step of obtaining a payee entity payee associated with the alias, the payee being used when configuring a transaction for making a cryptocurrency payment from the payer entity to the alias. The step of configuring a transaction according to the third aspect comprises the step of accessing a machine-readable resource based on identifying a payment service. This is followed by the step of returning a payee endpoint identifier based on one or more instructions and / or specifications in a machine-readable document. Payment details for the transaction from the payer entity are then 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. A digital signature is then obtained that associates the payment details with the payer entity's cryptographic key. An output script associated with the payee endpoint identifier associated with the alias is then generated for provision to the payer entity. The output script is provided for embedding in a payment transaction for a distributed ledger.

[0040] Advantageously, the third aspect allows for the reception of the output script of the digital wallet associated with the alias, thereby automatically enabling the construction of a transaction in a format suitable for inclusion in the digital ledger. This is based solely on knowledge of the recipient's alias, with the remaining details established from machine-readable resources associated with the host providing the payment service. Furthermore, enabling the provision of a ready output script to be included in the transaction along with the alias knowledge provides an overall simplified, seamless, efficient, automated, easy-to-implement, and user-friendly alias based on payment addressing techniques for digital wallets.

[0041] A third embodiment of the method may be implemented in or by a payment client entity, such as a digital wallet or application or processor associated with the payment client entity requesting the transaction. In this case, the method of constituting the 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 for the transaction. The payment details include an alias associated with the recipient entity's digital wallet and the amount of cryptocurrency to be paid to the recipient. The method includes the steps of providing a digital signature that associates the payment details with a cryptographic key and receiving an output script associated with the payee endpoint identifier associated with the alias. The output script is then embedded in a payment transaction for a 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 payee endpoint identifiers. Aliases and network identifiers 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 while these instructions reside within machine-readable resources associated with the payment service, they may also be intended to be executed by one or more computing resources or applications associated with the payment client entity. The one or more computing resources executing these instructions may be associated with a payment client application installed with or associated with the digital wallet associated with the payment client entity.

[0044] Advantageously, the provision of machine-readable documentation associated with the payment service allows for the generation of a specified-format request to the payment service for obtaining a payee endpoint identifier or URI, utilizing known aliases. Consequently, this may be used in the configuration of transactions for a distributed ledger.

[0045] In some embodiments, the public addresses of the alias and the payer entity include the public keys of the respective digital wallets associated with the recipient entity and the payer entity, respectively, and the digital signature is used to verify the identity of the payer entity requesting the transaction. In some related embodiments, the digital signatures associated with both the recipient 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 disclosure provides a process or protocol for when a payment client, i.e., a payer entity, wishes to make a cryptocurrency payment to another payment client, i.e., a recipient entity. The protocol in this aspect is hereafter referred to as the simplified payment protocol. The fourth aspect relates 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 relates to the third aspect of payee addressing and provides an improved technique for implementing payee addressing, in particular for simplifying the process for such addressing.

[0047] A fourth aspect relates to a computer-implemented method for implementing a payment service for one or more clients for transactions associated with a distributed ledger such as the Bitcoin blockchain. In the first implementation, the method is performed 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. In some embodiments, this machine-readable resource is as described above with respect to the third aspect and is provided at or accessed from a predictable or well-known location associated with the payment service.

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

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

[0050] A further benefit provided by the first implementation of the fourth aspect is the facilitation of providing or adding one or more new capabilities to be supported by the payment service. By updating machine-readable resources provided in a predictable or well-known publicly accessible location associated with the payment service, any new capabilities to be added can be automatically deployed or made applicable to 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 handle 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 added or further capabilities described above, there may be instructions to specify further capabilities, or in fact, whether the original generated capabilities are true (on, or 1) or false (off, or 0). This toggle functionality is advantageous because it allows the payment service to either implement or not implement one or more of the capabilities specified in the machine-readable resource for a particular type of transaction, or to set this implementation value accordingly for a particular period of time. Thus, any payment entity, such as a payer entity, can check whether a particular capability is actually implemented for the type of transaction related to the request, or at the time the request is being generated. For example, if the requesting payment client, i.e., the payer entity in this case, is a client that does not support or can not respond to messages or instructions regarding such capabilities, the request may be withdrawn or simply not sent.

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

[0053] A second implementation of the fourth aspect is also performed 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 aspects and embodiments described above, aliases are provided for clients among one or more clients associated with the payment service, the aliases are client-specific, and each client is provided with its own alias. The method includes the step of receiving a payment directive from the payer entity for a cryptocurrency payment associated with an alias, the directive relating to a recipient client among one or more clients associated with the payment service, and the recipient client relating to the alias in the payment directive. In some embodiments, the directive or payment directive is a form, request, or notice in which the payer entity wishes to make a digital asset payment to the recipient entity. In some embodiments, the directive may be automatically provided to the recipient entity when the payer entity requests or obtains one or more goods or services from the recipient entity. The method includes the step of obtaining a payment request template based on machine-readable resources associated with the recipient entity's payment service, the payment request template including the recipient entity's output script. In some embodiments, at least one capability supported by the recipient's payment service includes the simplified payment protocol described above. In some embodiments, the payment request template includes a payee endpoint, or URI, or the public address of a digital wallet associated with the recipient entity, and / or other metadata for the payment. In some embodiments, the recipient 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 the step of receiving a complete payment transaction from a payer entity 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 a network identifier and be included in the template by one or more processors associated with the payer entity's digital wallet, which may be an SPV wallet. The method then includes the step of 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, before submission to the blockchain, the method includes the step of verifying the payer entity as described in the second aspect above, i.e., checking the public key based on the PKI template described above if the payer entity is associated with a payment service.

[0054] The method described above is associated with the same advantages described above in relation to adding new capabilities for the simplified payment protocol to the first implementation of the fourth aspect. Even more advantageously, the simplified payment protocol capabilities for payment services make the processing of digital asset payments more secure and reduce the amount of online interaction required by the paying entity, such as cryptocurrency payments from the paying entity.

[0055] Security is enhanced because the simplified payment protocol requires that all details, metadata, and outputs for the payment be added to a payment template that should be sent to the payer entity in order to process cryptocurrency payments. This enhances the security of digital asset payments (since payments are made based on details sent from the bsvalias payment service). Thus, this embodiment prevents man-in-the-middle (MITM) attacks if the output script is encapsulated within the transaction template and sent directly to the payer entity by the recipient entity. As discussed in relation to the second embodiment, in some embodiments, the payment service specifies instructions for obtaining a public address, which follows a PKI template for verifying the relevant public key, as described in relation to Figure 4.

[0056] Advantageously, the simplified payment protocol capability of the first implementation in the further embodiment does not require the payer to be online, in other words, to be constantly connected to a communication network, in order to generate digital asset transactions to the recipient. Since the output script is provided within the template, the payer client does not need to access the recipient client's payment service, i.e., the bsvalias payment service, to obtain the payment transaction endpoint and metadata for the distributed ledger. Thus, the fourth embodiment enables an offline implementation, which is useful for payer clients that are not constantly connected to a communication network or are computationally less sophisticated, i.e., digital wallets associated with the payer, as they do not need to interact with a payment service to obtain the payment endpoint.

[0057] Furthermore, advantageously, the fourth embodiment ensures that when the recipient entity is responsible for posting to the blockchain, it is easy to search for and monitor payments or transactions associated with the recipient entity. Thus, the recipient entity no longer needs to monitor the blockchain for its own transactions. A payer client can also use the fourth embodiment to identify a transaction of a given recipient entity. Thus, the complete signed transaction is not posted by the payer entity, but instead is provided to the recipient entity by including an alias and network identifier in a payment request template provided in JSON format from a machine-readable resource of the payment service. Thus, the simplified payment protocol is similar to a payment flow model based on familiar invoices, making it more adoptable and interoperable for businesses or organizations using traditional accounting systems that require purchase orders, etc., to make digital asset payments.

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

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

[0060] In some embodiments, the method of the fourth aspect includes the step of sending an acknowledgment to the payer entity for receipt of a complete payment transaction. This, advantageously, allows the payer entity to track the payment transactions it has sent to recipient entities associated with the payment service and to check the status of the transactions. In some embodiments, the acknowledgment includes a transaction identifier (TxID) for each transaction.

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

[0062] The method described above has the same advantages as those described above in relation to the method implemented by the payment service according to the fourth aspect, except that the method is a method 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] Further aspects of this disclosure relate to a method for configuring a prefix to request a payment transaction from a requesting entity to an alias associated with a digital wallet in the network. As a result, in response to receiving a request from a requesting entity including the prefix and alias, the first and / or second and / or third aspects of this disclosure may be automatically executed by a payment service based on the alias.

[0065] Advantageously, the fourth aspect allows the requesting entity to automatically trigger the aspects and embodiments described above by simply presenting a prefix, such as "payto:" or "bsvto:", following an alias of the recipient entity known to it. This prefix, advantageously, allows a request for a payment transaction to be generated and sent to the payment service based on one or more of the aspects and embodiments described above. All the requesting entity needs to do is add the known alias to the prefix.

[0066] The Disclosure also provides a computing device including a processor and memory containing instructions that, as a result of execution by the processor, cause a computing device to perform any aspect or embodiment of the methods performed by the computer described in this specification. The Disclosure also provides a system including a plurality of such devices that can operate together to perform any of the above aspects or embodiments.

[0067] The disclosure also provides a non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by a processor of a computing device or system, cause the computing device or system to perform at least one aspect or embodiment of a method performed by a computer as described in this specification.

[0068] Several specific embodiments are described herein for illustrative purposes with reference to the accompanying drawings. Here, similar reference numerals indicate similar functions.

[0069] Figure 1 illustrates a method for implementing a payment service for one or more digital wallets associated with an alias, relating to a first aspect of this disclosure. In Figure 1, the method is understood to be implemented by one or more processors associated with providing the payment service. In this disclosure, the payment service may be one or more executable rules or protocols that perform the functions described below. The wallet may be in a network of digital wallets or may be a separate, standalone cryptocurrency wallet for transactions associated with a distributed ledger. For example, the method may be implemented in a network of Bitcoin wallets for the BSV cryptocurrency. For simplicity and ease of understanding, an alias associated with a digital wallet in a network of digital wallets will be referred to below in the description of the figure. However, as stated above, this disclosure is not often limited to digital wallets connected to other wallets in the network.

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

[0071] Step 104 relates to generating a service record for a payment service based on a network identifier in the directory. This step is necessary to associate an alias with the network identifier providing the payment service in the directory. The directory referred to herein is typically an open, i.e., a decentralized directory that is publicly accessible to any user. For example, a global directory such as DNS can be used. It is decentralized and open and therefore accessible from anywhere via the internet by any entity or user. An open, accessible, decentralized directory is a preferred implementation, but the 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., accessible only to users or entities registered with the network or service. For the sake of clarity, a global directory such as DNS will be mentioned below. It will be understood by those skilled in the art that other types of directories are also within the scope of this disclosure.

[0072] For example, when an alias is provided in an input or request in the format described above, a directory such as DNS is searched (caDNS lookup) to determine whether the payment is to be made using the alias. If an alias associated with a network or domain that does not support aliases based on payment services is entered, this situation may be handled using one or a combination of the following implementations. In one implementation, DNS does not return a result indicating that payment using the alias cannot be made. If a service record does not exist, the requesting entity must obtain a public address by other known techniques before any transactions associated with the distributed ledger can be generated. In another implementation, for example, when a service is provided by the dame domain as the network identifier, the returned result may be the location of the host responsible for the network or domain associated with the alias. For example, based on the example above, if a service record for the payment service associated with the network identifier in the alias does not exist in the directory, the location or URI of the host responsible for the domain "nchain" may be provided, or the requesting entity may be directed to the host for the domain "nchain". Therefore, 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 an entry or field in it that indicates a payment service provided by the network or domain associated by the network identifier. The step of updating the service record in DNS indicates that a particular network identifier, such as nchain.com, provides or uses a particular payment service, identified as, for example, "bsvpay" or "bsvalias". This updating step indicates to entities performing DNS lookups that, considering the identified payment service, i.e., "bsvalias", they can perform payment transactions against the alias associated with the nChain domain.

[0074] Step 108 concerns updating the service record to indicate the location of the host computing resource responsible for the payment service shown in Step 106. Thus, if the payment service is associated with a different network or domain to the network of digital wallets, this entry in the service record would point to the web server location or IP address of the host computer or server responsible for the service. Continuing from the example above, if the bsvalias payment service is associated with a separate network or separate domain (bsvalias.com), the location or instruction identifying the host server for bsvalias.com would be indicated in the service record. This is to identify where the host computing resource 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 DNS that defines 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 the following fields or entries in the following format: • service: The symbolic name of the desired service. • proto: The transport protocol for the desired service, which is usually TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). • name: The valid domain name for this record, ending in a dot. • TTL: A standard DNS lifespan field that sets the end period or deadline associated with a record. • class: This is a standard DNS class field. • priority: This is the priority of the target host. • weight: This is the relative weight among records with the same priority. • port: The TCP or UDP port on which the service should be discovered. • target: This is the standard hostname of the machine providing the service.

[0077] For example, an nchain domain owner may generate an SRV (service) record with the following parameters: [Table 1] Figures 2A and 2B are flowcharts illustrating how to identify the host responsible for payment services. Figure 2A shows the process performed by one or more processors associated with the payment service. Figure 2B shows the process performed by one or more processors associated with the payment client entity.

[0078] In step 202a of Figure 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 interface to the requesting entity's computing device, i.e., input from an installed digital wallet. For example, the request may include a request indicating a payto from the payer entity to alice@nchain.com.

[0079] In step 204a, in response to the request or input in step 202a, a global directory lookup, such as 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 associated with the network identifier in the alias. Thus, using the same example described above for Figure 1, this step identifies the service record for the domain nchain as described above, since nchain was received among the network identifiers in the alias. This service record for nchain then identifies bsvalias as the payment service used for nchain.

[0080] In step 206a, once the service record, and therefore 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 nchain's srv record. The target:port pair provides the location used or operated by the host responsible for the service bsvalias.

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

[0082] Figure 2B relates to the steps corresponding to Figure 2A, as described above, but is performed on the computing device or digital wallet of the payer or requesting entity.

[0083] Therefore, step 202b relates to sending a request for a transaction from the requesting entity, and the request is associated with the alias.

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

[0085] In step 208b, the public address of the digital wallet associated with the alias is obtained. This can then be used for transactions associated with the digital ledger.

[0086] Figures 3A and 3B are flowcharts illustrating a method according to a second aspect of this disclosure for identifying a public address associated with an alias in a request for a transaction. Figure 3A shows a method implemented by one or more processors associated with a payment service. Figure 3B shows a method implemented by one or more processors associated with a payment client entity.

[0087] In step 302a of Figure 3A, machine-readable resources are generated for the payment service. The machine-readable resources are provided to ensure that the features or capabilities offered or supported by the payment service, and / or any instructions that utilize these capabilities, can be identified. This process is therefore called capability discovery related to the payment service. Thus, machine-readable documents are generated for the capability discovery process. This allows a payment client entity or digital wallet or application wishing to use or request the service to learn or discover the supported features of the payment service and any respective endpoints and configurations related to the use of the payment service. In some embodiments, the machine-readable resources are pre-generated and stored files or documents associated with the payment service, i.e., static documents. In some embodiments, for example in an enterprise-grade service implementation, the machine-readable resources may be dynamic and can be generated on demand rather than as static files stored, for example, on a web server. Advantageously, such dynamically generated resources provide simplification in service deployment, migration, maintenance, and any upgrades required to be performed.

[0088] In some embodiments, the lightweight data exchange format JSON (JavaScript Object Notation) is used to generate machine-readable resources. JSON is a completely language-independent text format that uses conventions familiar to programmers accustomed to the C family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data exchange language. Furthermore, JSON is built on two structures: a collection of name / value pairs and an ordered list of values. In many languages, this is implemented 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 it provides a data format that is interchangeable with other programming languages ​​based on these same structures.

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

[0090] An entry associated with at least one of several capabilities supported by the Payment Service. This may be one or more capabilities that can be supported by the Payment Service, such as requesting entity or payer entity verification, multiple digital signatures for a transaction, recipient entity or payee authorization for a transaction, and / or email-based payment transactions that ensure the transaction is sent to an email address associated with an alias before being posted to the distributed ledger, payer and / or recipient callback functionality related to a request or response, etc.

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

[0092] For example, machine-readable resources may refer to the following files or entries for the payment service "bsvalias":

number

[0093] The template values ​​{name} and {domain.tld} are alias formats. <name> @ <domain> . <tld>This represents the components of the .tld, where .com, .org, or .co.uk is the top-level domain. The requesting entity or payment client may replace the template with an alias. In the example above, this would be alice@nchain.com.

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

[0095] Providing JSON-formatted documentation in a well-known and predictable location is useful. As a result, it becomes publicly accessible to all entities that recognize the payment service (e.g., based on network identifiers). The exemplary locations described above are based on the IANA (Internet Assigned Numbers Authority) Well-Known URI resources. Therefore, machine-readable resources are placed in a predictable location on the web server for discoverability related to payment services (bsvalias).

[0096] In step 306a, a request for a transaction is received from the payment client entity, and the request includes an alias to which the payment should be directed. Continuing from the example above, this would include a request like 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 Figure 3. For example, a mapping stored in a database, or a text document based on the service discovery process, may be used to identify the host of bsvalias instead of the service record in the first aspect.

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

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

[0100] Assuming in step 314a that the machine-readable resource has at least one supported capability for a transaction (if this is specified by the requesting entity), once this is identified, the machine-readable resource returns an endpoint identifier associated with the host computing resource for the payment service. In the example above, this could be the location of the host responsible for bsvalias. Then, using one or more 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 relates to the steps corresponding to Figure 3A, as described above, but is performed on the computing device or digital wallet of the payer or requesting entity.

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

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

[0104] Step 312a determines whether one or more capabilities for the requested transaction exist within the machine-readable resources. This step, similar to step 312a in Figure 3A, includes checking a JSON document 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, i.e., the host location for the service bsvalias.

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

[0107] Figure 4 shows an exemplary sequence of instructions specified within a machine-readable resource in a second embodiment of a public key infrastructure (PKI) technique for obtaining the cryptographic 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 for requesting a PKI endpoint identifier, which is the URI of the payment service's computing resource configured to identify and / or verify the public key of the payment client entity. For example, continuing from the example above, the template may be: "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 in the appropriate fields of the template to generate a complete PKI request. For example, the template values ​​{name} and {domain.tld} are aliases, i.e. <name> @ <domain> . <tld>This represents a component that must be substituted before issuing a complete request based on machine-readable resources. 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. When 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 payment service's PKI 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 hexadecimal encoded. This means the "pubkey" string is 66 bytes long (33 bytes in 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 a payment service and / or public key, the response message will indicate that an error occurred, or that the requested resource could not be found, was not available, or was not authorized.

[0114] Figures 5A and 5B are flowcharts illustrating a method according to a third aspect of the present disclosure for identifying a payee associated with an alias in a request for a transaction. The payee is used when configuring 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 a payee is based on or part of obtaining the public key associated with the alias in Figures 3A and 3B. In some embodiments, the payee endpoint identifier relates to an address that should be encoded or included in the output script, and as a result, the transaction may be configured for the blockchain based on this address. In some embodiments, the payee endpoint identifier is the same as the public address described above. In other embodiments, the payee endpoint identifier may be different from the public address associated with the alias, or may be a part of or associated with the public address for a digital wallet. In some embodiments, the public address and / or payee endpoint identifier associated with the alias may be assigned statically or dynamically.

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

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

[0117] In step 506a, the payment details 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 containing the payment details from step 506a, and the cryptographic key associated with the payer entity are obtained. This signature, associated with the request related to the transaction, is often applied using the private key of the requesting party, i.e., the payer entity.

[0119] In step 510a, the digital signature may be verified, thereby authenticating the identity of the payer entity. This may be done using one or more known techniques. Assuming that an ECDSA key is used in some embodiments, the public key of the payer entity obtained using, for example, the PKI sequence in Figure 4 can be used to verify the identity of the signing entity (payer entity). If 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 successful verification output in step 510a, an output script is generated based on the payee endpoint identifier associated with the alias. This output script is provided for embedding in a payment transaction for the distributed ledger in order to automatically resolve the payee in the transaction for the distributed ledger.

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

number

[0122] The value of the output field may be a hex-encoded Bitcoin script, which the payer entity will use during the configuration of the payment transaction.

[0123] While various types of output scripts may be generated, for the sake of simplicity, the generation of a P2PKH (Pay to Public Key Hash) output script will be discussed in the following example.

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

number

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

number

[0126] This can be broken down as follows:

number

[0127] The service response body, that is, the script to be embedded in the transaction in step 512a, is therefore as follows:

number

[0128] Figure 5B relates to the steps corresponding to Figure 5A, as described above, but is performed on the computing device or digital wallet of the payer or requesting entity.

[0129] In step 502b, a request for a transaction from the payer entity, which is based on a request associated with an alias, is accessed by the payer entity from a location associated with the payment service.

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

[0131] Step 506b relates to the step of sending or providing payment details for a transaction. Payment details include the 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 relate to the step in which the payer entity provides a digital signature to associate the payment details with a cryptographic key, followed by verification as discussed in the corresponding step in Figure 5A.

[0133] Step 512b relates to the step of receiving the output script by the payer entity based on the payee endpoint identifier associated with the alias. This was explained in relation to Figure 5A above.

[0134] Step 514b relates to the step of the payer entity configuring a payment transaction for the distributed ledger by embedding the received output script into the transaction.

[0135] Figure 6 shows an exemplary sequence of instructions specified within a machine-readable resource that perform the payment destination 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 Figures 5A and 5B. For example, continuing from the above example for the payment service bsvalias, the template may be: "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 in 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, i.e. <name> @ <domain> . <tld>The components of this 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 generating the output transaction associated with the alias.

[0138] In step 606, an HTTP POST request is generated based on the payment 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 configuring payment transactions for the distributed ledger, as discussed in Figures 5A and 5B.

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

number

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

[0142] In some embodiments, it is sufficient if, in addition to including an alias for the recipient entity, there is a field in the schema described above that is identified as payerHandle, or 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 payer's public identifier or IP or Bitcoin address. Hereafter, payerHandle in this 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 the payment transaction based on that alias. The payer's payment service may be the same as or different from the recipient's payment service.

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

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

[0145] The timestamp field "dt" may contain the current time in the accepted standard ISO-8601 format at the time the payer initiated the payment 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 paying entity or client to sign and verify the message signature. This capability is often essentially a standard ECDSA implementation, but with (r,s) signature pairs for integers r and s, and additional information provided to allow the client to verify the message signature against a P2PKH address (a hash of the public key) rather than directly against the public key.

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

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

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

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

[0151] If no quantity exists, the string "0" is used.

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

[0153] Figures 7A and 7B are flowcharts illustrating a method for implementing a simplified payment protocol for cryptocurrency payments to recipient clients associated with a payment service, such as the bsvalias payment service described above in relation to 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 the payment service for the recipient 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 different payment service as the payment service for the recipient entity, i.e., in this case, a payer entity.

[0154] In some embodiments, the simplified payment protocol of the fourth aspect is based on a payee associated with an alias discussed in relation to Figures 5A and 5B. In some embodiments, the payee is associated with an address that should be encoded or included in the output script, and as a result, 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 the public address for a digital wallet associated with the alias, or may be associated with it. 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 relation to Figures 7A and 7B may be implemented by a digital wallet which is an SPV for the recipient entity and / or payer entity. However, this is not essential if a payment service like bsvalias can be implemented for any type of computing device or wallet implementation as described in the embodiments described above.

[0155] In a non-restrictive description of a fourth aspect of payment transactions between two payment entities, continuing the example above, we assume that Alice (payer) wants to pay Bob (recipient), and both parties use the same type of SPV wallet. An SPV wallet is known to store the user's private and public keys, unused transactions, and block headers. Such a wallet also has the ability to connect to the blockchain. The term “block header” is conventionally known and used to represent the data provided at the top of a block of blockchain transactions. A block header can be placed on the blockchain because it uniquely identifies the block. It has fields of data that provide a unique summary or fingerprint of the contents of the entire block. A block header contains a Merkle Root, which is the hash of all the transactions in the block. A user can then look up the Merkle tree with the root to check (i.e., verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain. The advantage of SPV wallets is that they enable devices with limited power and memory, such as phones and laptops, to operate within a blockchain network, as they only need to check that a transaction has been verified (hence the term "simplified payment verification") rather than performing a full blockchain check for each other form of digital wallet. Improved security solutions for verification on blockchain networks using low-bandwidth SPV systems are described in detail in the following UK patent applications filed on February 5, 2019, by nChain Holdings Limited: GB1902086.6, GB1902088.2, GB1902090.8, GB1902089.0, and GB1902092.4. While SPV wallet implementations in these applications may be used to implement a fourth aspect of this disclosure, this disclosure is not limited to such SPV wallets.

[0156] An embodiment of the fourth aspect is discussed below with reference to Figure 7A, where the method is carried out by one or more processors associated with a payment service for a payment client, in this case a recipient entity.

[0157] Step 702a represents the step of receiving a payment directive from the payer entity for a cryptocurrency payment associated with an alias of the recipient client. Thus, continuing the example of the embodiment described above, this step includes obtaining a request from Alice to make a payment to Bob, where Alice indicates that the cryptocurrency payment, i.e., 3BSV, will be made to an alias that Alice recognizes for Bob, i.e., bob@nchain.com. In this case, the alias includes the name "bob" and the network identifier "nchain". However, as mentioned in the embodiment described above, the name in the alias may be or indicate the 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 notification sent or generated by the payer client upon intent to use or purchase of goods or services offered by Bob, or by such use. In this case, Bob is considered the merchant and Alice is the customer.

[0158] In step 704a, upon receiving the payment instruction, the payment service, which is bsvalias from the example above, accesses a machine-readable resource, i.e., a JSON document, to identify the capabilities available to Bob, i.e., the recipient client, for such payment. Assuming that bsvalias supports the above-mentioned simplified payment protocol capabilities for the alias bob@nhain.com, such capabilities may be specified in the bsvalias JSON document as follows:

number

[0159] The template values ​​{name} and {domain.tld} are aliases for the recipient, i.e. <name> @ <domain> . <tld>This represents a component of the ability. This should be substituted by the user or another payment client before issuing a request in relation to this ability. In this example, 3b585cdaa4cd may be an entry identifier representing the simplified payment ability in a machine-readable document.

[0160] In step 706a, once the capability of the simplified payment protocol is specified 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 instruction received from Alice in step 702a. This output script should be included in the payment request template, which can be sent directly to the payment client, 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 bsvalias machine-readable resource, in the form of a URI template referred here as the payment request template. The output script is associated with the payee endpoint for payment and may also indicate other metadata such as the end time / day of the output script. The payment request template generated based on the output script may include the following example:

number

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

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

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

[0165] In step 710a, a complete payment transaction based on the template from step 706a is received from the recipient entity. This is received as an HTTPS POST request, similar to the request float described for payee addressing in Figure 6. Here, aliases, i.e., name and network identifier, are 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, as the output script is already included in the template. The received complete payment transaction is signed by the payer entity. This is a digital signature associated with the payer entity's public key in this step, which may be verified, for example, using an HTTPS GET request associated with the PKI template described in Figure 4.

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

[0167] The fourth embodiment of the method and its implementation is advantageous in that it makes it far easier for a wallet, processor, and / or computing device associated with the recipient entity to track incoming transactions without scanning all transactions and all blocks in the blockchain, or relying on Bloom filters to do so. Thus, for a node, i.e., the recipient entity, Bob in this example, 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 recipient clients, requiring that the payer's digital signature be verified before being submitted to the blockchain. This is an additional security measure. The payment service for recipient clients may choose to reject signed transactions that do not pay 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] Figure 7B relates to the steps corresponding to Figure 7A, but is performed on the payer's or requesting entity's computing device or digital wallet.

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

[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 contains all the details of the blockchain transaction and the output script to make the payment to the recipient entity.

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

[0173] In step 708b, the digital signature associated with the payer entity's public key is applied to sign the complete payment transaction. As mentioned above with respect to step 710a, this is to allow 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, once the complete payment transaction is sent, the payer entity may receive an acknowledgment of the cryptocurrency payment from the payment service associated with the recipient entity. This may be used to track or monitor payments associated with the payer entity, i.e., Alice.

[0175] Referring to Figure 8, a simplified block diagram is provided for describing a computing device 2600 that may be used to carry out 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 payment client entity, i.e., to implement a host responsible for providing a payment service, or to implement a payer or recipient 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 Figure 8, the computing device 2600 may include one or more processors having one or more levels of cache memory and memory control units (collectively labeled 2602) that can be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620, as shown. The storage subsystem 2606 and the cache memory 2602 may be used for storing information such as transaction and block-related details as described in this disclosure. The processor 2602 may be used to provide any step or function of any embodiment as described in this 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 the 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 interfaces to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and sending data to other systems of the computing device 2600. For example, the network interface subsystem 2616 allows data technicians to connect the device to a network. As a result, data technicians can send data to and receive data from the device even if they are in 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, integrated mouse, trackball, touchpad, or graphics tablet; a scanner, barcode scanner, touchscreen integrated 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 a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may include a planar display such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or projection, or other display device. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms that output 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 facilitate user interaction with an application that performs the processes and variations described herein, when such interaction is appropriate.

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

[0182] The computing device 2600 may be of various types, including portable computer devices, tablet computers, workstations, or any other devices described later. Furthermore, the computing device 2600 may include other devices that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. Thus, this device may be configured to convert optical signals into electrical signals transmitted to the computing device 2600 through ports to which the device is connected for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 2600 shown in Figure 8 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations are possible with more or fewer components than the system shown in Figure 8.

[0183] Referring to Figure 8, a simplified block diagram is provided for describing a computing device 2600 that may be used to carry out 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 payment client entity, i.e., to implement a host responsible for providing a payment service, or to implement a payer or recipient 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 Figure 8, the computing device 2600 may include one or more processors having one or more levels of cache memory and memory control units (collectively labeled 2602) that can be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620, as shown. The storage subsystem 2606 and the cache memory 2602 may be used for storing information such as transaction and block-related details as described in this disclosure. The processor 2602 may be used to provide any step or function of any embodiment as described in this 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 the 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 interfaces to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and sending data to other systems of the computing device 2600. For example, the network interface subsystem 2616 allows data technicians to connect the device to a network. As a result, data technicians can send data to and receive data from the device even if they are in 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, integrated mouse, trackball, touchpad, or graphics tablet; a scanner, barcode scanner, touchscreen integrated 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 display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may include a planar display such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or projection, or other display device. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms that output 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 facilitate user interaction with an application that performs the processes and variations described herein, when such interaction is appropriate.

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

[0190] The computing device 2600 may be of various types, including portable computer devices, tablet computers, workstations, or any other devices described later. Furthermore, the computing device 2600 may include other devices that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. Thus, this device may be configured to convert optical signals into electrical signals transmitted to the computing device 2600 through ports to which the device is connected for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 2600 shown in Figure 8 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations are possible with more or fewer components than the system shown in Figure 8. <Examples of listed embodiments> (Item 1) A computer-based method for providing payment services for one or more clients for transactions associated with a distributed ledger, the method being: A step of providing an alias for a given client among the one or more clients, wherein the alias is specific to the given client, and the alias includes or is associated with a network identifier. The steps include associating the alias with the network identifier in the directory, Includes, The aforementioned association step is, The steps include generating a service record based on the network identifier in the directory, The steps include updating the service record to indicate that the payment service is provided by the network or domain associated with the network identifier, A step of updating the service record to indicate the location of the host computing resource responsible for the payment service, wherein the host computing resource is configured to identify the digital wallet associated with the alias in response to a request relating to a transaction associated with the alias. Methods that include... (Item 2) The method described in Item 1, wherein each of the one or more clients is associated with a digital wallet. (3) The step of performing a search of the directory based on the alias in response to a request from a requesting entity related to a transaction associated with the alias, The steps include identifying the service record of the payment service in the directory associated with the network identifier, A step of returning the location of the host computing resource 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; The method described in item 1 or 2, including the method described in item 1 or 2. (Item 4) A method relating to a transaction for a distributed ledger, wherein an alias is provided for a given client among one or more clients, the alias is specific to the given client, the alias includes or relates to a network identifier, and the method A step of sending a transaction-related request from a requesting entity, wherein the request is associated with the alias, A step of obtaining the location of a host computing resource associated with a payment service, wherein the location is based on a service record associated with the network identifier identified in a directory search, Includes, A method wherein the public address of the client associated with the alias is determined based on the location, and the public address is used in the transaction. (Clause 5) Each of the one or more clients is associated with a digital wallet, as described in Clause 4. (Clause 6) The method of any one of Clauses 3 to 5, wherein 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 including an identifier for the host computing resource and the port including an identifier for an Internet Protocol communication port used by the payment service. (Clause 7) The method according to any one of Clauses 1 to 6, wherein the host computing resource is associated with a payment network different from the network identifier associated with the alias, and the payment services of one or more entities registered with the network are delegated to the payment domain associated with the payment network. (Clause 8) The method according to any one of Clauses 1 to 7, wherein the host computing resource is associated with a payment network, and the domain of the payment network is the same as the domain of the network associated with the network identifier of the alias. (Item 9) A computer-based method for providing a payment service for one or more clients for transactions associated with a distributed ledger, the method being: A step of generating a machine-readable resource associated with the payment service, wherein the machine-readable resource is: At least one endpoint identifier associated with a host computing resource responsible for performing the payment service for each client, wherein each client is associated with an alias, and the alias includes or is related to a network identifier, An entry associated with at least one of the multiple capabilities supported by the aforementioned payment service, Instructions and / or specifications for accessing or obtaining a public address associated with the alias, wherein the public address is used to implement a transaction associated with the alias, Steps including, The steps include providing the machine-readable resource at a predictable or known location associated with the payment service, A method that includes this. (Clause 10) Each of the one or more clients is associated with a digital wallet, as described in Clause 9. (Article 11) The aforementioned multiple capabilities are: Verification of payer entity or payee entity, Multiple digital signatures for a transaction, Recipient entity authorization for transactions, Payment transactions related to email protocols, A simplified payment protocol or flow for payment transactions, and / or Callback request or response, The method described in paragraph 9 or 10, which includes one or more of the following: (Clause 12) further comprising the step of determining the location of a host computing resource by any method of Clauses 1-3, 6-8, wherein the endpoint identifier in the machine-readable resource is based on the determined location by any method of Clauses 9-11. (Section 13) In response to receiving a request from a requesting entity relating to a transaction associated with an alias, the method shall The steps include identifying the payment service associated with the alias based on the network identifier associated with the alias in the request, The steps include accessing the machine-readable resource from the predictable or known location based on the identified payment service, Steps include: In response to identifying whether one or more capabilities required for the transaction exist within the machine-readable resource, returning an endpoint identifier for the host computing resource for the payment service from the machine-readable resource; A step of obtaining the public address associated with the alias based on one or more of the instructions and / or specifications in the machine-readable resource, The method described in any of items 9 to 12, including the method described in item 9. (Clause 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 specific to the given client, the alias includes or is associated with a network identifier, and the method A step of sending a transaction-related request from a requesting entity, wherein the request is associated with the alias, A step of accessing the machine-readable resource from a location associated with the payment service, wherein the payment service is identified based on the network identifier in the alias, and the machine-readable resource is generated in accordance with Section 9, The steps include receiving an endpoint identifier for 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, The steps include obtaining the public address associated with the alias using one or more of the instructions and / or specifications within the machine-readable resource, A method that includes this. (Clause 15) The method of Clause 13 or 14, wherein each client associated with a digital wallet is associated with a user or entity registered for the payment service in the network, and each digital wallet is a cryptocurrency wallet associated with the public and private keys of an asymmetric cryptographic key pair for transactions on the distributed ledger, and the step of obtaining the public address includes the step of obtaining the public key of the digital wallet associated with the alias. (Clause 16) The public address associated with the alias is the method of Clause 15, based on the cryptographic hash of the public key of the digital wallet associated with the alias. (Clause 17) The method of Clause 15 or 16, wherein the public key of the digital wallet is an elliptic curve digital signature algorithm (ECDSA) public key, and the public key is not part of any transaction previously stored in or entered into the distributed ledger. (Clause 18) The one or more instructions and / or specifications in the machine-readable resource are: Regarding the PKI (public key infrastructure) endpoint identifier, obtain the PKI request template from the machine-readable resource mentioned above, The process involves including the alias and network identifier in the template to generate a complete PKI request, To obtain the public key associated with the alias, an HTTP GET request is sent based on the complete PKI request, The method described in any one of paragraphs 13 to 17, including the method described in paragraphs 13 to 17. (Clause 19) The method in any of Clauses 9 to 18, wherein 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 specification of the payment service contained in a publicly accessible, well-known domain repository. (Clause 20) The machine-readable resource is generated using the JSON (JavaScript Object Notation) format in any of the methods described in Clauses 9 to 19. (Section 21) The step of obtaining the public address associated with the alias is: The steps include obtaining a payee entity associated with an alias, wherein the payee is used when structuring a transaction to make a cryptocurrency payment from the payer entity to the alias, The aforementioned method, The steps include accessing the machine-readable resources for the payment service, The steps include: returning a payment endpoint identifier based on one or more instructions and / or specifications in the machine-readable document; A step of obtaining payment details for the transaction from the payer entity, wherein the payment details include an alias associated with the recipient entity client and the amount of cryptocurrency to be paid to the recipient. The steps include obtaining a digital signature that associates the payment details with a cryptographic key associated with the payer entity, A step of generating an output script associated with the payee endpoint identifier associated with the alias, wherein the output script is provided for embedding in a transaction for the distributed ledger, The method described in any of paragraphs 13, 15-20, including the method described in paragraph 13. (Clause 22) The step of obtaining the public address associated with the alias is: A step of obtaining the payee of the recipient entity associated with the alias, wherein the payee is used when structuring a transaction to make a cryptocurrency payment from the payer entity to the alias, The steps that constitute the transaction are: A step of sending a request relating to the transaction from the payer entity, wherein the request is associated with the alias, The steps include accessing the machine-readable resource from a location associated with the payment service, The steps include receiving a payment endpoint identifier based on one or more instructions and / or specifications within the machine-readable resource, A step of providing payment details for the transaction, wherein the payment details include an alias associated with the recipient entity client and the amount of cryptocurrency to be paid to the recipient entity. The steps include providing a digital signature that associates the aforementioned payment details with an encryption key, The steps include receiving an output script associated with the payment destination endpoint identifier associated with the alias, The steps include: generating the transaction by embedding the received output script into the transaction for the distributed ledger; The method described in any of paragraphs 14 to 20, including the method described in any of paragraphs 14 to 20. (Clause 23) The one or more instructions and / or specifications in the machine-readable resource are: Regarding the payee endpoint identifier, obtain the payee request template from the machine-readable resource, The alias and network identifier are included in the template to generate a complete payee request, To obtain the payee endpoint identifier associated with the alias, an HTTP POST request is sent based on the complete payee request. The method described in item 21 or 22, including the method described in item 21 or 22. (Clause 24) The method of any one of Clauses 21 to 23, wherein the alias and the public address of the payer entity each include the public key of the respective digital wallet associated with the recipient entity and the payer entity, and the digital signature is used to verify the identity of the payer entity. (Clause 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, as described in any of Clauses 21 to 24. (Article 26) A computer-based method for providing a payment service for one or more clients for transactions associated with a distributed ledger, the method being: A step of updating a machine-readable resource associated with the payment service, wherein the machine-readable resource is provided at or accessible from a predictable or known location associated with the payment service, and the machine-readable resource is generated in accordance with Section 9, The updating step is a step of adding at least one further capability supported by the payment service, the at least one further capability comprising the step of implementing a simplified protocol for processing the digital assets of a given client among the one or more clients. (Article 27) A computer-based method for providing a payment service for transactions 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 is specific to the client, and each client is provided with its own alias, and the method The steps include receiving a payment directive from a payer entity for a cryptocurrency payment associated with an alias, wherein the directive relates to a recipient entity among the one or more clients associated with the payment service, and the recipient entity relates to the alias in the payment directive, A step of providing a payment request template based on a machine-readable resource in accordance with Section 9, wherein the machine-readable resource is associated with the payment service, and the payment request template includes an output script for the recipient entity, A step of receiving a complete payment transaction from the payer entity based on the payment template, wherein the complete payment transaction is associated with the alias and the network identifier. The steps include providing the complete payment transaction to the distributed ledger, A method that includes this. (Clause 28) The payment service of the recipient client is performed in accordance with the method described in Clause 26, and the at least one capability supported by the payment service of the recipient client is based on the method described in Clause 27, wherein the at least one capability is based on at least one further capability in the updated machine-readable resources of Clause 26. (Section 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, and the output script is as follows: The steps include accessing the machine-readable resources for the payment service, The steps include obtaining a payment endpoint identifier based on one or more instructions and / or specifications in the machine-readable document, The steps include generating the output script associated with the payee endpoint identifier for the recipient entity to which the alias relates, The method provided by item 27 or 28. (Clause 30) The step of receiving the complete payment transaction from the payer entity in the form of an HTTPS POST request, wherein the complete payment transaction is: Payment details of the payment transaction from the payer entity, wherein the payment details include the alias associated with the recipient entity and the amount of cryptocurrency to be sent to the recipient entity. A step including: a digital signature that associates the payment details with a cryptographic key associated with the payer entity; The step of submitting the complete payment transaction to the distributed ledger, The method described in either item 27 or 29, including the method described in item 27 or 29. (Clause 31) The method of Clause 30, which includes the step of sending an acknowledgment to the payer entity for receipt of the complete payment transaction. (Clause 32) A computer-based 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 is specific to the client, and each client is associated with its respective alias, and the method The steps include generating a payment directive for a cryptocurrency payment associated with an alias related to a recipient entity among the one or more clients associated with the payment service, A step of transmitting the payment instruction to the alias based on one or more instructions and / or specifications in the machine-readable resource described in paragraph 9, wherein the machine-readable resource is associated with the payment service of the alias, A step of obtaining a payment request template from the payment service associated with the alias, wherein the payment request template includes an output script for the recipient entity. Based on the aforementioned acquired payment request template, the following applies: To sign the aforementioned payment transaction, a digital signature associated with the payer entity's public key is applied, Provides a payment including the amount of cryptocurrency to be paid to the aforementioned alias. This involves the steps of generating a complete payment transaction, The steps include sending the complete payment transaction to the recipient entity associated with the alias, A method that includes this. (Clause 33) The method of Clause 1, comprising the step of receiving an acknowledgment of the cryptocurrency payment from the payment service associated with the recipient entity. (Clause 34) The alias is a payment handle associated with the client, as described in any of Clauses 1 to 25. (Clause 35) A method for configuring a prefix for generating transaction-related requests from a requesting entity to an alias associated with a client, the method being: A method comprising the step of triggering one of the steps described in any of items 1 to 34 based on the alias in response to receiving a request from the requesting entity, including the prefix and the alias. (Article 36) A computing device or computer system, Processor and A memory containing executable instructions that, as a result of execution by the processor, cause the system to perform a method performed by a computer as described in any one of paragraphs 1 to 35, A computing device or computer system that includes such devices. (Item 37) A non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform a method performed by a computer as described in any one of items 1 to 35.

[0191] It should be noted that the embodiments described above are illustrative, not limiting, of the disclosure, and that a person skilled in the art can devise many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. Any reference numerals in parentheses in the claims should not be considered limiting. The terms “comprising,” “comprises,” etc., do not preclude the existence of elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “comprising” means “having or comprising,” and “comprising” means “comprising or comprising.” A singular reference to an element does not preclude multiple references to such element, and vice versa. The disclosure can be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In an apparatus claim enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain means are described in different dependent claims does not imply that combinations 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 implementation method for providing a payment service for one or more clients for transactions associated with a distributed ledger, wherein the method is performed by one or more processors associated with providing the payment service, The steps include: one or more processors providing an alias for a given client among the one or more clients, wherein the alias is specific to the given client, and the alias includes or is associated with a network identifier; The steps include: one or more processors associating the alias with the network identifier in the directory; Includes, The aforementioned association step is, The steps include generating a service record based on the network identifier in the directory, The steps include updating the service record to indicate that the payment service is provided by the network or domain associated with the network identifier, A step of updating the service record to indicate the location of the host computing resource responsible for the payment service, wherein the host computing resource is configured to identify the digital wallet associated with the alias in response to a request relating to a transaction associated with the alias. Methods that include...

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

3. The step of one or more processors performing a search of the directory based on the alias in response to a request from a requesting entity related to a transaction associated with the alias, The steps include: one or more processors identifying the service record of the payment service in the directory associated with the network identifier; A step in which one or more processors return the location of the host computing resource 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; The method according to claim 1 or 2, including the method described in claim 1 or 2.

4. A method relating to a transaction for a distributed ledger, wherein an alias is provided for a given client among one or more clients, the alias is specific to the given client, the alias includes or relates to a network identifier, the method is executed by one or more processors associated with the requesting entity, and the method is The steps include: one or more processors sending a request related to a transaction, wherein the request is associated with the alias; The steps include: one or more processors obtaining the location of a host computing resource associated with a payment service, wherein the location is based on a service record associated with the network identifier identified in a directory search; Includes, A method wherein the public address of the client associated with the alias is determined based on the location, and the public address is used in the transaction.

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

6. The method according to any one of claims 3 to 5, wherein the step of returning or obtaining the location of the host computing resource includes the step of returning or obtaining a target-port pair, the target including an identifier for the host computing resource, and the port including an identifier for an Internet Protocol communication port used by the payment service.

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

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

9. The method according to claim 1, comprising the step of one or more processors receiving an acknowledgment of a cryptocurrency payment from the payment service associated with the recipient entity.

10. The method according to any one of claims 1 to 9, wherein the alias is a payment handle associated with a client.

11. A method for configuring prefixes for generating transaction-related requests from a requesting entity to an alias associated with a client, wherein the method is performed by one or more processors associated with providing payment services, A method comprising the step of one or more processors 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.

12. A computer system, Processor and A memory including an executable instruction that causes the computer system to perform the method according to any one of claims 1 to 11 as a result of execution by the processor, A system that includes this.

13. A non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by the processor of a computer system, cause the computer system to perform the method according to any one of claims 1 to 11.

Images