Systems and methods implemented on a computer

Abstract

In a first aspect, the present disclosure proposes a computer-implemented method, device, and system for implementing a channel service for messages or transactions associated with a blockchain, the channel service being provided for one or more clients. The method comprises providing a given client with access to one or more functions enabling direct communication between the given client and another entity, the one or more functions including (i) channel functions or procedures related to one or more channels for the transmission of data and / or (ii) message functions or procedures related to data being transmitted using one or more channels. In a second aspect, the present disclosure proposes a computer-implemented method, device, and system for implementing addressing for a channel service, such as the channel service in the first aspect. Communication using a channel associated with the channel service is initiated based on an addressing key related to the communicating entities.

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for implementing channel services using one or more channels for communication between entities. Specifically, the present disclosure relates to providing access to one or more functions or applications for such entities via, or using, channels for such entities that enable, facilitate, or permit peer-to-peer or direct communication between entities for transactions or messages.

Background Art

[0002] In this document, the term "blockchain" is used to include all forms of electronic computer-based distributed ledgers, including consensus-based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, public and private blockchains, and variations thereof. The most well-known use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and for purposes of explanation, this specification may refer to Bitcoin, but the disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols associated with any type of digital asset or representation of a digital asset are within the scope of the disclosure. The terms "client", "entity", "node", "user", "sender", "receiver", "payer", "recipient" may refer in this specification to computing resources or processor-based resources. The term "Bitcoin" is used in this specification to include any version or variation derived from or based on the Bitcoin protocol. The term "digital asset" may refer to any transferable asset such as a cryptocurrency, a token representing at least a portion of an asset, a smart contract, a license, i.e., a software license, or a DRM contract for media content. Throughout this document, the term "digital asset" may be used to represent a commodity that may be associated with value, and it will be understood that a commodity may be transferred or provided as payment in a transaction from one entity to another.

[0003] A blockchain is a peer-to-peer electronic ledger, implemented as a computer-based decentralized distributed system consisting of blocks, which consist of transactions. Each transaction is a data structure that encodes the transfer of digital asset management rights among participants in the blockchain system and includes at least one input and at least one output. Since each block contains the hash of the previous block, the blocks are linked together to create a permanent and immutable record of all transactions written to the blockchain from the beginning of the blockchain. Transactions include a small program known as a script that specifies how the outputs of the transaction can be accessed by whom, and the script is embedded into the inputs and outputs of the transaction. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, the transaction must be "validated". Network nodes (miners) perform operations to ensure that each transaction is valid and that fraudulent transactions are rejected from the network. The software client installed on the nodes that perform this validation acts on unspent transaction outputs (UTXOs) by executing locking scripts and unlocking scripts. If the execution of the locking script and unlocking script is evaluated as TRUE, the transaction is valid and the transaction is then written to the blockchain. Thus, for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction, and if the validity of the transaction is confirmed, the node relays it to other nodes in the network, ii) be added to a new block constructed by the miner, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] It will be understood that the nature of the work performed by miners depends on the type of consensus mechanism used to maintain the blockchain. While proof of work (PoW) is associated with the original Bitcoin protocol, it will be understood that other consensus mechanisms such as proof of stake (PoS), delegated proof of stake (DPoS), proof of capacity (PoC), proof of elapsed time (PoET), proof of authority (PoA) may be used. Different consensus mechanisms differ in how mining is distributed among nodes, and the probability of successfully mining a block depends on, for example, the miner's hash power (PoW), the amount of cryptocurrency held by the miner (PoS), the amount of cryptocurrency staked with the delegate miner (DPoS), the miner's ability to store a predetermined solution to the cryptographic puzzle (PoC), the waiting time randomly assigned to the miner (PoET), etc. Usually, miners are given an incentive or reward for mining blocks. The Bitcoin blockchain, for example, rewards miners with newly issued cryptocurrency (Bitcoin) and fees associated with transactions in the block (transaction fees). In the Bitcoin blockchain, the amount of cryptocurrency issued decays over time and the incentive will eventually be only the transaction fees. Thus, it will be understood that the handling of transaction fees is part of the mechanism behind committing data to a public blockchain such as the Bitcoin blockchain.

[0006] As mentioned previously, each transaction within a given block encodes the transfer of management rights of digital assets among participants in the blockchain system. The digital assets do not necessarily correspond to cryptocurrencies. For example, the digital assets may relate to digital representations such as documents, images, physical objects, etc. Payments of cryptocurrencies and / or transaction fees to miners may simply serve as an incentive for maintaining the validity of the blockchain by performing the necessary work. There may be cases where the cryptocurrency associated with the blockchain serves as security for the miners, and the blockchain itself serves as a ledger for transactions mainly related to digital assets other than cryptocurrencies. In some cases, the transfer of cryptocurrencies among participants may be processed by entities different from and / or unrelated to the entity using the blockchain to maintain the transaction ledger.

[0007] When stored on the blockchain as UTXOs, the user can transfer the management rights of the associated resources to another address associated with an input in another transaction. This transfer is usually done using a digital wallet, but this is not essential. A digital wallet can be an application (app) on a computing device such as a device, physical medium, program, desktop, laptop, or mobile device, or a remotely hosted service associated with a domain on a network such as the Internet. A digital wallet can store public and private keys and can be used to receive or consume digital assets, transfer tokens related to digital assets such as cryptocurrencies, licenses, assets, or other types of resources, and track tokens and assets associated with the user to track the ownership of resources.

[0008] Regarding the implementation of cryptocurrency usage, blockchain technology is the most widely known, but digital entrepreneurs are exploring the use of both the cryptographic security system underlying Bitcoin and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes not limited to the world of cryptocurrency. Such a solution could utilize the benefits of the blockchain (such as permanent and tamper-proof records of events, decentralized processing, etc.) while having a wider range of applications.

[0009] One current area of research is the use of the blockchain for the implementation of "smart contracts." These are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that have rules for processing inputs to produce results, and thereby actions can be executed according to those results. Another area of interest related to the blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Items that may be confidential or sensitive can be represented by tokens that have no recognizable meaning or value. Thus, the tokens become identifiers that enable real-world items to be referenced from the blockchain.

