Payment channel aggregator

Abstract

A computer-implemented method for facilitating payment between a first party and a second party, where each of the first party and the second party is configured to create a respective payment channel by generating a channel opening transaction, the channel opening transaction comprises an input signed by the second party and an output locked to a public key of the respective first party and a public key of the second party, wherein the output locks a respective maximum value; the method comprises, for each respective first party: obtaining one or more channel closing transaction templates from the second party, each channel closing transaction template comprising an input referencing the output of the respective channel opening transaction and comprising a signature of the second party, and a first output locked to a public key of the first party and a second output locked to a public key of the second party, where the first output locks a first amount of the respective maximum and where the second output locks a second amount of the respective maximum; and sending a selected channel closing transaction template of the one or more channel closing transaction templates to the corresponding first party.

Description

Technical Field

[0001] The present disclosure relates to a method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party. Background Art

[0002] A blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"), and the copy is widely disclosed. The blockchain includes a series of data blocks, where each block includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in the sequence, which can span one or more blocks and go back to one or more coinbase transactions. The coinbase transaction will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is generally referred to as "mining", which involves each of a plurality of nodes competing to perform a "proof of work", that is, solving a cryptographic puzzle based on a representation of a defined ordered and verified set of pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the release of blocks can be achieved by only releasing block headers.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtual ledger or registry; receiving and processing timestamp entries; and / or sorting index pointers by time. Hierarchical additional functions on the blockchain can also be utilized. For example, the blockchain protocol can allow additional user data or data indexes to be stored in transactions. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

[0004] Nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, the nodes verify the transactions and insert these transactions into a block template, and these transactions attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes in the network, enabling each node to record the new block on the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The node receiving the transaction can compete to find a proof-of-work solution that will incorporate the verified valid transaction into a new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that a transaction is valid. Invalid transactions will not be propagated or incorporated into the block. Assuming that the transaction has been verified as valid and thus accepted on the blockchain, the transaction (including any user data) will then be registered and indexed as an immutable public record on each node in the blockchain network.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction", which distributes an amount of digital assets, i.e., the number of tokens. Detection and rejection of invalid transactions are performed through the actions of competing nodes, which act as agents of the network and discourage and prevent improper behavior through incentives. The wide dissemination of information enables users to continuously audit the performance of the nodes. Publishing only the block headers enables participants to ensure the continuous integrity of the blockchain.

[0006] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying an amount of digital assets, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). The output can also include a locking script, which specifies the future redemption conditions of the output. The locking script is a predicate that defines the conditions necessary to verify and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and can also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying an amount of digital assets and includes a locking script defining one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, and the at least one input includes a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0007] In such models, when a second (target) transaction is sent to a blockchain network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction), nor include the transaction in a new block to be recorded in the blockchain.

[0008] Another transaction model is the account-based model. In this case, each transaction is defined not by referring to the UTXOs of previous transactions in a past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored separately by nodes into the blockchain and is continuously updated. Summary of the Invention

[0009] In a blockchain environment, a payment channel is a set of transactions between two parties (where each transaction represents at least one payment) and the corresponding protocols for signing and submitting the transactions, which allow for a set of valid and secure payments between the two parties without submitting the entire set of transactions to the blockchain. In the set of transactions of the payment channel, regardless of the number of transactions created, only two transactions are submitted to the blockchain. One of these submitted transactions represents the final agreed-upon payment at the end of an iterative negotiation, or can be the sum of a set of periodic payments.

[0010] For the latter, an example of a one-year subscription (such as a streaming platform like Netflix) including twelve monthly payments can be considered. Each month, the customer provides a valid and secure copy of the transaction to the streaming platform. If needed, the streaming platform can submit the transaction to the blockchain. Each monthly transaction contains a payment that is the cumulative amount owed for the current month and previous months. However, the streaming platform only submits the final transaction to the blockchain. This transaction contains the cumulative payment for the full twelve months.

[0011] Generally, it is expected to establish the payment channel between two parties, namely the payer (e.g., Alice) and the intended recipient of the payment (e.g., Bob), where Bob will be the goods / services provider. However, as recognized herein, in some cases, an intermediary may be required.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for facilitating a plurality of corresponding payments between a plurality of corresponding first parties and a second party, wherein each corresponding first party and the second party are configured to create a corresponding payment channel by generating a corresponding channel opening transaction, the corresponding channel opening transaction including a corresponding input and a corresponding output, the corresponding input being signed by the second party, and the corresponding output being locked to a corresponding public key of the corresponding first party and a public key of the second party, wherein the corresponding output locks a corresponding maximum amount; wherein the method is performed by an intermediary party, and the method includes, for each corresponding first party:

[0013] Obtaining, from the second party, one or more corresponding channel closing transaction templates, wherein each corresponding channel closing transaction template includes a corresponding input (the corresponding input referencing the corresponding output of the corresponding channel opening transaction and including a corresponding signature of the second party), and a corresponding first output (locked to the corresponding public key of the corresponding first party) and a corresponding second output (locked to the public key of the second party), wherein the corresponding first output locks a corresponding first amount of the corresponding maximum amount, and wherein the corresponding second output locks a corresponding second amount of the corresponding maximum amount; and,

[0014] Sending, to the corresponding first party, a selected corresponding channel closing transaction template from the one or more corresponding channel closing transaction templates.

[0015] In this aspect, the intermediary party is used to facilitate payments between one or more payers and payees. Payment channels are initially established between each payer and payee. However, the payment channels are not executed by the one or more payers and the payee, but rather the burden on the parties is alleviated through the intermediary party. The intermediary party collects channel closing transactions (i.e., refund transactions or settlement transactions) from the parties, and uses one of the closing transactions in the closing transactions (e.g., the transaction transferring the maximum amount to the payee) to close each individual payment channel.

[0016] For example, a streaming platform may outsource the collection of its subscription fees to a third-party collection agency. The agency collects the transaction transferring the subscription fees to the platform and submits the transaction to the blockchain, e.g., after an agreed payment amount, after an agreed amount of time, in response to a request from the payer, etc. At each iteration of the payment channel (e.g., each round of payment), the process is more efficient than if each user had to interact separately with the streaming platform.

[0017] According to another aspect disclosed herein, a computer-implemented method is provided for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and the second party are configured to create a respective payment channel by generating a respective channel opening transaction, the respective channel opening transaction including a respective input and a respective output, the respective input being signed by the second party, the respective output being locked to a respective public key of the respective first party and a public key of the second party, wherein the respective output locks a respective maximum value; wherein the method is performed by an intermediary party, and the method includes, for each respective first party:

[0018] Obtain, from the second party, one or more respective channel closing transaction templates, wherein each respective channel closing transaction template includes a respective input (the respective input referencing the respective output of the respective channel opening transaction and including a respective signature of the second party), and a respective first output (locked to the respective public key of the respective first party) and a respective second output (locked to the public key of the second party), wherein the respective first output locks a respective first amount of the respective maximum value, and wherein the respective second output locks a respective second amount of the respective maximum value; and,

[0019] Send, to the respective first party, a selected respective channel closing transaction template from the one or more respective channel closing transaction templates.

[0020] In this aspect, the intermediary party is used to facilitate payments between payers and a plurality of payees. The payment channels are initially established between the payers and each payee. However, the payment channels are not executed by the payers and the payees, but rather the intermediary party receives the channel closing transactions (i.e., refund transactions or settlement transactions) from the payers and sends the channel closing transactions to the payees for submission to the blockchain, e.g., after signing the channel closing transactions.

[0021] In this case, a party (e.g., Alice) can subscribe to multiple services (e.g., multiple instances of Bob), in which case it would be more convenient (and more efficient) to have the intermediary party collect these payments on his / her behalf. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] To assist in understanding the embodiments of the present disclosure and to illustrate how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0023] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0024] Figure 2Some examples of transactions that can be recorded in a blockchain are schematically shown;

[0025] Figure 3 An example of a one-to-one payment channel is shown;

[0026] Figure 4 An example of a many-to-one payment channel is shown;

[0027] Figure 5 An example of a one-to-many payment channel is shown. Detailed implementation

[0028] 1. Exemplary System Overview

[0029] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switching network 101, typically a wide-area internet such as the Internet. The packet-switching network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switching network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0030] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memories, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0031] The blockchain 150 includes a series of data blocks 151, where a corresponding copy of the blockchain 150 is maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can perform data pruning as long as each blockchain node 150 stores the block headers of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A specific transaction protocol is used throughout a given blockchain. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies the amount of a digital asset represented as property, an example of which is the user 103 to whom the output is cryptographically locked (requiring the user's signature or other unlocking to redeem or spend). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0032] Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the blockchain to define the order of the blocks 151. Each transaction 152 (other than the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more early original transactions 152 in the blockchain 150 point to the genesis block 153, rather than a previous transaction.

[0033] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thus enabling the transactions 152 to spread throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store a corresponding copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is commonly referred to as the "mempool". In this document, the term is not intended to be restricted to any specific blockchain, protocol, or model. The term refers to an ordered set of transactions that the node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0034] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming the output, or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified as valid in order to ensure the validity of the current transaction, the previous transaction 152i does not have to exist at the time the current transaction 152j is created or even sent to the network 106. Thus, in this document, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily to the creation time or send time in a time sequence, and thus does not necessarily rule out the case of unordered creation or sending of transactions 152i, 152j (see the discussion of orphan transactions below). The previous transaction 152i can equally well be referred to as the antecedent transaction or the predecessor transaction.

[0035] The input of the current transaction 152j also includes input authorization, such as the signature of the user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 can have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a for the purpose of making a change). In some cases, a transaction can also have multiple inputs, aggregating the amounts in the outputs of one or more previous transactions and reallocating them to one or more outputs of the current transaction.

[0036] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program or manually employed by that party), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or the recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (which are now typically servers or data centers, but in principle could also be other user terminals). Additionally, it is not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol generally requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this can include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i that the new transaction spends (or "allocates"), where the conditions generally include at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The conditions can be at least partially defined by a script included in the output of the previous transaction 152i. Alternatively, this can be determined solely by the blockchain node protocol or by a combination thereof. Whichever way is adopted, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and thus forward the new transaction 152j to one or more other nodes 104 and so on. In this way, the new transaction spreads across the entire network of blockchain nodes 104.

[0037] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is that, according to the blockchain node protocol, whether it is validly redeemed by the input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, the transaction 152j will not spread (unless marked as invalid and spread for reminder) or be recorded in the blockchain 150. This prevents double spending, i.e., a transaction processor allocating the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Since there is also a defined order of transactions, the account balance has a single defined state at any given time.

[0038] In addition to verifying the validity of transactions, blockchain node 104 also competes to be the first node to create a transaction block in a process commonly referred to as mining, which is supported by "proof of work". At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on blockchain 150. Then, blockchain nodes compete to assemble a new valid transaction block 151 for the transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with the representation of the pending transaction ordered pool 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle and does not exclude other types. The characteristic of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0039] The first blockchain node 104 that solves the puzzle announces the solution on network 106, providing the solution as proof, and then other blockchain nodes 104 in the network can easily verify the solution (once the solution for the hash value is given, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. Then, the ordered transaction set 154 is recorded as a new block 151 in blockchain 150 by each blockchain node 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it spends or allocates the same output as a previously verified valid transaction, otherwise it is called double spending. Once created, block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointer 155 also imposes an order on block 151. Since transactions 152 are recorded in ordered blocks at each blockchain node 104 in network 106, an immutable public ledger of transactions is provided.

[0040] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time can do so based on different snapshots of the pool 154 of transactions not yet released at any given time, depending on the order in which they start searching for a solution or receive transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool 154 of unreleased transactions. Then, the blockchain nodes 104 continue to compete to create a block from the newly defined ordered pool 154 of unreleased transactions, and so on. In addition, there are protocols for resolving any "forks" that may occur, where two blockchain nodes 104 solve the puzzle within a short time of each other, thus spreading conflicting views of the blockchain among the nodes 104. Briefly, the fork with the longest direction becomes the final blockchain 150. It should be noted that this does not affect the users or agents of the network, as the same transaction will appear in both forks.

[0041] According to the Bitcoin blockchain (and most other blockchains), the node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited quantity of digital assets (as opposed to an inter-agent or inter-user transaction that transfers a certain quantity of digital assets from one agent or user to another). This special type of transaction is commonly referred to as a "coinbase transaction", but can also be called a "genesis transaction" or "generation transaction". It typically forms the first transaction of the new block 151n. The proof-of-work signals the intention of the node constructing the new block to follow the protocol rules, thus allowing the specific transaction to be redeemed later. Before the special transaction can be redeemed, the blockchain protocol rules may require a maturation period, such as 100 blocks. Typically, a regular (non-generative) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is discussed below.

[0042] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0043] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in the application layer or in one or more applications in a lower layer such as the operating system layer or the protocol layer or any combination of these layers.

[0044] The computer devices 102 of each party 103 that play the role of consumer users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in a transaction. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0045] Some or all of the parties 103 can be connected as part of different networks, such as a network overlaying the blockchain network 106. The users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 can interact with the blockchain network 106 so as to utilize the blockchain 150 by connecting to the blockchain node 106 (i.e., communicating with the blockchain node 106). For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but are not shown for convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein can be replaced by "first party" and "second party" respectively.