[0010] The examples, applications, and / or scenarios mentioned above utilize the advantages of blockchain to provide a permanent and tamper-proof record of events, while a client, client entity, computing device, or terminal associated with the client implements functions for managing digital assets, such as for managing encryption keys for the elliptic curve digital signature algorithm (ECDSA) used by, for example, the BSV (Bitcoin Satoshi's Vision) blockchain, in a digital wallet, etc., including or implementing software and / or hardware, or a processor / module. Additionally, there is a requirement for the client device to be able to perform blockchain transaction construction and download the BSV library in order to enable the transfer of assets or the management rights of assets to another entity or peer. Therefore, the client not only needs to include the processes for implementing such functions, but also needs to ensure that appropriate security measures are implemented for such processes.

[0011] There is a simple payment verification (SPV) mechanism. In SPV, the application requires information from the blockchain but does not run a full miner node and thus does not have a direct link to that information. Such an application of SPV enables lightweight clients to verify that a transaction is actually included in the blockchain without downloading the entire blockchain. This is advantageous, but still gives rise to the requirement for the client to execute the part of the blockchain associated with the transactions relevant to the client, because either the sender or the receiver among the peers is required to finally submit the transaction to the blockchain and determine whether the said transaction has been mined.

Prior Art Documents

Patent Documents

[0012] [Patent Document 1] U.S. Patent Application No. 16 / 384,696 [Summary of the Invention] [Problems to be Solved by the Invention]

[0013] Therefore, it is desirable to implement a secure, non - complex, user - friendly, efficient, and robust technique that enables any client, regardless of computational complexity, to access immediately and interact directly (in a peer - to - peer manner) with another participant, i.e., the counterparty or sender / receiver of the transaction associated with the client, in a simple, orderly, fast, accurate, reliable, and secure manner that is not overly burdensome computationally and functionally for the client. More specifically, it is desirable to utilize distributed ledger (blockchain) technology and the advantages of improved security, transparency, and reliability of records in such a way that any client computing device ensures that any data, event, or digital asset associated with the client can be mined instantaneously and securely or easily written to the blockchain, thereby providing a permanent, tamper - proof, and auditable record that can be created, written, updated, read, or viewed as needed without downloading or executing any part of the blockchain.

[0014] Such improved solutions have been devised. The present disclosure proposes one or more techniques to address the above technical problems by enabling all the advantages associated therewith while allowing direct or peer-to-peer communication for such clients without the need for the client to implement any processing or functionality for the blockchain, by providing an interface or function for a channel or messaging service to a method, device, and system. Data or information associated with the client may be either easily, securely, and instantaneously written to or retrieved from the blockchain, while the client is separated from the blockchain.

Means for Solving the Problems

[0015] In a first aspect, the present disclosure proposes a computer-implemented method, device, and system for implementing a channel service for messages or transactions between entities, the channel service being provided for one or more clients. The method comprises providing access to one or more functions to a given client that enable direct communication between the given client and another entity, the one or more functions including (i) channel functions or procedures related to one or more channels for transmission of data, and / or (ii) message functions or procedures related to data being transmitted using one or more channels.

[0016] In a second aspect, the present disclosure proposes a computer-implemented method, device, and system for performing addressing for channel services, where the channel services are provided for messages or transactions between entities, and the channel services are provided for one or more clients. The method comprises providing at least one service / client / minor endpoint from one entity and an associated addressing key. An addressing key associated with another entity for communication is obtained. Access is provided to one or more functions that enable direct communication between entities using a channel for sending data or messages, and communication using the channel is initiated based on the addressing key.

[0017] Throughout this specification, the term "comprise", or variations such as "includes", "comprises", or "comprising", are to be understood as implying the inclusion of the stated element, integer, step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, step, or group of elements, integers, or steps.

[0018] Here, by way of mere example and with reference to the accompanying drawings, aspects and embodiments of the present disclosure are described.

Brief Description of the Drawings

[0019]

Figure 1

Figure 1a

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Best Mode for Carrying Out the Invention

[0020] In the process of expanding the use of distributed ledger (blockchain) technology for several applications that require secure, reliable, auditable, tamper-proof, and trustworthy records of events or related transactions, conventionally, the solution for participating entities has relied on synchronizing a complete copy of the blockchain in real time and directly identifying both the transactions relevant to those applications and the embedded data from the blockchain. However, as the scope, capabilities, and security of the applications evolve and as the blockchain expands, in order to extend, fully realize, and utilize all the potential advantages associated with the blockchain, it has become apparent that a technical solution that enables participants to communicate directly and exchange messages directly for such applications is needed, and that such a solution be made available to any type of client, regardless of its computational complexity.

[0021] According to a first aspect, the present disclosure provides a computer-implemented method for implementing a channel service or function for messages or transactions between entities, the channel service being provided for one or more clients. In a first implementation of the first aspect, the method is implemented by a channel processor. In some embodiments, the channel service refers to one or more functions or procedures or application programming interfaces (APIs) described hereinbelow. In some embodiments, the channel processor may be executed on a single, remote, or distributed computing node or entity that can be accessed by one or more computing devices, or a server, or one or more clients via a wired or wireless communication network, and may be a cloud-based software solution. In some embodiments, the client may be an entity, a user terminal / device, or a computing device or system having one or more processors. In some embodiments, the client may be associated with a digital wallet that enables the client to manage one or more digital assets such as cryptocurrencies and tokens. In some embodiments, the channel service may be provided to a given client among one or more clients via the digital wallet. However, it should be understood that client entities without a separate application for the digital wallet or digital assets are also within the scope of the present disclosure. In some embodiments, particularly for clients that are computationally complex, the channel processor implementing the channel service can be integrated into or be part of the client entity. In this case, the channel processor may be implemented as a module within the client terminal that enables the channel service function for the client. In some embodiments, other clients or entities may also be served by the channel processor.

[0022] The method according to the first aspect includes receiving a request from a given client among one or more clients, the request being related to a channel service. In some embodiments, the request can be sent via a network such as the Internet. In some embodiments, the client can thus communicate with the channel service via a known Internet communication protocol. In some embodiments, the request relates to a request for registration of a given client with a channel service provider or a processor. The method then includes creating an account for the given client, the account having an account identifier unique to the given client and an access key unique to the account identifier. The identified account may be provided by the channel service or the client. Together, these constitute a certificate of the account of the given client, similar to a client ID and PIN or password pair. In other embodiments, these certificates may also be based on an asymmetric encryption key pair including a private key and a public key associated with the given client.

[0023] Once registered, the method includes providing the given client with access to one or more functions that enable direct communication between the given client and another entity, the one or more functions including channel functions or procedures related to one or more channels for data transmission and / or message functions or procedures related to data being transmitted using one or more channels. In some embodiments, the one or more channels enable a direct or peer-to-peer communication path or session between entities for the transfer of messages or data. In most embodiments, there are only two entities for each channel. However, in some limited situations, a third entity may also be given access to the same channel.

[0024] In this first implementation form, since one or more functions are in the form of an interface or an access point is provided for the client, one entity for the channel is the client, and the other is another device or entity or user terminal with which the client desires to communicate directly. In most embodiments, the channel enables full-duplex, i.e., two-way communication, between the client and the other entity. In some embodiments, the communication may be permitted in only one direction, i.e., the client may only desire to send a message or receive a message from the other entity.

[0025] Advantageously, using the first aspect, there is no need for a client to implement BSV, Bitcoin, blockchain knowledge, ECDSA, or other encryption key management libraries specific to the blockchain, or transaction construction software, etc. for peer-to-peer transactions. A client using one or more processing resources or user terminals simply registers to use the channel service via known authentication techniques such as password-protected authorization or standard public key infrastructure (PKI) for verifying the identity of the client for account registration purposes. When one or more functions from the channel service are received, the client can simply communicate with other entities using standard communication / transport protocols, i.e., Internet protocols such as the Hypertext Transfer Protocol (HTTP), Transmission Control Protocol (TCP), or the like. For client entities associated with a certain enterprise, such as a merchant, or representing a certain organization, such a client may have a number of other entities (customers) that conduct transactions with the client regarding several goods. Thus, in such a scenario, it would be highly beneficial to be separated or decoupled from implementing any functionality related to the blockchain that maintains a record of all such transactions while using a channel for communication with one or more customers. By providing channel functions as well as message functions, such a client has the ability to utilize a specific channel for a specific customer regarding a specific transaction (such as a specific invoice or a query for a certain good).

[0026] In some embodiments, a given channel is associated with a specific channel identifier. The same client can have several separate channels, each with a unique identifier. In some embodiments, a given channel is for communicating with another entity in relation to data associated with a specific type or topic, and the data associated with each topic in the channel is, or is included in, one or more messages or transactions. Advantageously, having a specific channel for a specific topic ensures greater clarity, reliability, and flexibility for the client, especially in the case of a client such as a merchant entity that may have several topics (such as transaction numbers or invoices) that need to be tracked or processed separately.

[0027] Advantageously, the use of the channel enables the asynchronous processing of each request or message within a given channel. This enables a seamless, accurate, discontinuous or delayed processing flow for the messages in the channel, since the channel is specific to a given topic and thus the order as well as the messages are always clear. This can be particularly useful in implementation forms or situations where a response from another entity (or client) is required to further continue a transaction, but the client or the other entity may not be operational, may not be online, or may not be able to provide such a response immediately. Thus, the above techniques enable requests to be reliably delivered and processed correctly in order using the channel even when the channel participants are offline or unable to respond, since the messages still exist in the channel when the participants come online or connect to the network next, so that the participants can access the messages in the channel. Further, no matter how many other messages may be provided in the channel, those messages are accessible to other entities in the order of delivery. Thus, despite delays or interruptions in processing requests, the processing of the messages in the channel is completed accurately and seamlessly as if there were no delays at all. In some embodiments, to preserve data integrity, there may be one or more rules associated with a particular channel associated with a particular topic when the participants are offline or online, for example, (i) messages should be responded to in the order of arrival to ensure no gaps in transmission, or (ii) the channel cannot be completed until all messages have been responded to.

[0028] In some embodiments, the client is the owner of one or more channels, which are channels based on one or more functions provided by the channel service. In some embodiments, the one or more functions are application programming interfaces (APIs) issued or provided for a given client, the API including a channel API for one or more channels and a message API for data, i.e., messages regarding topics associated with each or a given channel. The API may be understood as an endpoint, interface, or set of functions and procedures that enables the creation or management of an application for an entity such as a client to access the functions or data of the application or other services. In this case, it is to implement channel functions as well as message functions.

[0029] In some embodiments, the method further comprises issuing one or more access tokens for a given channel among one or more channels for the client, wherein the tokens are configured for secure communication with another entity. The one or more access tokens are related to a given channel or even to one or more messages within a given channel. In some embodiments, the access token is an API token specific to a given channel or a given message. The access token, and particularly the API token, may in some embodiments be a unique identifier of an entity or application that requests access to a service or channel. In some embodiments, the access token may be regarded as a unique authentication certificate assigned to an individual client account, and may be as fine-grained as an individual channel or an individual message within each channel. In some embodiments, the access tokens may be such that the client can provide them to other entities for each of those channels for authentication. In this embodiment, the access tokens may be generated or provided by the client or the channel service for one or more other entities each having a different channel.

[0030] In some embodiments, the channel processor is associated with an HTTP API endpoint, and requests from a given client are received based on an HTTP transmission protocol format such as HTTP, HTTP Secure (HTTPS). In some embodiments of the first aspect, the received request from the client is an HTTP GET or HTTP POST or HTTP PUT or HTTP PATCH request that includes or is associated with a client identifier unique to the given client, and, if there is a specific channel for the client, the channel identifier.

[0031] Advantageously, the channel processor API enables a web-based interaction interface, i.e., in some embodiments, the channel processor API may be implemented as a web service for one or more clients such that communication may occur over the Internet using standard Internet communication protocols for web-based services. For example, in some embodiments, HTTP messages or requests in an application level between peers or in a layer between a client and a channel service may be sent and received based on any standard Internet-based transport layer protocol. References herein to the HTTP transmission protocol, or to an HTTP API, also encompass all standard Internet communication protocols such as TCP / IP, UDP, HTTPS, etc. In some embodiments, the channel processor is implemented as a Representational State Transfer (REST) endpoint.

[0032] In embodiments where there may be more than one channel processor to provide channel services for one or more clients, i.e., there may be distributed channel processors or web servers associated with the same channel service, the method of the first aspect further comprises receiving a request from a client in an HTTP transmission protocol format, converting the received request into a Remote Procedure Call (RPC) format, and providing an Application Programming Interface (API) converter for performing the step of sending the RPC request to a given processor among a plurality of processors configured to execute the received request. In the reverse flow path, this embodiment includes receiving a related response from a given channel processor in RPC format and converting each response to be sent to the client using HTTP or a similar transmission protocol.

[0033] This is advantageous because it enables a client to communicate requests associated with a blockchain via a simple HTTP-based protocol using a web-based platform API, while also seamlessly providing interoperability with any node or server that implements the service described above but does not communicate using the Internet protocol communication standard for web services. The API converter implemented in this embodiment is not limited to the conversion from HTTPS to RPC and vice versa. In the reverse flow path, the method of the first aspect also includes receiving responses from respective processors in RPC format and, accordingly, converting each response using HTTP for transmission to the client. Thus, advantageously, implementing the interface proposed by the channel processor enables seamless communication where the client and the channel processor use different wireless data communication protocols and mechanisms.

[0034] In some embodiments, the account identifier assigned or provided to a client is an alias provided for a given client. Advantageously, there already exists a mechanism such that a memorable and more user-friendly alias is used instead of a complex public address for one or more client entities to make client identification as well as addressing easier. Such a solution is proposed in U.S. Patent Application No. 16 / 384696 in the name of nChain Holdings Limited. These documents describe an alias-based payment service and related protocols, called the bsvalias payment service, in which an alias is used instead of a client entity's public address for destination addressing. An alias in such a system is typically associated with the domain name of the sending / receiving client entity and may be a URI or an email address. Thus, as long as the sender or entity recognizes or is provided with the alias, this is sufficient for the bsvalias payment system or another alias-based addressing mechanism. Messages may be sent to a client's alias using instructions provided in a machine-readable resource, such as a JavaScript Object Notation (JSON) document, stored at a well-known URI or location for bsvalias or other payment services. In some embodiments of the present disclosure, one or more of a plurality of clients may have an alias such as the above to identify each other entity for peer-to-peer transactions, whether or not they are associated with a link to a blockchain.

[0035] In some embodiments of the first aspect, when a client is registered with a channel service and provided with an account certificate and one or more functions or APIs associated with the channel service, the channel processor may also provide one or more functions or APIs specific to the channel. In this case, the method includes receiving a request from a given client, the request being associated with a channel for the client account. The request may include access or functionality associated with, for example, one or more of the following. - A request to enumerate one or more channels related to an account for a given client - A request to create a channel for an account - A request to delete a specified channel - A request to modify properties and / or permissions associated with a specified channel - A request to generate a channel access token for a specified channel - A request to revoke a channel access token for a specified channel

[0036] In the above embodiment, the method of the first aspect comprises the step of verifying the validity of the client based on the client account identifier, which may be based on a record corresponding to the client account identifier and the access key that is stored or assigned during account registration. Such a record may be associated with the channel processor. Then, based on the success of the client validity verification, the method further includes, either additionally or optionally, the step of determining whether a request received from the client is valid based on the channel identifier. This may involve, for example, verifying whether the channel is active based on the channel API provided for the client or based on one or more settings or permissions included in each record. In some embodiments, attributes or settings may indicate whether a given client is allowed access to all or part of the requested services for the channel. For example, one or more levels of permissions associated with the client identifier may be provided in the attributes or settings. For example, a given client may be allowed to request services to create a channel and send / receive messages on the channel, but may not be allowed to modify, delete, or end messages in the channel. On the other hand, another client may have permissions for all of the above actions related to one or more services for the channel. In another example, a request to create another channel for an existing topic, such as an existing invoice number, may be rejected, which advantageously may prevent the creation of fraudulent messages or channels by impostors or malicious participants.

[0037] In some embodiments, additional verification may be made to confirm the integrity of data or messages in the channel, such as based on a checksum or hash value that may be further stored in each message being transmitted or received in the channel or a set number of messages. This ensures that malicious participants do not gain access to messages or data in the channel and tamper with them.

[0038] In some embodiments, the step of verifying the identity of a given client may be based on a digital signature associated with the client. An encryption key pair including a private key and a public key (or public address) associated with each client may be used to verify that requests made to the service actually originate from a given client, i.e., data signed with the private key can only be restored or verified as valid by using the corresponding public key. When verification is based on a digital signature, standard public key infrastructure (PKI) techniques may be used and implemented.

[0039] Subsequently, based on a determination that the account identifier and access key for a given client are valid and based on a determination that the request is valid, the method includes the step of processing the request for the channel and includes the step of sending a response to the given client, the response including access to one or more channel functions related to the request.

[0040] Similar to the above-described channel functions for a channel for a client account, when a request associated with one or more messages in a given channel is received by a client, one or more message functions or message APIs may also be provided to the client using a similar process. These may include providing one or more APIs for the following requests associated with the message. - Request to test new messages in a given channel - Request to retrieve messages in a given channel - Request to mark or identify read or unread messages in a given channel - Request to write messages in a given channel

[0041] If there is a Message API in the responses provided, this is provided to the client to control or manage transfers, rules, permissions for specific messages in the channel or for any of the messages. In some embodiments, such an API may be provided such that the client can share it with the channel's counterpart, i.e., the other entity.

[0042] In some embodiments, the channel or message functions provided in the response include a JavaScript Object Notation (JSON)-over-Hyper Text Transfer Protocol (HTTP) API for the account to enable access, creation, and / or management of one or more messages by the client or other entity.

[0043] Advantageously, by providing access to functions such as APIs or tokens that are specific to a given channel for a client or specific to one or more messages within a given channel, the control and management rights of the channel and messages are ensured to remain with the client when communicating directly or peer-to-peer with another entity. In some embodiments, when an API or function is provided for a channel, the control rights may not need to be requested for another message, but may need to be requested for a different channel. Also, this ensures that constraints on a particular channel or message can be monitored. For example, if multiple payment reminders in the form of messages or reminders are sent and ignored by another entity, requests associated with additional channels for that other entity, or requests to delete or mark the message as unread, may be rejected.

[0044] In some embodiments, a channel service library including one or more modules to assist with channel functions and / or message functions received from a channel processor for an account associated with a given client may be provided by the channel processor for the client.

[0045] In a second implementation of the first aspect of the present disclosure, a computer-implemented method for accessing a channel service for a message or transaction is provided, which is implemented by one or more processors of a given client among one or more clients. The second implementation is similar to the first implementation and is associated with similar advantages. Note that in some embodiments, the client for the channel service may also be one or more miner nodes or entities associated with or running full nodes of the blockchain. This method is particularly advantageous for clients who wish to communicate directly with another entity that has no links associated with the blockchain, although this does not preclude other full or partial (SPV) wallet implementations where miner nodes or clients associated with them also use such channel services for peer-to-peer communication. For example, an important and useful application example could be that such a miner mode uses the channel to directly send a proof of mining or inclusion proof to another participant who may be a channel processor or another entity associated with the blockchain transaction. In this embodiment, when a transaction is submitted for mining by a miner (which can be done by either the client or the channel service), the miner can use the channel to submit an inclusion proof to the transaction submitter based on the channel function received from the channel processor or the client. Advantageously, this means that neither the client nor the channel processor (or any submitting participant) needs to perform any confirmation of the execution of any part of the blockchain to verify the transaction submission, since such proof is now delivered directly to the submitter via the channel.This is advantageous because no entity needs to perform blockchain verification to access the transaction anymore, which helps with resource scalability and optimization for peer-to-peer applications to be written to the blockchain.

[0046] The method comprises a step of sending a request related to a channel service, wherein the channel service is implemented by a channel processor, and, in response thereto, a step of obtaining an account certificate of an account created for a given client, wherein the account certificate includes an account identifier and an access key unique to the account identifier. Next, the method implemented on the client includes a step of obtaining access to one or more functions that enable direct communication between a given client and another entity. As in a first implementation form, the one or more functions include channel functions or procedures related to one or more channels for data transmission and / or message functions or procedures related to data being transmitted using one or more channels.

[0047] In some embodiments, the method implemented by the client also includes, as discussed above, sending requests related to channels or messages for a given client's account such that a particular API can be delivered to the client. The channel API received by the client in the response of the channel processor is advantageously for enabling the creation and / or management of one or more channels. In some embodiments, the received response includes an access token, such as a channel API token for each channel function as mentioned above. In the case of message functions, the message API issued by the channel processor for a client account is advantageously such that a given client and one or more other entities can exchange messages and / or read data from and / or write data to a given channel. In some embodiments, the received response includes an access token, such as a message API token for each message function.

[0048] In some embodiments of the first aspect, for a client to interact with a counterpart or another entity using a channel service and one or more channels, as well as using a message function or API obtained from a channel processor, the method includes the step of identifying another entity with which a communication exchange is to be performed. This may be by using either an access point or an alias that is known about the other entity or provided by the other entity. Then, using one or more channel functions received from the channel processor, a channel for communication is created and one or more access tokens associated with the channel are sent to the other entity. This advantageously enables a secure, reliable, and accurate setup of the channel with another entity, which may be a customer of the merchant client. The method then includes the steps of using one or more message functions for the channel received from the channel processor, writing at least one message related to the transaction to the channel, and sending one or more access tokens associated with the one or more messages to the other entity. This advantageously enables the authentication of any responses to be ensured via the access tokens. The method includes the step of receiving at least one response message related to the transaction in the channel.

[0049] In response to the completion of a communication exchange, which may be indicated upon receipt of confirmation of payment of a digital asset, i.e., similar to a remittance notice by the other entity or confirmation of funds received by the client, then such a completed transaction associated with the channel is prepared for submission to the blockchain. In some embodiments, this is sent to a channel processor, which can then submit the transaction on behalf of the client. Advantageously, this relieves any participant (client or other entity) in a peer-to-peer transaction of the responsibility of submitting the completed transaction to the blockchain. This is done by the channel processor and may then be mined by one or more miner nodes associated with the blockchain. Thus, the client does not need to perform any functions associated with the blockchain, nor even run an SPV wallet or any other form of digital wallet. In some embodiments, if the client, or actually the other entity, has a function such that it can submit the transaction, the submission can be done by said client or other entity.

[0050] In a third implementation of the first aspect, the present disclosure provides a computer-implemented method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with a miner among a plurality of miners, the plurality of miners being communicatively coupled to at least one channel processor that implements a channel service for at least one client. As mentioned above, the miner node may also access a channel service to facilitate peer-to-peer communication with one or more other entities. This may apply whether or not the miner node is a client of the channel service, as long as the miner node receives a channel API or message API and / or evaluates a token associated with the channel from another entity that requires direct communication with the miner. This may be particularly advantageous for many blockchain-related applications, as it allows the miner to use the channel to directly send a Merkle tree inclusion proof for a transaction submitted to the blockchain to another entity. This is useful because it means that neither a client such as a merchant, or a customer or indeed any other entity such as a channel service, needs to search the blockchain to find such a transaction. Advantageously, once mined, the inclusion proof can be sent directly using the channel to either the channel processor or indeed the client or other entity, i.e., any entity that submits a blockchain transaction for mining.

[0051] Of course, mining can also be performed using the channel service without the miner for a given transaction being a client registered with the channel service. In this case, the channel processor, or actually the entity submitting the transaction, may simply create a channel for the miner inclusion proof to be received using the channel service, based on the channel functions and message functions already provided. Then the miner becomes the other entity in such a channel (and the client or channel API is the first entity), and can simply receive the message API and access the tokens required via the channel.

[0052] A second aspect of the present disclosure relates to providing secure addressing and encryption for channels used for peer-to-peer communication. Aspects and embodiments associated with the second aspect may be implemented separately for one or more peer-to-peer channels implemented between entities. It can be used in combination with the embodiments and implementations discussed above, i.e., also for the channel service of the first aspect. The following embodiments of the second aspect are discussed in relation to the channel service as referred to in the first aspect, but it is understood that it is not so limited.

[0053] In a first implementation of the second aspect, the present disclosure provides a method for performing addressing for channel services, where the channel services are provided for messages or transactions and the channel services are provided for one or more clients. The method is implemented by a channel processor and includes receiving a request from a given client among a plurality of clients, the request being related to a channel service. Next, a determination of the validity of an account identifier and an access key related to the given client is confirmed. This confirmation may be performed as discussed above with respect to the first aspect, based on a stored certificate or in fact based on PKI techniques. The method includes providing a service endpoint for the client. In some embodiments, this may be a service API or an HTTP endpoint for the channel service. The method includes providing at least one service addressing key associated with the channel service and obtaining at least one client addressing key associated with the client. The addressing key may be a static key, or a short-term key, or both, and may be used to authenticate the identity of each endpoint. Next, based on the received request, the method includes providing the given client with access to one or more functions that enable direct communication between the given client and another channel for sending data or messages, i.e., a configured communication path or session or data tunnel, and communication using the channel may be initiated based on the service and / or client addressing keys.

[0054] As discussed in connection with the first aspect, the minor node can also use the channel service as a client, in which case, in the second aspect, the above method is applied to the minor, which is also a client, in the same way. For the sake of brevity, the endpoint and key associated with the minor are referred to as the minor addressing key and the minor endpoint, because the second aspect may require both the client and the minor when mining the completed transactions (when the client does not have a link to the blockchain).

[0055] Advantageously, the method of the second aspect of the present disclosure enables one or more processors associated with the client to sign up for and access a channel service, such as a web service, without the requirement to write data to or access data from the blockchain, by implementing the channel service to provide endpoints such as API endpoints, and addressing keys such as static and / or dynamic / short-term keys. These keys further enable an authentication or handshake procedure to be initiated before the transfer of a message via the channel, thereby verifying the identity of the participants for which the channel is created and ensuring that all communications via the channel occur only between two authenticated entities, improving security.

[0056] In some embodiments, the handshake procedure includes obtaining a result or pattern of the handshake. Based on the result or pattern of the handshake, obtain a shared secret key such that direct communication using the channel is encrypted based on the shared secret key. This is further advantageous because the shared secret key is based on the identification information of the two participants or entities for which the channel is initiated, i.e., the addressing key. Thus, only each legitimate authenticated participant is able to decrypt the encrypted ciphertext, thereby enhancing reliability as well as privacy and obtaining resistance to spoofing attempts by malicious participants. In this case, the participant is a client such that the communication between the channel service and another participant, i.e., the client and the channel processor, is via the channel.

[0057] The second implementation form of the second aspect relates to a method for performing addressing for a channel using a channel service for a message or transaction, the channel service being provided for one or more clients, and the method being performed by one or more processors of a given client among one or more clients. As mentioned above, the minor node may also be a client for utilizing the channel service to facilitate peer-to-peer communication with other nodes. The method includes a step of sending a request related to the channel service performed by the channel processor, and a step of obtaining a service endpoint associated with the channel service. The method includes a step of obtaining at least one service addressing key associated with the channel service, and a step of providing at least one client addressing key associated with a given client. In the case of a miner, this may be a miner addressing key. The method then includes a step of obtaining access to one or more functions that enable direct communication between a given client and another entity using the channel for sending data or messages, and the communication using the channel is initiated based on the service and / or client / miner addressing keys. Advantageously, this enables the client and the service endpoint to securely verify each other's identities. The advantages discussed for the first implementation form equally apply.

[0058] When a channel with another entity is to be established using a function provided by the channel processor, the second aspect includes a step of identifying another entity with which a communication exchange is to be performed when implemented by a client. This may be based on a client identifier or alias or any other known means. Then, using one or more functions received from the channel processor, the method includes a step of creating a channel for the communication exchange. The method then uses the created channel to providing a client endpoint, obtaining at least one third - party addressing key associated with another entity, providing at least one client addressing key associated with a given client, exchanging one or more handshake messages using a channel based on the client and third - party addressing keys, further comprising performing steps of obtaining a shared secret key based on a handshake result or pattern, said direct communication with other entities using the channel is encrypted based on the shared secret key.

[0059] This advantageously ensures that all communications are authenticated and secure based on keys associated with the client as well as other entities. Further, this addressing and authentication scheme, as well as the provision of end - to - end encryption, is also compatible with the known Noise protocol framework.

[0060] In some embodiments, the endpoints for the service, client, and / or miner are HTTP API endpoints, and said endpoints are delivered to the client using HTTP Secure (HTTPS). This advantageously ensures that the endpoints are verifiable through a chain of certificates leading to a known and trusted Certificate Authority (CA). In some embodiments, the endpoint may be a Universal Resource Locator (URL) included in a response to a request for one or more functions associated with a channel service. By the above, advantageously, the identity of the other participant can be known and verified by at least one participant for the channel using PKI or other mechanisms.

[0061] In some embodiments, the endpoint may be an alias associated with each entity of the channel, the alias being specific to the channel processor and provided by an alias-based addressing service, the addressing service having machine-readable resources accessible from a defined or known location, the machine-readable resources including one or more capabilities related to the channel processor. The alias may be known to or provided to one or more clients / miners, and the alias is associated with an asymmetric cryptographic key pair for authentication.

[0062] Advantageously, by the above, the identities of both participants can be known and verified by both participants using PKI or other mechanisms.

[0063] Aspects of the present disclosure also include a computing device comprising a processor and a memory, the memory including executable instructions that, as a result of execution by the processor, cause the device to execute a computer-implemented method as discussed above, the computing device being related to a channel.

[0064] Aspects of the present disclosure also include a computing device comprising a processor and a memory, the memory including executable instructions that, as a result of execution by the processor, cause the device to execute a computer-implemented method as discussed above, the computing device being related to a client.

[0065] Aspects of the present disclosure also include a computing device comprising a processor and a memory, the memory including executable instructions that, as a result of execution by the processor, cause the device to execute a computer-implemented method as discussed above, the computing device being related to a miner.

[0066] Aspects of the present disclosure also include a system comprising at least one channel processor communicatively coupled to at least one client and at least one miner via a communication network, the at least one channel processor implementing channel services for one or more clients as discussed above.

[0067] Aspects of the present disclosure also include a computer-readable storage medium storing executable instructions that, as a result of being executed by a processor of a computer, cause the computer to execute any of the methods of the aspects and embodiments described above.

[0068] Here, some particular embodiments are illustrated by way of example with reference to the accompanying drawings, with like reference numerals referring to like features.

[0069] The aspects and embodiments described above in connection with the present disclosure provide such a solution and implement a secure, off-chain, (peer-to-peer / direct) application messaging mechanism between participants, which implements and manages channel services for such applications and use cases in a scalable, secure, and accurate manner that is simple for entities participating in the direct communication. The aspects and embodiments provide a mechanism by which participants can communicate securely even in cases where one of the participants is temporarily offline.

[0070] There are well-known systems and mechanisms for message delivery between entities. These are briefly discussed below.

[0071] Electronic mail (email):

[0072] As one of the oldest and most popular messaging applications used on the modern Internet, electronic mail provides many obvious solutions including the following. · Addressing, client · Connectivity (IMAP for push, or Exchange / ActiveSync) · Synchronization (IMAP or Exchange / ActiveSync) · Account management - Based on operator requirements rather than client requirements · Storage · Security - For authentication purposes (not related within the application)

[0073] Some of the drawbacks, which mean there is no proof that email is scalable enough to be used with applications associated with blockchain, are as follows. · There is no alternative, more flexible and secure addressing (only email addresses), no more reliable and separated structure based on topics for the other party. · Many applications, especially those interoperable with blockchain, use machine-readable ones, i.e., JSON-over-HTTP, but email is a custom protocol and many secure private blockchain networks as well as public blockchain networks do not allow email sending, so the scope of technology is not flexible or is limited.

[0074] Instant messengers:

[0075] Popular, secure, scalable, modern instant messengers such as WhatsApp, Telegram, and Signal are useful for some peer-to-peer applications. However, all of these are operated by central authorities and have the power to reject services to anyone for any reason. This is incompatible with the essence at the core of all public blockchains.

[0076] Message brokers:

[0077] A message broker is a hardware appliance or software middleware that supports various messaging paradigms. These products, sometimes called Enterprise Service Bus (ESB) or Integration Bus, provide publish-subscribe delivery messaging to enterprises. They generally provide one or more of the following useful mechanisms. · Addressing · Connectivity · Account management · Storage, quota · Security

[0078] However, such solutions are proprietary and often need to be deployed by a single entity within a single organization. Thus, they are not suitable for distributed ledger technologies, especially for public blockchains.

[0079] As discussed above, the first and second aspects and embodiments of the present disclosure propose to provide a channel service for implementing a messaging function through the use of separate identifiable channels, i.e., communication paths or sessions provided for peer-to-peer communication for many applications. This can be implemented across several applications and use cases that require entities to exchange messages without the participating entities having any links or downloading any parts of the blockchain. Some examples of these use cases are described in the "Use Cases" section of this document.

[0080] As discussed above, each channel has an owner, which is a client registered with the channel service, and the client obtains channel capabilities in the form of an API to configure channel read / write permissions. These permissions can provide, for example, separate read / write permissions for the channel, and individual messages, by not allowing unauthenticated connections and issuing a cancellable access token, i.e., an API key or token. As discussed, the channel operates an application-level end-to-end encryption protocol using a known transport protocol, which protects the messages transported therein.

[0081] First Aspect - Implementation of Channel Service

[0082] A channel processor for providing a channel service as described above for the first aspect may be a Platform as a Service (PaaS) and Software as a service (SaaS) that advantageously enables end-to-end (peer-to-peer) communication or messaging services for one or more clients.

[0083] As mentioned above, since the API can be implemented as a web service, requests may be received via the access point or API for the channel processor, via an Internet communication protocol from the client, or using it, although the method is not so limited. For example, an alias associated with the channel processor may also be used, i.e., based on the bsvalias addressing protocol mentioned above. FIG. 1 shows a computer-implemented method for providing a channel service for facilitating peer-to-peer communication for one or more clients, with respect to the first aspect of the present disclosure. The method of FIG. 1 is implemented by a channel processor, which may include one or more channel processors.

[0084] Step 102 relates to a registration request for a channel service from a client. Step 102 indicates receiving a request from a given client among a plurality of clients. As mentioned above, the client may be a client having no functions for interacting with the blockchain, or a client having limited functions such as an SPV wallet, or even a miner node that executes a complete copy of the blockchain. Since the channel processor is associated with an API endpoint identified by a URI or an alias, in this example, the request from a given client may be based on a standard Internet protocol such as the Hypertext Transfer Protocol (HTTP) transmission protocol format. In some embodiments, the request may include an identifier of the client as well as an identifier of the requested service.

[0085] Step 104 indicates creating an account for the client, and this account is associated with an access key for the channel service, which may be an account certificate such as a unique client identifier or account identifier, and may also be a password or PIN, or even one or more encryption keys associated with the client. In some cases, a record may be created for a given client based on the account certificate at the time of registration.

[0086] An exemplary schema associated with account registration may be as follows. Openapi: 3.0.0 … components: securitySchemes: basicAuth: # Name of the scheme type: http scheme: basic security --basicAuth:[]

[0087] Step 106 shows providing access to channel functions as well as message functions in order to enable a client to perform peer-to-peer direct communication with any other entity using the channel. The channel may be created using the channel function, and the data flow within the channel may be based on the provided message function. As discussed above, these may be the channel API or the message API. The channel API secured by the account certificate enables the account holder to create and manage the channel. The messaging API enables the account holder and the counterparty, i.e., the other entity or third party for which the channel is created, or even another entity such as an administrator (if the client is an organization), to read from or write to the channel.

[0088] Accordingly, the channel service identifier identifies the customer / user via the account certificate from step 104 and / or via the channel for each account having its own identifier. The message stream is logically aligned to the channel, whether it is a one-shot stream or a long-lived stream, and the channel is owned by the client account which is a single account. Once set up, the client can identify itself to the channel service via the account certificate.

[0089] In some embodiments, if the channel owner requires authentication for its API, the channel functions and the message functions may also include the functionality of the account holder (client) to generate an API token to be passed to a third party (the message exchange partner with which the client desires to communicate directly). Accordingly, the channel API is optional and may be secured by the API token.

[0090] Figure 1a is a schematic representation of an implementation form of a channel service according to a first aspect. Figure 1a shows channel services provided by a plurality of n, where n > 1, and several channel processors implement channel services for a plurality of n clients, and each client communicates with one or a plurality of n counterparts respectively. As shown, each client may have several different channels, each of which is for a specific topic among n topics.

[0091] Figure 2 shows a computer-implemented method for providing an API or function associated with a request related to a specific channel, or a message associated with a given client account, with respect to the first aspect of the present disclosure.

[0092] Step 202 indicates receiving a request associated with a channel from a given client. This request may be related to a channel, that is, it may be a request that is either identified by a unique channel ID or related to a new channel for a client account. In some embodiments, this request may be related to a specific message, as seen in Figure 1a, that is, it may be related to topic 1 or 2 or n in a specific channel. The request includes the client's account identifier and may be made following the submission of the account certificate in step 104 of Figure 1.

[0093] In step 204, the identity of the client is verified to see if the client is a valid client registered to use the channel service and the functions provided by the channel service. In some embodiments, this may be based on known authentication methods such as password-protected login authentication during registration. The validity check may be based on the received password matching the password in the record. In other embodiments, standard PKI techniques based on cryptography or addressing private / public key pairs may also be used to perform a validity check on the digital signature that may be present in the request received from the client in step 202. In this case, the identity of the client can be verified by checking whether the request signed by the private key can be successfully restored or validated using the public key.

[0094] If the identity of the client cannot be verified or the verification fails, in step 206, the request is not processed further.

[0095] If the client is successfully verified in step 204, the validity of the request for the service in step 208 is then verified. This step is to ensure that a given client actually has the right to use the requested service. Permissions or attributes for this may exist in the record for the client to indicate one or more types of access levels or services provided to each client. For example, a client may have permission to create channels and messages but may not have permission to modify or delete a message. Also, in some cases, the channel specified in the request may be incorrect or may not be associated with a given client and thus may be invalid.

[0096] For a requested client, if the request is found to be unacceptable or invalid, in step 210, the request is not processed further. Some examples of error messages that may be returned if an unauthorized request is made are given below.

[0097] Error code 401 The account certificate / digital signature was not valid.

[0098] Error code 402 The account certificate / digital signature is valid, but the request was not authorized. This may be due to either the account being invalid or the account holder not being the owner of the specified channel.

[0099] Error code 403 The channel, API token, or other resource was not found.

[0100] It should be understood that the embodiments for verifying the validity of the client and / or request described above are not essential for the operation of implementing the channel service of the first aspect, but are useful. In some cases, only the validity check of step 202 or step 206 may be performed. In some cases, the validity check is not performed via the channel processor, because this may be done by other means (see the second aspect mentioned above and detailed after FIG. 6).

[0101] If it is determined in step 208 that the request is valid, in step 212, along with the requested channel function and / or message function, their access token or API token is provided to the client if it is required or needed as part of the request or permission.

[0102] Some examples of specific schemas and / or formats associated with requests to channel functions and / or message functions / APIs are shown below along with an exemplary schema for the response provided by the channel processor.

[0103] 1. Channel API:

[0104] The channel API may be a JSON-over-HTTP API client account provided to the service by the channel service to create and / or manage channels for peer-to-peer communication.

[0105] In some embodiments, all API endpoints may require authentication. The specific authentication scheme may be determined according to the implementation form. Common forms include schemes such as OAuth, basic authentication, and bearer token method. As mentioned above, the channel API may optionally be secured by an API token provided and generated by the client.

[0106] As seen from steps 204 to 208, the channel API secured by the account certificate enables the account holder to create and manage channels. The following APIs may be provided.

[0107] 1.1 List Channels: Returns a list of all channels

[0108] Request Format: GET / api / account / <account-id> / channel / list Authorization: ...

[0109] Response format: 201 OK Content-type: application / json Content-length: ... { "Channel": { "id": "...", "href": "https: / / example.org / channel / <id>", "public_read": true | false, "public_write": true | false, "locked": true | false, "sequenced": true | false, "head": <sequence>, "retention": { "min_age_days": null | <number>, "max_age_days": null | <number>, "auto_prune": true | false }, "access_tokens": { "id": "...", "description": "...", "can_read": true | false, "can_write": true | false } } }

[0110] 1.2 Creating a Channel: Create a new channel owned by the account holder.

[0111] Request Format: POST / api / account / <account-id> / channel Authorization: ... Content-type: application / json Content-length: ... { "public_read": true | false, "public_write": true | false, "sequenced": true | false, "retention": { "min_age_days": null | <number>, "max_age_days": null | <number>, "auto_prune": true | false } }

[0112] Response format:

[0113] A successfully created response contains the initial access token. The account certificate of step 204, set up according to Figure 1, may be used to access the channel API, but the token may need to be used to access the messaging API. This initial access token for this purpose belongs to the account holder for the purpose of the account holder reading from and writing to the channel. 201 OK Content-type: application / json Content-length: ... { "id": "...", "href": "https: / / example.org / channel / <id>", "public_read": true | false, "public_write": true | false, "sequenced": true | false, "head": <sequence>, "retention": { "min_age_days": null | <number>, "max_age_days": null | <number>, "auto_prune": true | false }, "access_tokens": { "id": "...", "token": "...", "description": "Owner", "can_read": true , "can_write": true } }

[0114] 1.3 Deleting a Channel

[0115] Request Format: DELETE / api / account / <account-id> / channel / <channel-id> Authorization: ...

[0116] Response format: 204 No Content

[0117] 1.4 Modify the channel: Update the channel metadata and permissions

[0118] Request POST / api / account / <account-id> / channel / <channel-id> Authorization: ... Content-type: application / json Content-length: ...

[0119] Response Since this request functions like an HTTP PATCH, fields from the message body may be omitted if no changes are required. { "public_read": true | false, "public_write": true | false, "locked": true | false }

[0120] 1.5 Generate Channel API Token

[0121] Request Format: POST / api / account / <account-id> / channel / <channel-id> / api-token Authorization: ... Content-type: application / json Content-length: ... { "description": "...", "can_read": true | false, "can_write": true | false }

[0122] Response format: This is the only API call that returns the token value. If this is lost, the token should be deleted and replaced with a new token. 201 Created Content-type: application / json Content-length: ... { "id": "...", "token": "...", "description": "...", "can_read": true | false, "can_write": true | false }

[0123] 1.6 Revoke the channel API token: Create a new APT to be used when a third party accesses this channel.

[0124] Request format: DELETE / api / account / <account-id> / channel / <channel-id> / api-token / <token-id> Authorization: ...

[0125] Response format: 204 No Content

[0126] The Messaging API enables an account holder and the associated parties (other entities for the channel) to read messages from and write messages to a given channel.

[0127] 2. The following Message API may be provided as a JSON-over-HTTP API for the account holder and their parties to exchange messages.

[0128] 2.1 Test Channel for New Messages

[0129] Request format: HEAD / api / channel / <id> Authorization: <api-token>

[0130] Response format: 201 OK ETag: <max-sequence>

[0131] 2.2 Write the message to the channel

[0132] Request format: POST / api / channel / <id> Authorization: <api-token> Content-type: ... Content-length: ...

[0133] Response format: a) Approval The message has been written to the channel. 201 Created b) Sequencing failure The channel has been created in order, and the API token associated with the request is not marked as having read the latest message in the channel. Even so, if that is appropriate, the client may need to try the write again. 409 Conflict c) Message too large In embodiments where end-to-end encryption secures all messages, for example, based on the Noise Protocol, the maximum size of any single message is set to 65536 bytes. Since there should be no messages larger than this, in some embodiments it may be useful to limit the maximum size of any message written to the channel. Messages larger than this may be rejected by the channel. 413 Payload Too Large d) Storage quota exceeded In some embodiments, a quota that may be set by the service operator has been exceeded. The client request may be valid, but this time the storage service is unable to fulfill it. 507 Insufficient Storage

[0134] 2.3 Obtaining messages in a channel Returns all messages from the channel, optionally filtered as unread.

[0135] Request format: GET / api / channel / <id>[?unread=true] Authorization: <api-token> The unread query string parameter is optional.

[0136] Response format: 201 OK Content-type: application / json Content-length: ... ETag: <max-sequence> { "messages": { "sequence": <number>, "received": <unix-timestamp>, "content_type": "...", "payload": "hex / base64" } }

[0137] 2.4 Mark messages as read or unread: Flag messages as read or unread.

[0138] Request format: POST / api / channel / <id> / <sequence>[?older=true] Authorization: <api-token> Content-type: application / json Content-length: ... {"read": true | false} Optional older parameters enable the client to mark as read all messages with sequences below the supplied <sequence> path argument in a single call.

[0139] Response format: 201 OK

[0140] In step 214, in the embodiment of FIG. 2, the completed transaction may then be provided to the channel processor. This may be sent by the client or by another entity for the channel. In this embodiment, it is contemplated that the channel processor submits the transaction to the blockchain to be mined. However, as previously mentioned, the present disclosure is not so limited. It is possible for the client or other entity to submit the transaction instead.

[0141] In this embodiment, the channel processor (or submitter in other examples) may then proceed to prepare the transaction for submission and then create a channel where an inclusion proof (Merkle tree proof) is ultimately received from the miner. This channel is unique to the channel processor and the miner. The channel processor (or submitter) then submits the transaction to the miner for inclusion in a blockchain network such as the public BSV blockchain. In some embodiments, the channel processor (or submitter) may also receive a submission response from the miner.