[0046] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes corresponding instances of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein can be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0047] The client application 105 can initially be provided to the computer device 102 of any given party 103 through, for example, a suitable computer-readable storage medium downloaded from a server, or through a removable storage device such as a removable SSD, a flash drive, a removable EEPROM, a removable disk drive, a floppy disk, or a magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical disk drive.

[0048] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and thus included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant party scattered in the blockchain 150.

[0049] Note: Although various client functions may be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein may be implemented in a suite consisting of two or more different applications, such as via API interface connection or one application as a plugin of another application. More generally, client functions may be implemented at the application layer or at a lower layer such as an operating system or any combination of these layers. The following will be described in terms of client application 105, but it should be understood that this is not restrictive.

[0050] An instance of the client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This can enable the wallet function of the client 105 to send a transaction 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query any transactions in which a corresponding party 103 is the recipient in the blockchain 150 (or actually check the transactions of other parties in the blockchain 150, since in the embodiments, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send a transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify the transaction 152 according to the blockchain node protocol and forward the transaction 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0051] When a given party 103 (say Alice) wishes to send a new transaction 152j intended to be included in the blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). Then, she sends the transaction 152 from the client application 105 to one or more of the blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets specific conditions to become "valid", and specific examples will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis through the script included in the transaction 152. Alternatively, the conditions can be merely a built-in function of the node protocol or defined by combining the script and the node protocol.

[0052] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any blockchain node 104 that receives the transaction 152j will add the newly verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means the transaction will soon spread throughout the network 106.

[0053] Once in the uncommitted transaction ordered pool 154 maintained at a given blockchain node 104, that blockchain node 104 will start competing to solve the proof-of-work puzzle on the latest version of its respective pool 154 that contains the new transaction 152 (remember, other blockchain nodes 104 may attempt to solve the puzzle based on different transaction pools 154. However, the one who solves the puzzle first will define the set of transactions included in the latest block 151. Eventually, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154 that includes Alice's transaction 152j). Once the pool 154 that includes the new transaction 152j completes the proof of work, it will irrevocably become part of a block in block 151 of the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of the transactions is also irrevocably recorded.

[0054] Different blockchain nodes 104 may first receive different instances of a given transaction and thus have conflicting views on which instance is "valid" before one instance is published into the new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as a valid instance and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., consider invalid) the instance it initially accepted (i.e., the instance that has not yet been published in block 151).

[0055] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be referred to as an "account-based" protocol. In the account-based case, each transaction defines the amount of the transfer not by referring to the UTXO of a previous transaction in a past transaction sequence, but by referring to an absolute account balance. The current state of all accounts is stored separately by the nodes of the network into the blockchain and is continuously updated. In such a system, transactions are ordered using the running transaction record (also known as "position") of the account. This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. Additionally, optional data fields can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0056] 2. UTXO - based Model

[0057] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). It will be described below by referring to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although an exemplary UTXO-based protocol is described with reference to Bitcoin, it can equally be implemented on other example blockchain networks.

[0058] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 can include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO can also contain the transaction ID of its source transaction and other information. The transaction data structure can also include a header 201, which can include size indicators for the input field 202 and the output field 203. The header 201 can also include the ID of the transaction. In an embodiment, the transaction ID is the hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0059] For example, say Alice 103a wishes to create a transaction 152j that transfers a relevant amount of digital assets to Bob 103b. In Figure 2 this, Alice's new transaction 152j is labeled "Tx1". This new transaction obtains the amount of digital assets locked to Alice in the output 203 of a previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. In Figure 2In this case, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels, and they do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0060] When Alice creates her new transaction Tx1, or at least when she sends the new transaction to the network 106, the previous transaction Tx0 may already be valid and included in the block 151 of the blockchain 150. This transaction may already be included in a block of block 151 at this time, or it may still be waiting in the ordered set 154, in which case the transaction will soon be included in the new block 151. Alternatively, Tx0 and Tx1 can be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 can even be sent after Tx1. The terms "previous" and "subsequent" used in the context of the transaction sequence in this article refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can equally be replaced by "predecessor" and "successor", "ancestor" and "descendant", or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or reach any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child") that points to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. A child that reaches the blockchain node 104 before the parent is considered an orphan. Depending on the node protocol and / or node behavior, it can be discarded or buffered for a period of time to wait for the parent.

[0061] One of the outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which usually include the condition that the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

[0062] The locking script (also known as scriptPubKey) is a piece of code written in a domain - specific language recognized by the node protocol. A particular example of such a language is called "Script" (with S capitalized), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain - specific language that provides the information required to meet the criteria of the locking script. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0063] Thus, in the example shown, the UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P A , which requires Alice's signature Sig P A to redeem UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem UTXO0 valid). [Checksig P A contains the representation (i.e., the hash) of the public key P A in Alice's public - private key pair. The input 202 of Tx1 includes a pointer to Tx1 (e.g., via its transaction ID (TxID0), which in an embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes the unlocking script <Sig P A >, which includes Alice's cryptographic signature created by Alice by applying the private key in her key pair to a predetermined portion of data (sometimes called the "message" in cryptography). The data (or "message") for which Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0064] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check if the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria). In an embodiment, this involves juxtaposing the two scripts:

[0065] <Sig PA> <pa>||[Checksig PA]

[0066] Where "||" represents juxtaposition, "<...>" represents pushing data onto the stack, and "[...]" represents a function composed of a locking script (in this example, a stack-based language). Similarly, the scripts can run one after another using a common stack instead of juxtaposing the scripts. Either way, when run together, the scripts use Alice's public key P A (including in the locking script of the output of Tx0) to authenticate the signature when the unlocking script in the input of Tx1 contains the data of the expected part of Alice's signature. The expected part of the data itself ("message") also needs to be included in order to perform this authentication. In an embodiment, the data signed includes the entire Tx1 (so there is no need to include a separate element to specify the part of the data signed in plain text as it already exists).

[0067] Those skilled in the art will be familiar with the details of authentication through public-private cryptography. Basically, if Alice has encrypted and signed a message using her private key, given Alice's public key and the message in the plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and tagging this to the message as the signature, so that any holder of the public key can authenticate the signature. Therefore, it should be noted that in an embodiment, any reference in this document to signing a specific data fragment or part of a transaction, etc. may mean signing the hash value of that data fragment or part of the transaction.

[0068] If the unlocking script in Tx1 meets one or more conditions specified in the locking script of Tx0 (thus, in the example shown, if Alice's signature is provided and authenticated in Tx1), then blockchain node 104 considers Tx1 valid. This means that blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. Blockchain node 104 will also forward transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that it will be propagated throughout network 106. Once Tx1 is valid and included in blockchain 150, this will define UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid when spending an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Thus, blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (i.e., whether it has formed a valid input for another valid transaction). This is one of the reasons why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of spent transactions 152, but ultimately defining whether a UTXO has been spent depends on whether a valid input for another valid transaction has been formed in blockchain 150.

[0069] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, then this is another basis for invalidation in most transaction models. Thus, such a transaction will not be propagated or included in block 151.

[0070] Note that in a UTXO-based transaction model, a given UTXO needs to be used as a whole. One cannot "leave" a portion of the amount defined as spent in a UTXO while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split between multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1, or pay it to another party.

[0071] In practice, Alice typically also needs to include a fee for Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and thus may not propagate and be included in blockchain 150 even though it is technically valid (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will automatically be provided to the blockchain node 104 that publishes the transaction. For example, assume that the pointer to UTXO0 is the only input of Tx1 and Tx1 has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference can be allocated (or spent) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. Alternatively or additionally, this does not necessarily preclude the transaction fee from being explicitly specified in one of the UTXOs 203 of its own transaction 152.

[0072] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Thus, typically, the assets of a given party 103 are spread across the UTXOs of various transactions 152 throughout blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in blockchain 150. The role of the wallet function of client application 105 is to collate the various UTXO values locked to the corresponding party and not yet spent in other subsequent transactions. To achieve this, it can query a copy of blockchain 150 stored at any one of the Bitcoin nodes 104.

[0073] It should be noted that script code is typically represented schematically (i.e., using non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to specific opcodes of the script language. For example, OP_RETURN is a script language opcode that, when preceded by OP_FALSE at the start of the locking script, creates an unspendable output of the transaction that can store data within the transaction, thereby immutably recording the data in blockchain 150. For example, the data can include a file to be stored in the blockchain.

[0074] Typically, the input of a transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific data segment. In an embodiment, for a given transaction, the signature will sign part of the transaction input as well as part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that is used to select the output to be signed (and thus fixed at the time of signing).

[0075] The locking script, sometimes called "scriptPubKey", means that it typically includes the public key of the party to which the corresponding transaction is locked. The unlocking script, sometimes called "scriptSig", means that it typically provides the corresponding signature. But more generally, in all applications of the blockchain 150, the conditions for UTXO redemption do not necessarily include verifying the signature. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" can be preferably used.

[0076] 3. Side Channel

[0077] As Figure 1 shown, the client applications on each of the computer devices 102a, 120b of Alice and Bob can include additional communication functions. This additional function enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables data to be exchanged outside of the blockchain network. Such communication is sometimes called "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or posting it to the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes called sharing a "transaction template". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0078] A side channel 107 can be established through the same packet-switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 can be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between the devices 102a, 102b of Alice and Bob. Generally, the side channel 107 referred to anywhere in this document can include any one or more links via one or more networking technologies or communication media, which are used for "off-chain" data exchange, that is, data exchange outside the blockchain network 106. In the case of using multiple links, the off-chain link bundle or set as a whole can be referred to as the side channel 107. Therefore, it should be noted that if it is said that Alice and Bob exchange certain information or data, etc. through the side channel 107, this does not necessarily mean that all of this data must be sent through exactly the same link or even the same type of network.

[0079] 4. Payment Channel

[0080] In a typical payment channel implementation, an almost infinite number of payments can be made, but only two transactions need to be added to the blockchain 150. In addition to reducing the number of transactions added to the blockchain and reducing the associated costs, storage, and bandwidth usage, payment channels also offer a speed advantage and enable the payer to refund funds in case things do not go as planned or either party decides not to continue with a certain set of payments. The payment channel implementation is outlined below.

[0081] First, it should be noted that

[0082] "For each Bitcoin transaction, you can have multiple inputs. For each input, there is a parameter called the sequence number. This number indicates whether the transaction including this input has been finalized. If this parameter does not take the maximum value (0xFFFFFFFF), the verification process will look at the lock time field (defined at the transaction level), which specifies the time when the transaction becomes effective, that is, the transaction is invalid before the lock time. This can be useful when the specified time is in the future. (At the time of writing, the farthest lock time you can choose is about 9,500 years in the future.) Before the lock time of a given transaction expires, a new version of the transaction with a larger sequence number can invalidate an earlier version that spends the same input but has a smaller sequence number." [https: / / nchain.com / payment-channels-and-smart-contracts-on-bitcoin / ]

[0083] Now consider the scenario where Alice 103a needs to pay Bob 103b for services, which may require Alice 103a to make multiple payments to Bob 103b over a period of time as the situation demands. Alice 103a anticipates spending up to 15 BSV (in total) to Bob 103b in a possible set of exchanges. To facilitate this, a payment channel is established between Alice 103a and Bob 103b, and the following operations are carried out.

[0084] Alice creates a 2-of-2 multisignature transaction T c , which submits 15 BSV originating from Alice 103a. The multisignature locking script requires two people (Alice and Bob) to sign any transaction that spends the corresponding locked output. At this point, the transaction is not submitted to the blockchain network 106.

[0085]

[0086] Table 1: Funding Transaction T c

[0087] Alice 103a creates a separate refund transaction T r,0 , thereby refunding all the funds in the "multisignature-controlled funds" back to Alice 103a. This transaction includes the nLockTime value. nLockTime is a blockchain transaction parameter that allows a blockchain transaction to be executed only after a specified time has elapsed. Bob 103a signs this blockchain transaction. If there are problems with the exchange between Alice 103a and Bob 103b, after the nLockTime has expired, this refund transaction allows Alice 103a to obtain a refund.

[0088]

[0089] Table 2: Refund Transaction T r,0

[0090] Alice 103a signs the original transaction T c . At this point, Alice 103a and Bob 103b can continue to create new refund transactions to reflect the (off-chain) payments made from Alice 103a to Bob 103b. These refund transactions will reflect the net amount that Alice 103a needs to pay Bob 103b at that point in time. For example, if Alice 103a is to pay Bob 103b 5 BSV, a new refund transaction T r,i is created, which has an output that sends 5 BSV to Bob 103b and sends back 10 BSV to Alice 103a. If Alice 103a needs to pay Bob 103b another 5 BSV, a new refund transaction T r,i+1 , the new refund transaction has an output that sends 10 BSV to Bob 103b and 5 BSV to Alice 103a. For each new refund transaction, assuming agreement on the details, both parties sign the transaction, but do not have to submit the transaction to the network 106.

[0091]

[0092] Table 3: Refund Transaction T r,1

[0093]

[0094] Table 4: Refund Transaction T r,2

[0095] It should be noted that each subsequent refund transaction created has a lower nLockTime than the previous refund transaction and a higher sequence number:

[0096] s r,i+1 <S i,i

[0097] If one party refuses to sign any T r,i then the aggrieved party can only submit T r,i-1 . In the worst-case scenario, Alice 103a signs T r,0 and submits it to the network 106 to recover all her funds (after the nLockTime has expired). The final refund transaction constructed represents the net amount of funds transferred from Alice 103a to Bob 103b. This transaction is submitted to the network 106. The refund transaction submitted to the blockchain network 106 is referred to herein as the settlement transaction.

[0098] 6. Facilitating Blockchain Payments

[0099] Embodiments of the present disclosure provide an intermediary 303 for facilitating payments between one or more first parties 301 and second parties 302. In some embodiments, as Figure 3 and Figure 4 shown, the first party 301 is considered the payer, while the second party 302 is considered the recipient. In other embodiments, as Figure 5 shown, the second party 302 is considered the payer and multiple first parties 301 are considered the recipients.

[0100] Figure 3 An exemplary system 300 is shown in which an intermediary 303 is used to facilitate payments between a first party 301 and a second party 302. The first party 301, the intermediary 303, and the second party can be configured to perform as described above with reference to Figure 1 and Figure 2 Any actions described as being performed by Alice 103a and / or Bob 103b. In these embodiments, a second party 302 may provide corresponding goods and / or services to a first party 301 in exchange for payment.

[0101] Figure 4 An exemplary system 400 is shown in which an intermediary party 303 is used to facilitate payments between a plurality of first parties 301 and second parties 302. Each first party 301, intermediary party 303, and second party may be configured to perform any actions described above with reference to Figure 1 and Figure 2 Any actions described as being performed by Alice 103a and / or Bob 103b. In these embodiments, a second party 302 may provide corresponding goods and / or services to each first party 301 in exchange for payment.

[0102] Each first party (whether there is a single first party 301 or multiple first parties 301) establishes a corresponding payment channel with the second party. Each first party 301 and second party 302 establish a corresponding payment channel by generating a corresponding channel opening transaction. The channel opening transaction may also be referred to as an initial transaction or a funding transaction. Each corresponding channel opening transaction includes an input signed by the corresponding first party 301. That is, the input references the output of the previous transaction, where the output is controlled by the public key owned by the corresponding first party 301 (i.e., locked to that public key). Each corresponding channel opening transaction includes an output locked to the public key of the corresponding first party 301 and the public key of the second party 302 (e.g., the output may be a multi-signature output). Unless the context otherwise requires, each reference herein to the public key of a party may mean the same public key or different public keys owned by that party. The output of the corresponding channel opening transaction locks a corresponding maximum amount, i.e., the quantity (e.g., satoshis) of the underlying digital asset of the blockchain 150.

[0103] The second party 302 sends one or more corresponding channel close transaction templates for each respective payment channel, i.e., for each first party 301 with which the second party 302 has established a respective payment channel by generating a respective channel open transaction. The channel close transaction templates may also be referred to as final transaction templates or refund transaction templates. For each payment channel, each respective channel close transaction template among the one or more respective channel close transaction templates includes a respective input that references an output of the respective channel open transaction used to open the payment channel. This input is signed by the second party 302. In some examples, the signature of the second party may sign all outputs in the output of the respective channel close transaction template. Each respective payment channel close transaction template among the one or more respective payment channel close transaction templates includes a respective output locked to the public key of the respective first party 301 and a respective output locked to the public key of the second party 302. The output locked to the public key of the first party 301 locks a first amount of the respective maximum amount locked by the output of the respective channel open transaction. Similarly, the output locked to the public key of the second party 302 locks a second amount of the respective maximum amount locked by the output of the respective channel open transaction. The sum of the first amount and the second amount is at most equal to the respective maximum amount. As discussed below, the first amount and the second amount may be less than the maximum amount. It should be noted that the close transaction templates are called templates because they lack at least one data item, in this case, the at least one data item is the signature of the respective first party 301.

[0104] For each respective payment channel, the intermediary party 303 obtains the respective signature in the respective input of at least one respective channel close transaction template to be included in the respective channel close transaction template from the respective first party 301, thereby completing the template and forming the respective channel close transaction. The first party 301 may send only the signature, or the first party 301 may send the entire transaction. For example, the intermediary party 303 may first send one or more transaction templates to the first party 301 for signature.

[0105] For each respective payment channel, the intermediary party 303 selects one respective channel close transaction in the respective channel close transaction to close the payment channel by having the closed channel transaction be submitted to the blockchain network 106. The transaction used to close the payment channel is called the final channel close transaction. The intermediary party 303 may submit the final channel close transaction to the blockchain network 106, or the intermediary party 303 may send the final channel close transaction to the second party 302, who may submit the final channel close transaction to the blockchain network 106. The selected transaction may be the transaction with the highest amount locked to the public key of the second party 302.

[0106] A channel opening transaction and / or a channel closing transaction may include metadata related to a payment associated with a particular payment channel, such as an identifier of the corresponding first party 301, an identifier of the second party 302, a payment reference, etc.

[0107] In some examples, the intermediary party 303 may deduct a service fee for facilitating the payment, as shown in the following Tables 5 and 6 (for the scenario where there is a single first party 301), which respectively show examples of channel opening transactions and channel closing transactions. Another example is shown in the following Tables 7 and 8 (for the scenario where there are multiple first parties 301), which respectively show examples of channel opening transactions and channel closing transactions.

[0108] Figure 5 An exemplary system 500 is shown, in which an intermediary party 303 is used to facilitate payments between multiple first parties 301 and a second party 302. Each first party 301, intermediary party 303, and second party may be configured to perform any actions performed by Alice 103a and / or Bob 103b as described above with reference to Figure 1 and Figure 2 The system 500 may include any number (n) of first parties 301. In these embodiments, each first party 301 may provide a corresponding good and / or service to the second party 302 in exchange for a payment.

[0109] Similar to the above embodiments, a corresponding payment channel is established between each respective first party 301 and the second party 302. A corresponding channel opening transaction is used to open each respective payment channel. Each corresponding channel opening transaction includes an input signed by the second party 302. That is, the input references the output of the previous transaction, where the output is controlled by the public key owned by the second party 302 (i.e., locked to that public key). Each corresponding channel opening transaction includes an output locked to the public keys of the corresponding first party 301 and the second party 302 (e.g., the output may be a multi-signature output). The output of the corresponding channel opening transaction locks the corresponding maximum value, i.e., the amount of the underlying digital asset of the blockchain 150 (e.g., satoshi).

[0110] The second party 302 sends one or more corresponding channel closing transaction templates for each respective payment channel to the intermediary party 303, i.e., for each first party 301 with which the second party 302 has established a respective payment channel by generating a respective channel opening transaction. For each payment channel, each respective channel closing transaction template among the one or more corresponding channel closing transaction templates includes a respective input that references an output of the respective channel opening transaction used to open the payment channel. This input is signed by the second party 302. In some examples, the signature of the second party may sign all outputs in the output of the respective channel closing transaction template. Each respective payment channel closing transaction template among the one or more corresponding payment channel closing transaction templates includes a respective output locked to the public key of the respective first party 301 and a respective output locked to the public key of the second party 302. The output locked to the public key of the first party 301 locks a first amount of the respective maximum amount locked by the output of the respective channel opening transaction. Similarly, the output locked to the public key of the second party 302 locks a second amount of the respective maximum amount locked by the output of the respective channel opening transaction. The sum of the first amount and the second amount is at most equal to the respective maximum amount. As discussed below, the first amount and the second amount may be less than the maximum amount.

[0111] For each respective payment channel, the intermediary party 303 selects one respective channel closing transaction template from the respective channel closing transaction templates and sends the selected channel closing transaction template to the respective first party 301. The selected transaction may be the transaction with the highest amount locked to the public key of the respective first party 301. Then, the first party 301 signs the respective channel closing transaction template, thus completing the transaction. Then, the payment channel is closed using the completed channel closing transaction by submitting the channel closing transaction to the blockchain network 106.

[0112] In some examples, the intermediary party 303 may deduct a service fee for facilitating the payment, examples of which are shown in Tables 9 and 10 below, which respectively show examples of channel opening transactions and channel closing transactions.

[0113] 7. Payment Channel Aggregator Example

[0114] This section describes an exemplary payment channel aggregator (PCA) according to an embodiment of the present disclosure, which is a system that helps to introduce an intermediary party (I - Ivan) between two parties (A - Alice and B - Bob) who previously directly used payment channels between themselves (Alice and Bob).

[0115] 7.1 One - to - One

[0116] Figure 3 An exemplary system 300 is shown for facilitating payments between a first party 301 and a second party 302 using an intermediary 303. For convenience, the first party 303 is referred to as Alice 103a, the second party as Bob 103b, and the intermediary as Ivan 303. For one-to-one payments, it is assumed that a party, Alice 103a, will intermittently pay Bob 103b for services or goods. This was previously done through a payment channel between the two parties. However, in the PCA of this scenario, an intermediary (Ivan) 303 is utilized to handle payments from Alice 103a to Bob 103b.

[0117] If Ivan 303 is not trusted, Ivan is responsible for collecting off-chain transactions (signed by Alice 103a) and then submitting settlement transactions to the blockchain 150. These off-chain transactions have been signed by Bob 103b. This may require Bob 103b to know in advance the possible values of these off-chain payments. This may apply to examples such as Netflix, where monthly payments are a known amount and thus the total cost for multiple months is predictable.

[0118] PCA involves the following steps:

[0119] - Ivan 303, Alice 103a, and Bob 103b reach an agreement that Ivan 303 will collect payments (off-chain transactions signed by Alice 103a) from Alice 103a and then Ivan 303 will submit settlement transactions for these payments to the blockchain 150 (e.g., before a deadline).

[0120] - Alice 103a and Bob 103b create a payment channel between themselves. This includes creating a funding transaction that can refund an amount Max BSV to Alice 103a.

[0121] - For each payment (refund transaction) that Alice 103a can make to Bob 103b, Bob 103b creates a transaction template that includes appropriate details in the output, signs the transaction, and provides the set of pre-signed transactions to the intermediary Ivan 303. Bob 103a signs the transaction using the sighash flag (SIGHASH_ALL|ANYONECANPAY) that signs all outputs of the transaction.

[0122] - Additional (e.g., OP_RETURN) outputs can be included in each refund transaction that contain various metadata related to the transaction, such as Netflix subscription paid months, other customer and provider details.

[0123] - Ivan 303 collaborates with Alice 103a, who signs the refund transactions each time an agreement is reached. For example, if the monthly Netflix subscription costs 10 BSV, at the end of month i, Alice 203a signs the refund transaction for 10i BSV. Then, Alice 103a sends the signed transaction to Ivan 303.

[0124] - At the end of Alice's payment (e.g., when the Netflix annual subscription expires, or when Alice 103a refuses to sign other refund transactions with larger cumulative fees), Ivan 303 submits the final refund transaction signed by Alice (the transaction with the highest payment value) to the blockchain 150 as a settlement transaction, and the payment channel is closed.

[0125] - A service fee proportional to the cumulative fees received by Bob 103b can be paid to the intermediary Ivan 303. This serves as payment and incentive for Ivan to submit the transaction and obtain a higher cumulative settlement payment from Alice 103a. This service fee sc is included in each refund transaction within the refund transactions.

[0126] For the payment channel utilized, examples of one of the refund transactions in the fund transaction T c and the refund transaction T r,i are shown in Table 5 and Table 6 respectively. For simplicity purposes, transaction fees are not depicted.

[0127]

[0128] Table 5: Fund Transaction, PCA, One-to-One.

[0129]

[0130] Table 6: Refund Transaction, PCA, One-to-One.

[0131] After Ivan 303 submits the settlement refund transaction, Bob (Netflix) 103v will receive the total payment (minus Ivan's service fee) from Alice 103a. It should be noted that Ivan 303 can pass the transaction to Bob 103b and let Bob 103b review the final transaction before Bob 103b himself submits the transaction to the blockchain 150.

[0132] Similarly, Bob (Netflix) 103b may not necessarily have to wait for Ivan 303 to submit a settlement refund transaction before requesting a review of the refund transaction signed by Alice. In the Netflix example, Bob 103b can request a copy of the latest refund transaction signed by Alice every quarter of the year (March, June, September, etc.). These checkpoints allow Bob 103b to recover some funds if Ivan 303 fails to submit an updated iteration of the transaction refunded by Alice. In such a case, Bob 103b must balance the frequency of the checkpoints against the risk of losing funds and the inconvenience of frequent check-ins.

[0133] 7.2 Many - to - One

[0134] Figure 4 An exemplary system 400 is shown for facilitating payments between a plurality of first parties 301a, 301b... 301n and a second party 302 using an intermediary 303. For convenience, each first party 303 is referred to as Alice 103a, the second party is referred to as Bob 103b, and the intermediary is referred to as Ivan 303. For many-to-one, assume there are multiple Alices {Alice j |j ∈ [1, n]} who will intermittently pay Bob 103b for services or goods. (For example, multiple subscribers need to pay Netflix monthly).

[0135] For each subscriber Alice j , this was previously performed through separate corresponding payment channels (e.g., Netflix) between each Alice and Bob.

[0136] However, using PCA, the intermediary Ivan 303 is utilized to manage these payments. This intermediary 303 will accept iterative payments for each channel, and subsequently the settlement transaction will ultimately be submitted to the blockchain 150. Then, Ivan 303 will forward the aggregate value of these n settlement transactions as a payment to Bob 103b.

[0137] If Ivan 303 is not trusted, Ivan is responsible for collecting off-chain transactions for a set of Alice j →Bob payment channels, and then submitting the settlement transaction for each payment channel to the blockchain 150. This operates in the same manner for each Alice j as described in the one-to-one case in the previous section.

[0138] For the payment channels utilized, examples of a funds transaction T c and a refund transaction are shown in Tables 7 and 8 respectively.

[0139]

[0140] Table 7: Fund Transaction, PCA, Many-to-One.

[0141] It should be noted that Bob 103b receives payment in the refund transaction, while Ivan 303 obtains his service fee (see Table 8).

[0142]

[0143] Table 8: Refund Transaction, PCA, Many-to-One.

[0144] 7.3 One - to - Many

[0145] Figure 5 An exemplary system 500 is shown for facilitating payments between a second party 302 and a plurality of first parties 301a, 301b... 301n using an intermediary 303. For convenience, the second party 302 is referred to as Alice 103a, each first party is referred to as an instance of Bob 103b, and the intermediary is referred to as Ivan 303. For one-to-many, it is assumed that there are multiple Bobs {Bob k | k ∈ [1, m]} and one Alice. An example is a person subscribing to multiple services. Consider Alice 103a who subscribes to subscription services such as Netflix, Amazon Prime, Disney+, etc. Instead of dealing with multiple service providers personally, Alice 103a makes a single payment to the intermediary Ivan 303, who then processes the payments to each provider.

[0146] In the described scenario, the PCA technique is used, and the intermediary Ivan 303 is again utilized to manage these payments.

[0147] If Ivan 303 is not trustworthy, the risk is that if Alice 103a pays the service fee sc to Ivan 303 in advance, Ivan 303 may act maliciously and never submit one, multiple, or all of the settlement transactions in the settlement transactions of the payment channels for the corresponding Bob k payments.

[0148] To mitigate this risk, a payment channel is established between Alice 103a and Bob 103b, and Ivan 303 is responsible for sending the appropriate iterations of the off-chain transactions k to each Bob Alice 103a communicates with Ivan 303 in advance or at various times before the existence of the payment channel regarding when Ivan 303 should stop passing the refund transactions signed by Alice to Bob k

[0149] Then, Alice 103a signs for the payment to Bob k ​Sign all possible iterations of the refund transactions for each of the k payment channels. Since Ivan 303 is not trustworthy, Alice 103a can only sign up to the iterations of the refund transactions that she (Alice) is willing to pay back to Bob k for the refund transaction iterations For example, only sign the refund transactions for Netflix (Bob1) up to 6 months in advance, only sign the transactions for Amazon Prime (Bob2) in the first 8 months, etc.

[0150] The refund transaction may include a service fee This service fee is paid to Ivan 303 for the service of communicating the off-chain transaction to Bob k The service fee may be proportional to the iteration of the refund transaction. Since Ivan 303 will thus have more incentive to submit refund transactions with higher iterations to Bob k Alice 103a can therefore only pre-sign the iterative refund transactions up to the level she is willing to pay

[0151] For the payment channels used to pay Bob k the funding transactions and refund transactions Examples of one of the refund transactions are shown in Tables 9 and 10 respectively

[0152]

[0153] Table 9: Funding transaction, PCA, one-to-many

[0154] It should be noted that Ivan 303 obtains his service fee in the refund transaction. See Table 10

[0155]

[0156] Table 10: Refund transaction, PCA, one-to-many

[0157] 8. Further Comments

[0158] Once the disclosure of this document is given, other variations or use cases of the disclosed technology may become obvious to those skilled in the art. The scope of this disclosure is not limited by the described embodiments, but only by the appended claims

[0159] ​For example, some of the above embodiments have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of the blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any reference above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 can be replaced by reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0160] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin node 104 performs at least all of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing the blocks (keep in mind that these entities are not considered nodes of the preferred Bitcoin network 106).

[0161] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150 but not all of them. For example, on these other blockchain networks, the term "node" may be used to refer to a network entity that is configured to create and publish the blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0162] Even more generally, any reference above to the term "Bitcoin node" 104 can be replaced by the term "network entity" or "network element", where such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functions of such a network entity / element can be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0163] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and any type of suitable consensus mechanism may be used in general embodiments, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is typically referred to as a validator. A blockchain node may lock up its tokens for a period of time in order to have the opportunity to become a validator. Generally, the node that locks up the maximum stake for the longest time is most likely to become the next validator.

[0164] It should be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements.

[0165] Statement 1. A computer-implemented method for facilitating a corresponding payment between one or more corresponding first parties and a second party, wherein each corresponding first party and the second party are configured to create a corresponding payment channel by generating a corresponding channel opening transaction, the corresponding channel opening transaction including a corresponding input signed by the corresponding first party, and a corresponding output locked to the corresponding public key of the corresponding first party and the public key of the second party, wherein the corresponding output locks a corresponding maximum value; wherein the method is performed by an intermediary party, and the method includes, for each corresponding first party:

[0166] Obtaining, from the second party, one or more corresponding channel closing transaction templates, wherein each corresponding channel closing transaction template includes a corresponding input, and a first corresponding output locked to the corresponding public key of the corresponding first party and a second corresponding output locked to the public key of the second party, the corresponding input of the corresponding channel closing transaction template referring to the corresponding output of the corresponding channel opening transaction and including a corresponding signature of the second party, wherein the first corresponding output locks a corresponding first amount of the corresponding maximum value, and wherein the second corresponding output locks a corresponding second amount of the corresponding maximum value;

[0167] Obtaining one or more corresponding channel closing transactions, each corresponding channel closing transaction being generated by including a corresponding signature of the corresponding first party in the corresponding input of the corresponding channel closing transaction template; and,

[0168] Sending the selected corresponding channel closing transaction among the one or more corresponding channel closing transactions to a blockchain network, or sending the selected corresponding channel closing transaction to the second party.

[0169] Statement 2. The method according to statement 1, wherein the one or more corresponding first parties include a plurality of corresponding first parties.

[0170] Statement 3. The method according to statement 1 or 2, wherein the corresponding signature of the second party included in the corresponding input of the corresponding channel closing transaction signs each output of the corresponding channel closing transaction.

[0171] Statement 4. A computer-implemented method for facilitating a plurality of corresponding payments between a plurality of corresponding first parties and a second party, wherein each corresponding first party and the second party are configured to create a corresponding payment channel by generating a corresponding channel opening transaction, the corresponding channel opening transaction including a corresponding input signed by the second party, and a corresponding output locked to the corresponding public key of the corresponding first party and the public key of the second party, wherein the corresponding output locks a corresponding maximum value; wherein the method is performed by an intermediary party, and the method includes, for each corresponding first party:

[0172] Obtaining, from the second party, one or more corresponding channel closing transaction templates, wherein each corresponding channel closing transaction template includes a corresponding input, and a corresponding first output locked to the corresponding public key of the corresponding first party and a corresponding second output locked to the public key of the second party, the corresponding input of the corresponding channel closing transaction template referring to the corresponding output of the corresponding channel opening transaction and including the corresponding signature of the second party, wherein the corresponding first output locks a corresponding first amount of the corresponding maximum value, and wherein the corresponding second output locks a corresponding second amount of the corresponding maximum value; and,

[0173] Sending, to the corresponding first party, the selected corresponding channel closing transaction template among the one or more corresponding channel closing transaction templates.

[0174] Statement 5. The method according to any one of the preceding statements, wherein each corresponding channel closing transaction template includes a corresponding third output locked to the public key of the intermediary party, and wherein the corresponding third output locks a service fee value, wherein the corresponding first amount of the corresponding maximum value is equal to the corresponding maximum value minus a third amount of the corresponding maximum value and then minus the service fee value, and the corresponding second amount of the corresponding maximum value is equal to the third amount of the corresponding maximum value plus the service fee value.

[0175] Statement 6. The method according to any one of the preceding statements, wherein, for each corresponding first party, the selected corresponding channel closing transaction is the corresponding channel closing transaction having the highest corresponding second amount of the corresponding maximum value locked by the second output of the corresponding channel closing transaction.

[0176] Statement 7. The method according to any one of the preceding statements, wherein the corresponding channel opening transaction and / or the corresponding channel closing transaction includes metadata related to the corresponding payment.

[0177] Statement 8. The method according to statement 1 or any of its dependent statements, wherein the second party provides a corresponding good and / or a corresponding service to the corresponding first party in exchange for the corresponding payment.

[0178] Statement 9. The method according to statement 4 or any of its dependent statements, wherein each corresponding first party provides a corresponding good and / or a corresponding service to the second party in exchange for the corresponding payment.

[0179] Statement 10. A computer device, the computer device comprising:

[0180] A memory, the memory including one or more memory units; and,

[0181] A processing device, the processing device including one or more processing units, wherein the memory stores code configured to run on the processing device and, when run on the processing device, execute the method according to any one of statements 1 to 9.

[0182] Statement 11. A computer program, the computer program being contained on a computer-readable memory and configured to, when run on one or more processors, execute the method according to any one of statements 1 to 9.

[0183] According to another aspect disclosed herein, a method can be provided, the method including actions of the intermediary party and one or both of the following: i) the one or more first parties; ii) the second party.