[0142] In step 216, the channel processor receives from the miner a proof of inclusion in the blockchain via the channel created in step 214. Thus, neither the channel processor, the client, nor any other entity needs to search the blockchain for such a transaction, as the proof of inclusion is provided directly by the miner using the channel service.

[0143] The method of FIG. 3 according to the first aspect is performed by one or more processors associated with a client.

[0144] In step 302, the client prepares a request for the channel service and sends it to the channel service (channel processor), and in step 304, receives the requested account certificate associated with the account identifier and access key for the client account. In some embodiments, the client identifier includes in the request the client alias or identifier and / or the service identifier. This is similar to steps 102 and 104 of FIG. 1 for this process. The request prepared may be sent by the client using the Hypertext Transfer Protocol (HTTP) or a similar transmission protocol format. In some embodiments, it is sent to a channel processor implemented as an HTTP or REST API, and the response may also be provided to the client in the HTTP transmission protocol format.

[0145] In step 306, requests regarding a specific channel or message are sent by the client when received by the channel processor, similar to step 202 in FIG. 2. In step 308, if necessary, a response with the channel API or message API and an access token for the request is provided to the client. Examples of requests sent and responses received for the channel API and / or message API can be seen in step 212 of FIG. 2.

[0146] In step 310, the received API from the channel processor in step 308 is then used to create a channel with another entity. For example, the client may be a merchant, and the other participant may be a customer or counterpart with whom data or asset transfers such as payments of digital assets must be made for a specific invoice or purpose or goods. For this, any known transport protocol may be used over the channel, and the channel provides a direct end-to-end path for the client and the other entity, secured by the API and access token.