[0184] According to another aspect disclosed herein, a method can be provided, the method including a computer device of the intermediary party and one or both of the following: i) the one or more first parties; ii) the second party.< / pa>

Claims

1. A computer-implemented method for facilitating corresponding payments between one or more respective first parties and a second party, wherein each respective first party and the second party are configured to create a corresponding payment channel by generating a corresponding channel opening transaction, the corresponding channel opening transaction including a corresponding input signed by the respective first party, and a corresponding output locked to the respective public key of the respective first party and the public key of the second party, wherein the corresponding output locks a corresponding maximum amount; wherein the method is performed by an intermediary party, and the method includes, for each respective first party: Obtaining, from the second party, one or more corresponding channel closing transaction templates, wherein each corresponding channel closing transaction template includes a corresponding input, and a first corresponding output locked to the respective public key of the respective first party and a second corresponding output locked to the public key of the second party, the corresponding input of the corresponding channel closing transaction template referring to the corresponding output of the corresponding channel opening transaction and including the corresponding signature of the second party, wherein the first corresponding output locks a first amount of the corresponding maximum amount, and wherein the second corresponding output locks a second amount of the corresponding maximum amount; Obtaining one or more corresponding channel closing transactions, each corresponding channel closing transaction being generated by including the corresponding signature of the respective first party in the corresponding input of the corresponding channel closing transaction template; and Sending a selected corresponding channel closing transaction among the one or more corresponding channel closing transactions to a blockchain network, or sending the selected corresponding channel closing transaction to the second party.