[0147] The received API is used to read or write a message, or perform any other function associated with the channel, and / or to send a message based on one or more access tokens associated with the channel to another entity. As mentioned above, the access token can be used to authenticate the other entity. In some embodiments, the message API is also sent to the other entity for communication over the channel.

[0148] In step 312, a response from the other entity or counterpart is received over the channel. This is possible because the other participant received all the required message APIs and access tokens in the previous step.

[0149] In step 314, in response to the completion of the communication exchange, the client sends the completed transaction to the channel processor in the embodiment of FIG. 3 for submission to the blockchain. As discussed with respect to step 214, this is also possible if the client or other participant is associated with the function for submitting the transaction. However, the client or other participant need not have any such function for using the channel service for peer-to-peer communication using the channel.

[0150] The method of FIG. 4 according to the first aspect is implemented by one or more processors associated with the miner.

[0151] As mentioned above, the miner can be a client of the channel service, in which case the processes described in FIGS. 1 to 3 apply to the miner node as well as the client. However, the miner node need not be a client in order to be able to utilize the channel provided by the channel service. For example, if the miner node is another entity for the channel, when a certain channel is sent to the miner node, the miner node can use that channel. This scenario is shown in FIG. 4.

[0152] In step 402, when the completed transaction is provided to the miner by the participant who submitted it for mining (the submitting participant may be the channel processor or a client of the channel service), the submitter can create a channel using the channel service for direct communication with the miner. In this case, as also discussed in step 310 of FIG. 3, the miner receives access to the channel from the submitter and any associated message API and access token.

[0153] In step 404, the miner proceeds to mine a transaction in a block associated with the blockchain using known techniques for mining, some of which are discussed in the background of this application.

[0154] In step 406, the miner then uses the channel in step 402 to directly send the inclusion proof of the transaction in the blockchain to the submitter, thereby eliminating the need for the submitter to execute a copy of the blockchain or search the blockchain to find the said transaction.

[0155] In some embodiments, the proof may be a Merkle tree proof. This is a known authenticated data structure organized as a tree. The hash of each data block is stored in the nodes of the base layer, or the cryptographic hash where the leaves and any internal nodes of the tree, or branch, contain the hash calculated from the hashes of its two child nodes. The Merkle root, which is the topmost node of the tree, uniquely identifies the dataset from which the tree is constructed. Thus, the Merkle tree enables an efficient inclusion proof such that the miner or prover node can send the proof along with an audit path to the submitter node or verifier node to show that a certain data block is part of the authenticated dataset. The audit path contains the node hashes necessary for the submitter to recalculate the Merkle root without having to reveal the entire dataset. In Bitcoin SV, the transactions included in a block are stored in a Merkle tree.

[0156] Second aspect: Security: Addressing and encryption

[0157] The second aspect of the present disclosure relates to providing secure addressing and security functions for channels used for peer-to-peer communication. Aspects and embodiments associated with the second aspect may be implemented separately for one or more peer-to-peer channels implemented between entities. It may be used in combination with a channel service implemented according to the first aspect of the embodiments discussed above. This is the embodiment discussed below in relation to FIGS. 5 to 7, but it will be understood that the second aspect of the present disclosure is not limited only to the channel service as described and implemented in the first aspect. The second aspect relates to ensuring the security of the peer-to-peer communication path for entities. One exemplary related use case of the second aspect is to use it together with the channel service of the first aspect.

[0158] The method of FIG. 5 relating to the second aspect is implemented by one or more processors associated with a channel processor implementing a channel service.

[0159] Step 502 shows the step of receiving, from a client, a request by the channel processor for a service associated with the channel service. This may be a minor as mentioned above. The request in this embodiment is for the entity making the request to be able to access a service for facilitating the creation or management of one or more channels or messages with a third party or another entity, as discussed in relation to the first aspect.

[0160] In step 504, the account certificate associated with the requesting client is verified as described in step 204 of FIG. 2. This is based on the assumption that the client making the request is registered with the channel service as described in FIG. 1. If client authentication is invalid, the request made in step 502 is rejected by the channel processor in step 506.

[0161] In step 508, the channel processor transmits a service endpoint for the channel service and at least one service addressing key associated with the channel service.

[0162] The service endpoint may be a Hypertext Transfer Protocol (HTTP) Application Programming Interface (API) endpoint, and the endpoint is delivered using HTTP Secure (HTTPS) and is verifiable through a chain of certificates leading to a known trusted CA. This is advantageous as it provides authentication of the channel service's identification information so that the service endpoint can be trusted as belonging to the channel service and not a malicious participant.

[0163] In some embodiments, the endpoint may be a Universal Resource Locator (URL) that was previously sent from the channel service, for example, during account setup, or included in the delivery of the channel API or message API for the client. This advantageously provides the endpoint in a message that can be associated only with the required channel service, so that the endpoint can be reliably trusted. Optionally, an HTTP authentication header value may also be included. When an asynchronous response is to be generated by the client (or another participant in the channel), a simple HTTP POST call may be used.

[0164] The object schema may be extended using the following exemplary properties. { "noise_e": "<hex encoded ephemeral public key>", "callbackUrl": "https: / / example.com / api / channel / <id>", "authorization": " <type> <credentials>" }

[0165] In other embodiments, the service endpoint may be an alias associated with a channel service such as the bsvalias service as mentioned above, where in the bsvalias service, the alias can be verified based on a machine-readable JSON resource associated with bsvalias or another addressing service.

[0166] In step 510, a client addressing key is obtained from the client. The service addressing key and / or the client addressing key may be one or more static "s" keys and / or short-term "e" keys. This is advantageous because such addressing keys are compatible with one or more known secure key exchange protocols for end-to-end encryption, such as the Noise protocol framework.

[0167] In step 512, using the addressing key, a handshake procedure is performed between two participants, in this case the channel processor and the client. In some embodiments, the handshake is based on a mechanism set up on the Noise protocol framework. Noise is a framework for cryptographic protocols based on Diffie-Hellman (DH) key exchange. The Noise protocol provides a series of highly regarded, verified, and adopted cryptographic protocols that solve all requirements except for the initial distribution of static keys. The Noise protocol framework is used to construct a scheme that solves authentication, confidentiality, and data integrity by selecting a configuration with static keys during the handshake phase.

[0168] An overview of a Noise-compliant handshake as described at http: / / www.noiseprotocol.org / noise.html is described below.

[0169] The Noise protocol starts with two participants exchanging handshake messages. During this handshake phase, the participants exchange DH public keys, execute a sequence of DH operations, and hash the DH result into a shared secret key. After the handshake phase, each participant can use this shared key to send encrypted transport messages.

[0170] The Noise framework supports handshakes where each participant has a long-term static key pair and / or a short-term key pair. The Noise handshake is described in a simple language. This language consists of tokens placed into message patterns. The message patterns are placed into handshake patterns.

[0171] A message pattern is a sequence of tokens that specify a DH public key, along with the DH operations to be performed when sending or receiving that message. A handshake pattern specifies the sequential exchange of messages that make up the handshake.

[0172] A handshake pattern can be instantiated by DH functions, cryptographic functions, and hash functions to give a specific Noise protocol.

[0173] The core of Noise is a set of variables maintained by each participant during the handshake, as well as rules for sending and receiving handshake messages by sequentially processing tokens from the message pattern.

[0174] Each participant maintains the following variables. · s, e: The local participant's static key pair and short-term key pair (these may be empty). · rs, re: The remote participant's static public key and short-term public key (these may be empty). · h: The handshake hash value that hashes all the handshake data sent and received. · ck: The chaining key that hashes all previous DH outputs. When the handshake is complete, the chaining key is used to derive the encryption key for the transport message. · k, n: The encryption key k (which may be empty) and the counter-based nonce n. Whenever a new ck is calculated from a new DH output, a new k is also calculated. The key k and the nonce n are used to encrypt the static public key and the handshake payload. Encryption with k uses some authenticated encryption (AEAD) cipher mode and uses the current value of h as the associated data covered by the AEAD authentication. Encryption of the static public key and the payload provides a certain confidentiality and key confirmation during the handshake phase.

[0175] The handshake message consists of several DH public keys followed by a payload. The payload may contain a certificate or other data selected by the application. To send a handshake message, the sender specifies the payload and processes each token sequentially from the message pattern. The possible tokens are as follows. · "e": The sender generates a new short key pair, stores it in the e variable, writes the short public key as plaintext to the message buffer, and hashes the public key together with the old h to derive a new h. · "s": The sender writes the static public key from the s variable to the message buffer, encrypts it if k is not empty, and hashes the output together with the old h to derive a new h. · "ee", "se", "es", "ss": DH is executed between the initiator's key pair (whether static or ephemeral is determined by the first character) and the responder's key pair (whether static or ephemeral is determined by the second character). The result is hashed with the old ck to derive the new ck and k, and n is set to 0.

[0176] After processing the last token in the handshake message, the sender then writes the payload to the message buffer, encrypts it if k is not empty, and hashes the output with the old h to derive the new h.

[0177] As a simple example, an unauthenticated DH handshake is described by the handshake pattern. -> e <- e, ee

[0178] The initiator sends a first message which is simply an ephemeral public key. The responder returns its own ephemeral public key. Then DH is executed and the output is hashed to the shared secret key.

[0179] Note that after the ephemeral public key, a plaintext payload is sent in the first message, and after the ephemeral public key, an encrypted payload is sent in the response message. The application can send any payload it desires.

[0180] The responder sends its static public key (under encryption), and can authenticate itself via a slightly different pattern -> e <- e, ee, s, es

[0181] ​In this case, the final values of ck and k are the hashes of both DH results. Since the es token indicates the DH between the initiator's ephemeral key and the responder's static key, the initiator's successful decryption of the second message's payload will authenticate the responder to the initiator.

[0182] The payload of the second message may contain plaintext of length 0, but note that since encryption is done in AEAD mode, the ciphertext of the payload will still contain authentication data (such as an authentication tag or "synthetic IV"). The payload of the second message can also be used to distribute a certificate for the responder's static public key.

[0183] The initiator sends its static public key (under encryption), and can authenticate itself using a handshake pattern with one additional message -> e <- e, ee, s, es -> s, se as follows.

[0184] The following sections describe the details in more specificity and become somewhat more complex. However, the core of Noise is this simple system of variables, tokens, and processing rules that enables a concise representation of a wide range of protocols.

[0185] In step 514, based on the handshake described above, a shared secret key is obtained, which then becomes the key used for end-to-end encryption of the channel. In some embodiments, the shared key is not used directly, and there may be additional processing and further key derivation, secondary DH exchanges, double ratchets, etc., where it is combined with any such key obtained subsequent to the handshake in step 512 and used as well.

[0186] The method of FIG. 6 for the second aspect is implemented by one or more processors associated with the client.

[0187] In step 602, a request associated with the channel service is sent by the client, and in step 604, following the successful verification of validity, one or more functions associated with the channel service, namely the channel API and the message API, etc., are obtained. These steps are similar to steps 306 and 308 of FIG. 3 and also relate to steps 502 and 504 of FIG. 5.

[0188] In step 606, the client creates a channel for communication with a peer or a third party (another entity). This is similar to step 310 of FIG. 3.

[0189] In step 608, the client addressing key as well as the client endpoint are sent to another entity via the created channel. In step 610, the addressing key of the third party is received from another entity. These steps are similar to steps 508 and 510, except that it is the client rather than the channel processor that provides the endpoint and the addressing key to another participant via the channel. In some embodiments, the other participant may be a minor, a channel processor, or any other third - party entity with which direct communication via the channel is intended and for which a client endpoint is provided.

[0190] Steps 612 and 614 for performing a handshake to identify a shared secret key for end - to - end encryption are similar to steps 512 and 514, except that the handshake is performed between the client and another entity.

[0191] The method of FIG. 7 for the second aspect is implemented by one or more processors associated with a miner.

[0192] Step 702 indicates that the miner receives a request from the submitter to mine the completed transaction. This request may be from the channel processor or from a client associated with the channel service implemented by the channel processor. In some embodiments, the miner may be a client of the channel service. In the embodiment of FIG. 7, the channel processor is the submitter, but the present disclosure is not so limited.

[0193] Step 704 is similar to step 608, and the service (submitter) addressing key and service (submitter) endpoint are received. Step 706 is similar to step 610, except that in this case the miner addressing key is provided.

[0194] Steps 708 and 710 for performing a handshake to identify a shared secret key for use in end-to-end encryption are similar to steps 512 and 514, except that the handshake is performed between the miner and the submitter.

[0195] FIG. 8 represents an exemplary flow of messages using a channel for an example of peer-to-peer communication / transaction / exchange between a client of a channel service and another entity (counterparty) based on the first and second aspects of the present disclosure discussed above.

[0196] Use Cases

[0197] This section describes some existing real-world scenarios using an application messaging system among participants in which the aspects and embodiments of the present disclosure can be implemented / used / applied to realize all of the advantages described above with respect to the first and second aspects.

[0198] A) Peer-to-Peer Transaction:

[0199] To promote the adoption of cryptocurrencies, cryptocurrency payments must approximate the manner in which fiat currency payments function, specifically, the traditional manner in which we pay for goods at the checkout counter. Customers must be able to spend BSV without being online, and the merchant will bear the burden of broadcasting the transaction. To do this, a low-bandwidth SPV system is an appropriate solution. Customers may be offline most of the time and have a wallet that only has the ability to pay for transactions that include block header UTXOs, input Tx, and Merkle paths. On the other hand, merchants have a system that can branch out across the entire location using a central hub that receives those payments and broadcasts them to the blockchain.

[0200] A schematic representation of such a peer-to-peer flow can be seen in Figure 9. This flow of Invoice - Transaction - Submission - Verification allows participants to conduct transactions without the need to maintain and investigate a full replica of the Bitcoin SV blockchain.

[0201] The sender system and the receiver system may be sophisticated solutions with server-side advanced key management and always-on connections, in which case they may communicate directly in response to user requests. However, the sender and / or receiver may be end-user devices with partial connections. In this configuration, the sender and receiver are not connected and may not be contactable simultaneously. Furthermore, if both the sender and receiver are devices with partial connections, they may both be behind a Network Address Translation (NAT) configuration, which prevents them from being in a state where they can communicate directly even if both are online at the same time.

[0202] The solution provided by the channel service of the present disclosure suitable for peer-to-peer exchange of transactions advantageously enables peers to exchange messages when the counterpart is offline and in deployments where there is no simple route between two participants.

[0203] B) Invoice sending:

[0204] Invoice sending enables a participant conducting a transaction to request payment directly from the recipient to the sender. Logically, an invoice consists of · issuer details · invoice number or payment request reference · payee script · payable amount · return path and so on.

[0205] Implementing the channel service of the present disclosure for use cases of invoice sending advantageously meets the following requirements. · Addressing: The invoice issuer must be able to address the invoice for delivery to the invoice recipient, and the sender must be able to deliver the payment transaction to the issuer later. · Confidentiality: The invoice may be non-public and / or business confidential and must not be visible to any third party other than the participants conducting the transaction. · Authentication: Participants must be able to authenticate counterparts in any message exchange so that the sender can verify the legitimacy of the invoice source (recipient) and so that the source of the invoice does not violate the sender's privacy by sharing details with another participant. · Data integrity: The message must be tamper-evident so that the sending participant can know that the received invoice has not been modified since it was issued by the recipient, for example, to correct the payee, the payable amount, or the assumed issuer details.

[0206] C) Payment Channel:

[0207] A payment channel is a technique for off-chain payment negotiation that reduces the counterparty's risk to almost zero. A typical use of a payment channel is for scenarios where low-value, high-frequency metered billing is required. Some examples of such payment scenarios are as follows. · Public Wi-Fi access · Streaming media (movies, sports events) · Parking · Prepaid household utility bills (electricity, gas, water)

[0208] One construction of a payment channel is similar in nature to a credit card pre-authorization, in that the provider or merchant can be confident that funds are secured, while still protecting the customer against non-delivery of goods or services.

[0209] In this construction, an initial funding transaction is constructed that pays the provider the full amount of the funds. Before this transaction is submitted for inclusion in the Bitcoin SV blockchain, a refund transaction is constructed that returns all of the funds to the customer. This refund transaction is further blocked by a time lock set far enough in the future to allow the provision of goods or services to conclude.

[0210] If neither participant takes further action, the customer can be confident that the "pre-authorized" funds will be returned to the customer when the time lock expires.

[0211] When service provision begins, a new transaction is constructed that pays the pre-authorized funds to both the customer and the provider, and the ratio of customer:provider payment depends on the elapsed time unit per unit price (e.g., 1000 satoshis per second). This payment transaction is continuously updated by the customer and sent to the provider in exchange for the customer receiving the next unit of goods or services.

[0212] This continuously updated transaction is also blocked by a time lock, which is set somewhere between the expected end of service provision and when a full customer refund transaction becomes active.

[0213] If either participant stops the transaction midway, the maximum loss to either participant is the value of one time unit of billing, which in this example is a 1000 satoshi loss to the customer or a 1000 satoshi worth of goods or services loss to the merchant. The latest version of this split payment transaction can be submitted for inclusion in the Bitcoin SV blockchain by either participant, regardless of the other party's response.

[0214] When the payment channel reaches a conclusion, the merchant or service provider has the goods or services fully prepared and the customer has paid the correct amount. The service provider may submit the final version of the split transaction to settle the payment channel.

[0215] The use case represents almost entirely an off-chain solution, and only the "pre-orchestration" transaction and any settlement transaction that is most appropriate are broadcast to the Bitcoin SV network.

[0216] Implementing the channel service of this disclosure for the use case of payment channels advantageously meets the following requirements. · Addressing: The customer and service provider must be able to exchange messages based on some stable destinations. · Authentication: This construction reduces the counterparty risk to almost zero, but due to the default terms, actions may be taken by one participant against the other, so the participants must be able to authenticate each other. The participants must be confident about who they are communicating with during the life cycle of the payment channel. · Data integrity: Messages must be verifiably received as they are sent to prevent a third party from "trapping" one of the participants conducting the transaction for a contract violation or other penalty. · Real-time: Payment channels may operate for high-frequency (but not all) low-value increments, and in scenarios with short time units, updates to split transactions need to be routed (pseudo) real-time from the customer to the provider to prevent service interruptions due to non-payments received.

[0217] D) Multi-signature wallet:

[0218] A multi-signature wallet protects funds using a script that requires authorization from multiple participants within a defined group in the form of signatures. Whether it is based on the traditional (sometimes called "naked") OP_CHECKMULTISIG or a newer accumulator multi-signature construction, the wallet may be configured to require authorization from a subset of the group, and the size of that subset can range from 1 to all participants. This is sometimes called M-of-N multi-signature.

[0219] Until M signatures are applied to the spending of multi-signature protected funds, a transaction that spends it is not valid under the Bitcoin rules. This means that unsigned or partially signed transactions cannot be exchanged among the validating participants via the Bitcoin SV network. Additionally, even if this were possible, it would be contrary to current scaling initiatives, including peer-to-peer transactions and the SPV model.

[0220] Therefore, participants within the group need to exchange transactions with each other, along with the context (why are these funds being spent and who are they being spent to?), until sufficient authorization is given for the spending transaction to be valid. It can then either be passed on to the recipient of the funds or submitted for mining. An exemplary schematic flow for this scenario can be seen in Figure 10.

[0221] Implementing the channel service of the present disclosure for use cases of multi-signature signatures advantageously meets the following requirements. · Addressing: Participants must be able to route transactions (and context) to each other by some means. · Authentication: Participants must be able to authenticate the source of an authorization request in order to immediately reject an unauthorized spending request. · Data integrity: The context and transaction must be presented to the group by the initiating participant. In addition, participants within the group may be using any mix of partially connected local client software and fully connected local client software, and that local client software may be unreachable due to NAT deployment. Any messaging solution must be able to overcome these obstacles.

[0222] E) Secure multiparty computation:

[0223] Secure multiparty computation (also known as secure computation, multiparty computation (MPC), or privacy-preserving computation) is a field of cryptography aimed at creating methods for participants to jointly compute a function over their inputs while keeping those inputs secret. Unlike conventional cryptographic tasks where cryptography guarantees the security and integrity of communication or storage and the adversary is outside the participants' systems (eavesdroppers on the sender and receiver), the cryptography in this model protects the participants' privacy from each other.

[0224] Solutions that improve the security of private-key based systems are beginning to emerge by computing private keys as part of multiparty computation. Completion of this protocol, sometimes called dealerless secret sharing, causes several participants, devices, or systems to hold shares of a private key. A second protocol, threshold signature, further enables those participants holding shares of the key to jointly generate a valid ECDSA signature over a message.

[0225] From start to signature completion, the private key never appears in a single location. This provides a level of security similar to the multisignature scheme but offers improved privacy by hiding the number of participants from the blockchain (and in some multisignature schemes, the public keys of those participants).

[0226] Implementing the channel service of the present disclosure for use cases of secure multiparty computation advantageously meets the following requirements. · Confidentiality: The security of MPC is broken if any message between any pair of participants is observed by any other participant, even within the same group. · Authentication: In any message exchange, participants must be able to authenticate their counterparts in order to prevent confidentiality breaches through man-in-the-middle attacks or the like. · Data integrity: Messages must be tamper-evident so that participants can tell if a received message has been altered during transport from the conversation's counterpart.

[0227] Depending on the specific application example, secret material, including the sharing of private keys and other intermediate states, may exist on end-user devices with partial connectivity. Messages between pairs of participants must be delivered regardless of the connection state of the sender and receiver.

[0228] F) Device synchronization:

[0229] Consider a system model in which the following entities are defined. · Accounts that logically hold secrets and / or funds · Users, representing individuals with permissions to act on behalf of an account, where an account has one or more users · Devices, owned by users who may have multiple devices

[0230] In such a system, many authentication and authorization schemes are possible. In one model, all account secrets, such as private keys or symmetric keys, are managed by the system.

[0231] The user authenticates to such a system using one or more well - understood methods such as passwords, TOTP / authenticator apps, smart cards, and / or hardware keys. Once authenticated, the user may register one or more devices, such as a desktop or laptop computer, a tablet, or a smartphone, under the user's control. End - user devices are increasingly equipped with secure enclaves, which protect secrets (such as private keys) from loss using tamper - resistant hardware. Secure enclave operations may be further protected by additional factors such as biometrics.

[0232] Once registered, the device typically identifies itself to the system through challenge - response protocols and digital signatures, and the device - local keys are generated in a secure enclave local to the device and are never exported. In this regard, these keys operate in a manner similar to client certificates in schemes such as SSL and TLS.

[0233] The user may authorize actions to be taken within the system by authenticating those actions locally to the user's device and issuing them to the system, and the system recognizes the device as being registered. The system may then execute that action against system - managed funds using system - managed secrets, private keys (or shares thereof).

[0234] In another model, secrets such as private keys are not managed by the system but are instead managed by the user's device.

[0235] In services or applications that deploy end-to-end encryption, there is usually a handshake phase, which often involves a key exchange protocol followed by a symmetric key derivation process. The key exchange protocol may be performed using keys from only one device (usually short-term keys), and furthermore, those keys may be fully managed within a secure enclave. At the end of the handshake protocol, only one of the user's devices has knowledge of the symmetric key.

[0236] Synchronizing the plaintext of account or user-level messages received over an end-to-end encrypted channel can be resolved in one of two ways. In both cases, the devices must pair up and form a mesh of channels between device and device via a similar handshake protocol to establish an end-to-end encrypted channel between them.

[0237] Once the device mesh is established, the device that successfully completed the original third-party handshake either shares the obtained symmetric key with the user's other devices or decrypts the channel messages and then re-encrypts them before forwarding them to the other devices. Both models are seen in today's products and services.

[0238] Implementing the channel service of the present disclosure for use cases of device synchronization advantageously meets the following requirements. · Addressing: The device pair must be able to locate each other · Authentication: The device pair must be confident that the counterparty in any message exchange is the expected channel counterparty · Confidentiality: Participants other than the device pair must not be able to know the secrets or private messages exchanged between the devices · Data integrity: Any attempt to interfere with the distribution of messages between devices must not result in the devices synchronizing incorrect material. · Synchronization: Devices must not attempt to respond simultaneously to an external handshake process; otherwise, the (well - constructed) handshake will fail when it detects conflicting protocol messages.

[0239] Referring now to FIG. 11, a simplified block diagram is provided for the description of a computing device 2600 that may be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. For example, the computing device 2600 may be configured to be used as one or more components of the illustrated DBMS, or the computing device 2600 may be configured to be a client entity associated with a given user, where the client entity makes database requests to a database managed by the DBMS of FIG. 11. Accordingly, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 11, the computing device 2600 may include one or more processors with one or more levels of cache memory and a memory controller (collectively labeled 2602) configured to communicate with a storage subsystem 2606 that includes main memory 2608 and persistent storage 2610. The main memory 2608 may include, as shown, dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used for storing information such as details associated with transactions and blocks as described in the present disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in the present disclosure.

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

[0241] The bus subsystem 2604 may provide a mechanism for enabling 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.

[0242] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may function as an interface for receiving data from and transmitting data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network so that data can be transmitted to and received from the device while the data technician is at a remote location such as a data center.

[0243] The user interface input device 2612 may include one or more user input devices such as a keyboard, an integrated mouse, a trackball, a touchpad, or a pointing device such as a graphics tablet, a scanner, a barcode scanner, a touch screen incorporated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, 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.

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

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

[0246] Computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device that may be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Thus, the device may be configured to convert an optical signal into an electrical signal that can be transmitted through a port that connects the device to computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 11 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 FIG. 11.

[0247] The exemplary embodiments recited

[0248] Here, the present disclosure is discussed based on the following articles regarding the above aspects, which are provided herein as exemplary embodiments to better explain, describe, and understand the claimed aspects and embodiments.

[0249] 1. A computer-implemented method for implementing a channel service for a message or transaction, wherein the channel service is provided for one or more clients, the method being performed by a channel processor, Receiving a request from a given client among the one or more clients, the request being related to the channel service, Creating an account for a given client, the account having an account identifier unique to the given client and an access key unique to the account identifier. Providing the given client with access to one or more functions that enable direct communication between the given client and another entity. The one or more functions include Channel functions or procedures related to one or more channels for data transmission, and / or Message functions or procedures related to data transmitted using one or more channels.