2. The method according to claim 1, wherein, The one or more respective first parties include a plurality of respective first parties.

3. The method according to claim 1 or 2, wherein The corresponding signature of the second party included in the corresponding input of the corresponding channel closing transaction signs each output of the corresponding channel closing transaction.

4. A computer-implemented method for facilitating multiple corresponding payments between a plurality of respective first parties and a second party, wherein each respective first party and the second party are configured to create a corresponding payment channel by generating a corresponding channel opening transaction, the corresponding channel opening transaction including a corresponding input signed by the second party, and a corresponding output locked to the respective public key of the respective first party and the public key of the second party, wherein the corresponding output locks a corresponding maximum amount; wherein the method is performed by an intermediary party, and the method includes, for each respective first party: Obtaining, from the second party, one or more corresponding channel closing transaction templates, wherein each corresponding channel closing transaction template includes a corresponding input, and a first corresponding output locked to the respective public key of the respective first party and a second corresponding output locked to the public key of the second party, the corresponding input of the corresponding channel closing transaction template referring to the corresponding output of the corresponding channel opening transaction and including the corresponding signature of the second party, wherein the first corresponding output locks a first amount of the corresponding maximum amount, and wherein the second corresponding output locks a second amount of the corresponding maximum amount; and Send the selected corresponding channel closing transaction template in the one or more corresponding channel closing transaction templates to the corresponding first party.