[0250] 2. A method as described in clause 1, wherein a given channel is associated with a channel identifier and the given channel is configured for communication with another entity in relation to data associated with a particular type or topic.

[0251] 3. A method as described in clause 2, wherein the data associated with a given channel is or includes one or more messages or transactions.

[0252] 4. A method as described in any one of clauses 1 to 3, wherein a given client is an owner of one or more channels and the method further comprises issuing one or more access tokens for a given channel among the one or more channels, the one or more access tokens being configured for secure communication with another entity and the one or more access tokens being related to the given channel or a given message in the given channel.

[0253] 5. A method as described in any of clauses 1 to 4, wherein one or more functions are application programming interfaces (APIs) issued for or provided to a given client, the API including a channel API for one or more channels and a message API for data associated with each channel or a given channel, and the access token is an API token specific to a given channel or a given message.

[0254] 6. Receiving, from the given client, a request associated with a channel; Based on a determination that an account identifier and access key associated with the given client are valid, allowing the given client to access the account; Based on a determination that the request is valid, processing the request for the channel; Sending a response to the given client, the response including access to one or more channel functions related to the request. The received request includes - A request to enumerate one or more channels related to an account for a given client - A request to create a channel for an account - A request to delete a specified channel - A request to modify properties and / or permissions associated with a specified channel - A request to generate a channel access token for a specified channel - A request to revoke a channel access token for a specified channel and includes one or more of the above, and is a method as described in any of clauses 1 to 5.

[0255] 7. A method as described in clause 6, wherein the channel functions in the response include a JavaScript Object Notation (JSON)-over-Hyper Text Transfer Protocol (HTTP) API for the account, to enable creation and / or management of one or more channels.

[0256] 8. Receiving, from a given client, a request associated with a message, wherein the message relates to data associated with a given channel for the given client, and Based on a determination that the account identifier and access key associated with the given client are valid, allowing the given client to access the account, and Based on a determination that the request is valid, processing the request for the message, and Sending a response to the given client, wherein the response includes access to one or more message functions related to the request, and The received request is - A request to test a new message in a given channel - A request to retrieve a message in a given channel - A request to mark or identify read or unread messages in a given channel - A request to write a message in a given channel A method as described in any of clauses 1 to 7, including one or more of the above.

[0257] 9. A method as described in clause 8, wherein the message functions in the response include a JSON-over-HTTP API for the account, to enable a given client and one or more other entities to exchange messages, and / or read data from a given channel, and / or write data to a given channel.

[0258] 10. A method as described in any of clauses 1 to 9, wherein the channel processor is associated with an HTTP API endpoint and requests from a given client are received based on the HTTP transmission protocol format.

[0259] 11. The channel processor is associated with an API converter, and the API converter receives requests from a given client in the HTTP transmission protocol format, and converts the received requests into a remote procedure call (RPC) format and sends an RPC request to the channel processor to execute the received requests, and receives a response from the channel processor in the RPC format, and converts each response to be sent to a given client using the HTTP transmission protocol. A method as described in clause 10, configured to perform the steps.

[0260] 12. A method as described in any of clauses 1 to 11, wherein the received request is an HTTP GET or POST or PUT or PATCH request that includes or is associated with an account identifier for a given client.

[0261] 13. The account identifier is an alias provided for a given client, the alias is unique to the given client, provided by an alias-based addressing service, the addressing service has a machine-readable resource accessible from a defined or known location, and the machine-readable resource includes one or more capabilities related to the given client. A method as described in any of clauses 1 to 12.

[0262] 14. A method as described in clause 13, wherein the alias is associated with the domain name of a given client.

[0263] 15. A method as described in any of clauses 1 to 14, comprising the step of providing a channel service library for a given client, the channel service library including one or more modules for assisting channel functions and / or message functions for an account associated with the given client.

[0264] 16. In response to receiving a completed message or transaction associated with a given channel from a given client for submission to a blockchain, the step of submitting the transaction to a given miner; the step of creating a channel for communication with the given miner; the step of providing the given miner with access to one or more functions that enable direct communication with a channel processor; A method as described in any of clauses 1 to 15, comprising the step of using the channel to receive from the given miner a proof of inclusion of the completed transaction in a block.

[0265] 17. A computer-implemented method for accessing a channel service for a message or transaction, the channel service being provided for one or more clients, the method being implemented by one or more processors of a given client among the one or more clients, the step of sending a request related to the channel service, the channel service being implemented by a channel processor; the step of obtaining an account certificate for an account created for the given client, the account certificate including an account identifier and an access key unique to the account identifier; obtaining access to one or more functions that enable direct communication between a given client and another entity, the one or more functions including channel functions or procedures related to one or more channels for data transmission, and / or message functions or procedures related to data transmitted using one or more channels.

[0266] 18. transmitting a request related to a channel for an account of a given client, and obtaining a response from a channel processor, the response including access to one or more channel functions related to the request. wherein the request includes - a request to enumerate one or more channels related to an account for a given client - a request to create a channel for an account - a request to delete a specified channel - a request to modify properties and / or permissions associated with a specified channel - a request to generate a channel access token for a specified channel - a request to revoke a channel access token for a specified channel the method as described in clause 17 including one or more of the foregoing.

[0267] 19. the method as described in clause 18, wherein the channel functions obtained in the response include a channel API for an account, the channel API enabling creation and / or management of one or more channels.

[0268] 20. the method as described in clause 19, wherein the response includes an access token such as an API token for each channel function.

[0269] 21. A step of sending a request associated with a message, wherein the message relates to data associated with a given channel for a given client's account, A step of obtaining a response from a channel processor, wherein the response includes access to one or more message functions related to the request, The request is - A request for testing new messages in a given channel - A request for retrieving messages in a given channel - A request for marking or identifying read or unread messages in a given channel - A request for writing messages in a given channel including one or more of the above, in the manner described in clause 17.

[0270] 22. The message functions in the response include a message API for the account to enable a given client and one or more other entities to exchange messages and / or read data from and / or write data to a given channel, in the manner described in clause 21.

[0271] 23. The response includes an access token such as a message API token for each message function, in the manner described in clause 22.

[0272] 24. A step of identifying another entity with which to conduct a communication exchange, A step of creating a channel for communication using one or more channel functions received from a channel processor, A step of sending one or more access tokens associated with the channel to the other entity, Writing at least one message related to a transaction to a channel using one or more message functions for the channel received from a channel processor; Sending one or more access tokens associated with one or more messages to another entity; Receiving at least one response message related to a transaction in the channel; Further comprising providing a completed transaction for submission in response to completion of the communication exchange, a method as described in any of clauses 17 to 23.

[0273] 25. A method as described in any of clauses 17 to 24, comprising receiving and / or storing a channel service library, the channel service library including one or more modules for assisting channel functions and / or message functions received from a channel processor for an account associated with a given client.

[0274] 26. A method implemented on a computer for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a given miner among a plurality of miners, the plurality of miners being communicatively coupled to at least one channel processor implementing a channel service for at least one client, Receiving, by another entity, a request for submission of a completed transaction to the blockchain; Receiving, from another entity, access to a channel enabling direct communication with the other entity; Comprising sending, using the channel, a proof of inclusion of the completed transaction to further mine the completed transaction in a block.

[0275] 27. A method implemented on a computer for performing addressing for channel services, wherein the channel services are provided for messages or transactions, the channel services are provided for one or more clients, the method is implemented by a channel processor, receiving a request from a given client among a plurality of clients, the request being related to channel services; providing a service endpoint for the client based on a determination that an account identifier and an access key related to the given client are valid; providing at least one service addressing key associated with the channel service; obtaining at least one client addressing key associated with the client; providing the given client with access to one or more functions that enable direct communication between the given client and another entity using a channel for sending data or messages based on the received request.

[0276] 28. Receiving a completed message or transaction associated with a given client for submission to a blockchain; providing a service endpoint for a miner; providing at least one service addressing key associated with the channel service; obtaining at least one miner addressing key associated with the miner; providing the miner with access to one or more functions that enable direct communication using a channel with the channel service, the method as described in clause 27.

[0277] 29. The method as described in any one of clauses 27 or 28, wherein the service addressing key, the client addressing key, and / or the minor addressing key is one or more static keys and / or short-term keys.

[0278] 30. Based on the service and client / minor addressing keys, exchanging one or more handshake messages between the client / minor and a server, obtaining a handshake result or pattern, and obtaining a shared secret key based on the handshake result or pattern, wherein the direct communication using the channel is encrypted based on the shared secret key, as described in any one of clauses 27 to 29.

[0279] 31. The method as described in any one of clauses 27 to 30, wherein the service endpoint is a Hypertext Transfer Protocol (HTTP) Application Programming Interface (API) endpoint, and the endpoint is delivered to the client using HTTP Secure (HTTPS).

[0280] 32. The method as described in any one of clauses 27 to 30, wherein the service endpoint is a Universal Resource Locator (URL) included in a response to a request from a given client for one or more functions associated with a channel service.

[0281] 33. A service endpoint is an alias associated with a channel service, the alias being specific to a channel processor and provided by an alias-based addressing service, the addressing service having a machine-readable resource accessible from a defined or known location, the machine-readable resource including one or more capabilities related to the channel processor, in a manner as described in any of clauses 27 to 32.

[0282] 34. The alias is either known to or provided to one or more clients / minors, the alias being associated with an asymmetric encryption key pair for authentication, in a manner as described in clause 33.

[0283] 35. A channel service is implemented using a method as described in any one of clauses 1 to 16, in a manner as described in any one of clauses 27 to 34.

[0284] 36. A computer-implemented method for performing addressing for a channel using a channel service for a message or transaction, the channel service being provided for one or more clients, the method being performed by one or more processors of a given client among the one or more clients, the step of sending a request related to the channel service, the channel service being implemented by a channel processor, the step of obtaining a service endpoint associated with the channel service, the step of obtaining at least one service addressing key associated with the channel service, the step of providing at least one client addressing key associated with the given client, A method comprising obtaining access to one or more functions that enable direct communication between a given client and another entity using a channel for sending data or messages.

[0285] 37. Identifying another entity with which to perform a communication exchange; Creating a channel for the communication exchange using one or more functions received from a channel processor, the method further using the created channel to Provide a client endpoint; Obtain at least one third party addressing key associated with the other entity; Provide at least one client addressing key associated with the given client; Exchanging one or more handshake messages using the channel based on the client and third party addressing keys; Obtaining a shared secret key based on the handshake result or pattern; A method as described in clause 36, wherein the direct communication with the other entity using the channel is encrypted based on the shared secret key.

[0286] 38. A method as described in clause 36 or 37, wherein the service addressing key, and / or the client addressing key, and / or the third party addressing key are one or more static keys and / or short-term keys.

[0287] 39. A method as described in any one of clauses 36 to 38, wherein the client endpoint is a Hypertext Transfer Protocol (HTTP) Application Programming Interface (API) endpoint and the client endpoint is delivered using HTTP Secure (HTTPS).

[0288] 40. A method as described in any one of clauses 36 to 38, wherein the client endpoint is a Universal Resource Locator (URL) included in a message from a given client that is sent using the created channel.

[0289] 41. A method as described in any one of clauses 36 to 40, wherein the client endpoint is an alias associated with the client, the alias is unique to the client, provided by an alias-based addressing service, the addressing service has a machine-readable resource accessible from a defined or known location, the machine-readable resource includes one or more capabilities related to the client, and the alias is associated with an asymmetric encryption key pair for authentication.

[0290] 42. A method as described in any one of clauses 36 to 41, wherein another entity is associated with the alias, the alias is unique to the other entity, provided by an alias-based addressing service, the addressing service has a machine-readable resource accessible from a defined or known location, the machine-readable resource includes one or more capabilities related to the other entity, and the alias is associated with an asymmetric encryption key pair for authentication.

[0291] 43. A method as described in any one of clauses 36 to 42, further comprising a method as described in any one of clauses 17 to 26.

[0292] 44. A computer-implemented method for processing transactions associated with a blockchain, the method being implemented by one or more processors associated with a miner among a plurality of miners, the plurality of miners being communicatively coupled to at least one channel processor that implements a channel service for at least one client, the method comprising: Receiving, from a submitter, a request to mine a completed transaction, the submitter being a channel processor or a client associated with the channel service; Obtaining a service endpoint or client endpoint associated with the submitter; Obtaining at least one service addressing key or client addressing key associated with the submitter; Providing at least one miner addressing key associated with the miner; Obtaining access to one or more functions that enable direct communication with the channel service using the channel.

[0293] 45. A method as described in clause 44, wherein the service / client addressing key and / or the miner addressing key is one or more static keys and / or short-term keys.

[0294] 46. A method as described in either clause 44 or 45, comprising exchanging one or more handshake messages between the channel processor and one or more miners based on the service / client addressing key and the miner addressing key, and obtaining a shared secret key based on the handshake result or pattern, wherein the direct communication using the channel is encrypted based on the shared secret key. Obtaining a shared secret key based on the handshake result or pattern. The direct communication using the channel is encrypted based on the shared secret key.

[0295] 47. The minor endpoint is a Hypertext Transfer Protocol (HTTP) Application Programming Interface (API) endpoint, and the endpoint is provided using HTTP Secure (HTTPS) in a manner as described in any one of clauses 44 to 46.

[0296] 48. The minor endpoint is a Universal Resource Locator (URL) included in a message from a minor that is sent using one or more functions associated with a channel service in a manner as described in any one of clauses 44 to 46.

[0297] 49. The minor endpoint is an alias associated with a minor, the alias is unique to the minor, provided by an alias-based addressing service, the addressing service has a machine-readable resource accessible from a defined or known location, the machine-readable resource includes one or more capabilities related to the minor, and the alias is associated with an asymmetric encryption key pair for authentication, in a manner as described in any one of clauses 44 to 48.

[0298] 50. A method as described in any one of clauses 44 to 49, further comprising a method as described in clause 26.

[0299] 51. A computing device comprising a processor and a memory, the memory including executable instructions that cause the device to execute a computer-implemented method as described in any one of clauses 1 to 16 and clauses 27 to 34 as a result of execution by the processor, and the computing device being related to a channel processor.

[0300] 52. A computing device comprising a processor and a memory, the memory including executable instructions that cause the device to execute, as a result of execution by the processor, a method implemented on a computer as described in any one of clauses 17 to 25 and clauses 36 to 43, the computing device being related to a client.

[0301] 53. A computing device comprising a processor and a memory, the memory including executable instructions that cause the device to execute, as a result of execution by the processor, a method implemented on a computer as described in any one of clauses 26 and 44 to 50, the computing device being related to a minor.

[0302] 54. At least one channel processor communicatively coupled to at least one client and at least one minor via a communication network, the at least one channel processor implementing channel services for one or more clients, the at least one channel processor being implemented according to a computing device as described in clause 51, at least one client being implemented according to a computing device as described in clause 52, and at least one minor being implemented according to a computing device as described in clause 53.

[0303] 55. A computer-readable storage medium storing executable instructions that cause a computer to execute, as a result of execution by the computer's processor, a method according to any one of clauses 1 to 50.

[0304] The aspects and embodiments mentioned above are illustrative rather than limiting the present disclosure, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended patent claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words such as "comprising" and "comprises" do not exclude the existence of elements or steps other than those recited as a whole in any claim or specification. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consisting of". The mention of an element in the singular does not exclude the mention of that element in the plural, and vice versa. The present disclosure can be implemented by hardware comprising several distinct elements and by a suitably programmed computer. In a claim of a device enumerating several means, some of these means may be embodied by the same piece of hardware. The mere fact that some measures are recited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

Explanation of Signs

[0305] 2600 Computing Device 2602 Processor 2604 Bus Subsystem 2606 Storage Subsystem 2608 Main Memory 2610 Persistent Storage 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 Dynamic Random Access Memory (DRAM) 2620 Read Only Memory (ROM) 2624 Clock< / credentials> < / type> < / id> < / sequence> < / id> ​ < / number> < / id> < / id> < / id> ​< / number> < / number> < / sequence> < / id> < / number> < / number> ​​< / number> < / number> < / sequence> < / id>

Claims

1. A computer-implemented method for implementing a channel service for a message or transaction, wherein the channel service is provided for one or more clients, and the method is performed by a channel processor, receiving a request from a given client among the one or more clients, wherein the request is related to the channel service; creating an account for the given client, the account having an account identifier unique to the given client and an access key unique to the account identifier; providing the given client with access to one or more functions that enable direct communication between the given client and another entity; comprising: wherein the one or more functions include channel functions or procedures related to one or more channels for data transmission and / or message functions or procedures related to the data transmitted using the one or more channels; wherein the method, in response to receiving a completed message or transaction associated with a given channel from the given client for submission to a blockchain, submits the transaction to a given miner; creates a channel for communication with the given miner; provides the given miner with access to one or more functions that enable direct communication with the channel processor; and receives, using the channel, a proof of inclusion of the completed transaction in a block of the blockchain from the given miner. A method as described above.

2. The method according to claim 1, wherein a given channel is associated with a channel identifier and is configured for communication with another entity in relation to data associated with a specific type or topic.

3. The method according to claim 2, wherein the data associated with the given channel is or includes one or more messages or transactions.

4. The given client is the owner of the one or more channels, and the method further comprises the step of issuing one or more access tokens for a given channel among the one or more channels, the one or more access tokens being configured for secure communication with another entity, the one or more access tokens being related to the given channel or a given message in the given channel, the method according to any one of claims 1 to 3.

5. The one or more functions are application programming interfaces (APIs) issued for or provided to the given client, the API including a channel API for the one or more channels and a message API for data associated with each channel or a given channel, the access token being an API token specific to a given channel or a given message, the method according to claim 4.

6. Receiving a request associated with a channel from the given client; Based on a determination that the account identifier and access key associated with the given client are valid, permitting the given client to access the account; Based on a determination that the request is valid, processing the request for the channel; Sending a response to the given client, the response including access to one or more channel functions related to the request; comprising The received request is - a request to enumerate the one or more channels related to the account for the given client, - a request to create a channel for the account, - a request to delete a specified channel, - a request to modify properties and / or permissions associated with a specified channel, - a request to generate a channel access token for a specified channel, - a request to revoke a channel access token for a specified channel, including one or more of the method according to any one of claims 1 to 5.

7. The method of claim 6, wherein the channel function in the response includes a JavaScript Object Notation (JSON)-over-HyperText Transfer Protocol (HTTP) API for the account to enable creation and / or management of one or more channels. **Claim 8** Receiving, from the given client, a request associated with a message, wherein the message relates to data associated with a given channel for the given client; Based on a determination that the account identifier and access key associated with the given client are valid, allowing the given client to access the account; Based on a determination that the request is valid, processing the request for the message; Sending a response to the given client, the response including access to one or more message functions related to the request; comprising: wherein the received request includes - a request to test for new messages in the given channel - a request to retrieve messages in the given channel - a request to mark or identify read or unread messages in the given channel - a request to write a message in the given channel The method according to any one of claims 1 to 7, including one or more of the above. **Claim 9** The method of claim 8, wherein the message function in the response includes a JSON-over-HTTP API for the account to enable the given client and one or more other entities to exchange messages and / or read data from and / or write data to the given channel. **Claim 10** The method according to any one of claims 1 to 9, wherein the channel processor is associated with an HTTP API endpoint and the request from the given client is received based on an HTTP transmission protocol format. **Claim 11** The channel processor is associated with an API converter, and the API converter receiving the request from the given client in an HTTP transmission protocol format; converting the received request into a Remote Procedure Call (RPC) format and sending the RPC request to the channel processor to execute the received request; receiving a response from the channel processor in an RPC format; converting each response to be sent to the given client using an HTTP transmission protocol; The method according to claim 10, configured to perform.

12. The method according to any one of claims 1 to 11, wherein the received request is an HTTP GET or POST or PUT or PATCH request that includes or is associated with an account identifier for the given client.

13. The method according to any one of claims 1 to 12, wherein the account identifier is an alias provided for a given client, the alias is unique to the given client, provided by an alias-based addressing service, the addressing service has a machine-readable resource accessible from a defined or known location, and the machine-readable resource includes one or more capabilities related to the given client.

14. The method according to claim 13, wherein the alias is associated with the domain name of the given client.

15. The method according to any one of claims 1 to 14, further comprising providing a channel service library for the given client, the channel service library including one or more modules to assist the channel functions and / or the message functions for the account associated with the given client.

16. The method further includes method steps for accessing the channel service for a message or transaction, implemented by one or more processors of a given client among one or more clients, the channel service being provided for one or more clients, and the method comprising: A step of sending a request related to the channel service, wherein the channel service is implemented by a channel processor; A step of obtaining an account certificate for an account created for the given client, wherein the account certificate includes an account identifier and an access key unique to the account identifier; A step of obtaining access to one or more functions that enable direct communication between the given client and another entity comprising, wherein the one or more functions include channel functions or procedures related to one or more channels for data transmission, and / or message functions or procedures related to the data transmitted using the one or more channels. The method according to claim 1.

17. A step of sending a request related to a channel for the account of the given client; and A step of obtaining a response from the channel processor, wherein the response includes access to one or more channel functions related to the request. comprising, wherein the request - a request for enumerating the one or more channels related to the account for the given client, - a request for creating a channel for the account, - a request for deleting a specified channel, - a request for modifying properties and / or permissions associated with a specified channel, - a request for generating a channel access token for a specified channel, - a request for canceling a channel access token for a specified channel The method according to claim 16, comprising one or more of the above.

18. The method according to claim 17, wherein the channel function obtained in the response includes a channel API for the account, and the channel API enables creation and / or management of one or more channels.

19. The method according to claim 18, wherein the response includes an access token, and the access token includes an API token for each channel function.

20. A step of sending a request associated with a message, wherein the message relates to data associated with a given channel for an account of the given client. A step of obtaining a response from the channel processor, wherein the response includes access to one or more message functions related to the request. Comprising: The request is: - A request for testing new messages in the given channel - A request for retrieving messages in the given channel - A request for marking or identifying read or unread messages in the given channel - A request for writing messages in the given channel The method according to claim 16, comprising one or more of the above.

21. The message function in the response includes a message API for the account to enable the given client and one or more other entities to exchange messages, and / or read data from the given channel, and / or write data to the given channel. The method according to claim 20.

22. The response includes an access token, and the access token includes a message API token for each message function. The method according to claim 21.

23. A step of identifying another entity with which a communication exchange is to be made. A step of creating a channel for communication using one or more channel functions received from the channel processor. A step of sending one or more access tokens associated with the channel to the other entity. A step of writing at least one message related to a transaction to the channel using one or more message functions for the channel received from the channel processor. A step of sending one or more access tokens associated with the one or more messages to the other entity. A step of receiving at least one response message related to the transaction in the channel. A step of providing the completed transaction for submission in response to the completion of the communication exchange. The method according to any one of claims 16 to 22, further comprising

24. A method comprising receiving and / or storing a channel service library, the channel service library including one or more modules for assisting the channel functions and / or the message functions received from the channel processor for the account associated with the given client, according to any one of claims 16 to 23

25. A method implemented on a computer for processing a transaction associated with a blockchain, the method being implemented by one or more processors associated with a given miner among a plurality of miners, the plurality of miners being communicatively coupled to at least one channel processor implementing a channel service for at least one client Receiving, by another entity, a request for submission of a completed transaction to the blockchain Receiving, from the other entity, access to a channel enabling direct communication with the other entity Transmitting, using the channel, a proof of inclusion of the completed transaction for further mining of the completed transaction in a block of the blockchain The method comprising

26. A method implemented on a computer for performing addressing for a channel service, the channel service being provided for a message or a transaction, the channel service being provided for one or more clients, the method being implemented by a channel processor Receiving a request from a given client among the plurality of clients, the request being related to the channel service Providing a service endpoint for the client based on a determination that an account identifier and an access key associated with the given client are valid Providing at least one service addressing key associated with the channel service Obtaining at least one client addressing key associated with the client Based on the received request, providing the given client with access to one or more functions that enable direct communication between the given client and another entity using a channel for sending data or messages Receiving a completed message or transaction associated with a given client for submission to a blockchain Providing a service endpoint for a miner Providing at least one service addressing key associated with the channel service Obtaining at least one miner addressing key associated with the miner Providing the miner with access to one or more functions that enable direct communication using a channel with the channel service A method comprising the above steps

27. The method according to claim 26, wherein the service addressing key, client addressing key, and / or miner addressing key are one or more static keys and / or short-term keys

28. Exchanging one or more handshake messages between the client / miner and based on the service and client / miner addressing keys Obtaining a handshake result or pattern Obtaining a shared secret key based on the handshake result or pattern Comprising the above steps The method according to any one of claims 26 to 27, wherein the direct communication using the channel is encrypted based on the shared secret key

29. The method according to any one of claims 26 to 28, wherein the service endpoint is a Hypertext Transfer Protocol (HTTP) Application Programming Interface (API) endpoint, and the endpoint is delivered to the client using HTTPSecure (HTTPS)

30. The method according to any one of claims 26 to 28, wherein the service endpoint is a Universal Resource Locator (URL) included in a response to a request from the given client for one or more functions associated with the channel service

31. The service endpoint is an alias associated with the channel service, the alias being specific to the channel processor and provided by an alias-based addressing service, the addressing service having a machine-readable resource accessible from a defined or known location, the machine-readable resource including one or more capabilities related to the channel processor, the method according to any one of claims 26 to 30.

32. The method according to claim 31, wherein the alias is either known to or provided to one or more clients / miners, and the alias is associated with an asymmetric encryption key pair for authentication.

33. The method according to any one of claims 26 to 32, wherein the channel service is implemented using the method according to any one of claims 1 to 15.

34. A computing device comprising a processor and a memory, the memory including executable instructions that cause the device to execute the method according to any one of claims 1 to 15 and claims 26 to 32 as a result of execution by the processor, the computing device being related to a channel processor.

35. A computing device comprising a processor and a memory, the memory including executable instructions that cause the device to execute the method according to claim 25 as a result of execution by the processor.

36. A computer system, comprising at least one channel processor communicatively coupled to at least one client and at least one miner via a communication network, the at least one channel processor including at least one channel processor that implements a channel service for one or more clients, the system being configured to perform the steps of the method according to any one of claims 16 to 24.

37. A computer-readable storage medium storing executable instructions that cause a computer to execute the method according to any one of claims 1 to 33 as a result of execution by a processor of the computer.

Images