5. The method according to any one of the preceding claims, wherein each corresponding channel closing transaction template includes a corresponding third output locked to the public key of the intermediary party, and wherein the corresponding third output locks a service fee value, wherein the corresponding first amount of the corresponding maximum value is equal to the corresponding maximum value minus the third amount of the corresponding maximum value and then minus the service fee value, and the corresponding second amount of the corresponding maximum value is equal to the third amount of the corresponding maximum value plus the service fee value.

6. The method according to any one of the preceding claims, wherein, For each corresponding first party, the selected corresponding channel closing transaction is the corresponding channel closing transaction having the highest corresponding second amount of the corresponding maximum value locked by the second output of the corresponding channel closing transaction.

7. The method according to any one of the preceding claims, wherein, The corresponding channel opening transaction and / or the corresponding channel closing transaction includes metadata related to the corresponding payment.

8. The method according to claim 1 or any of its dependent claims, wherein, The second party provides corresponding goods and / or corresponding services to the corresponding first party in exchange for the corresponding payment.

9. The method according to claim 4 or any of its dependent claims, wherein, Each corresponding first party provides corresponding goods and / or corresponding services to the second party in exchange for the corresponding payment.

10. A computer device, the computer device comprising: a memory, the memory including one or more memory units; and a processing device, the processing device including one or more processing units, wherein the memory stores code configured to run on the processing device, and the code is configured to, when running on the processing device, execute the method according to any one of claims 1 to 9.

11. A computer program, the computer program being contained on a computer-readable memory and configured to, when running on one or more processors, execute the method according to any one of claims 1 to 9.

Images