Payment channel aggregator

Abstract

A computer-implemented method for facilitating payment between a plurality of first parties and a second party, the method comprising: executing a respective payment channel between each respective first party and an intermediate party by: obtaining a channel opening transaction, the channel opening transaction comprising a locked maximum output; obtaining one or more channel closing transactions, the one or more channel closing transactions comprising a final channel closing transaction, the final channel closing transaction comprising a first output and a second output, the first output locking a first amount of the maximum and the second output locking a second amount of the maximum; and generating a payment transaction, where the payment transaction includes a plurality of inputs, each input referencing a second output of the final channel closing transaction, and an output locked to a public key of the second party, the output lock based on a value of a sum of the second amounts locked by the second output.

Description

Technical Field

[0001] The present disclosure relates to a method for facilitating multiple corresponding payments between multiple corresponding 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 multiple 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 a new block. The process of creating a new block is generally referred to as "mining", which involves each of multiple 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, a blockchain protocol can allow additional user data or data indexes to be stored in a transaction. There is no predefined 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 a 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 the 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 incentivize reporting and prevent improper behavior. 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. A spendable output is sometimes called a UTXO ("unspent transaction output"). 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 a digital token or asset. 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 that points 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 that defines 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 the 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 the new block to be recorded in the blockchain.

[0008] Another type of transaction model is the account-based model. In this case, each transaction does not define the amount of the transfer by referring to the UTXO of a previous transaction in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored separately by the 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 protocol for signing and submitting transactions, which allows 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 the iterative negotiation, or can be the sum of a set of regular 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 copy of a valid and secure transaction to the streaming platform. If needed, the streaming platform can submit the transaction to the blockchain. Each month's 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 / service provider. However, as recognized herein, in some cases, an intermediary party may be required.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for facilitating multiple corresponding payments between multiple corresponding first parties and a second party, where the method is performed by an intermediary party and includes:

[0013] Execute a corresponding payment channel between each respective first party and the intermediary party, where executing the corresponding payment channel includes:

[0014] Obtain 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 corresponding first party, the corresponding output being locked to the corresponding public key of the corresponding first party and the public key of the intermediary party, where the corresponding output locks a corresponding maximum value;

[0015] Obtain one or more corresponding channel closing transactions, the one or more corresponding channel closing transactions including a corresponding final channel closing transaction, where the corresponding final channel closing transaction includes a corresponding input (the corresponding input referencing the corresponding output of the corresponding channel opening transaction and including the corresponding signature of the corresponding first party and the signature of the intermediary 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 intermediary party, where the corresponding first output locks a corresponding first amount of the corresponding maximum value, and where the corresponding second output locks a corresponding second amount of the corresponding maximum value; and,

[0016] Generate a payment transaction, where the payment transaction includes a plurality of corresponding inputs (each corresponding input referencing the corresponding second output of the corresponding final channel closing transaction and including the signature of the intermediary party), and an output locked to the public key of the second party, where the output locks a value based on the sum of the corresponding second amounts locked by the corresponding second outputs.

[0017] In this regard, the intermediary party is used to facilitate payments between multiple payers and payees. The intermediary party establishes a payment channel with each payer. After each payment channel is closed (i.e., settled), the intermediary party submits a payment transaction to the blockchain, the payment transaction transferring a certain amount to the payee based on the result of each individual payment channel.

[0018] The intermediary party (e.g., Ivan) collects funds from multiple payers (e.g., multiple instances of Alice) on behalf of the payee (e.g., Bob), and then pays Bob. For example, a streaming platform may outsource the collection of its subscription fees to a third-party collection agency. The agency collects all subscription fees and then pays the cumulative fees to the platform through one or more payments. This process is more efficient than each user having to interact with the streaming platform individually.

[0019] According to another aspect disclosed herein, there is provided a computer-implemented method for facilitating multiple corresponding payments between multiple corresponding first parties and a second party, where the method is executed by an intermediary party and includes:

[0020] Obtain a fund transaction generated by the second party, where the fund transaction includes an input and an output, the input contains the signature of the second party, and the output is locked to the public key of the intermediary, where the amount locked in the output is at least equal to the sum of a plurality of corresponding maximum values; and,

[0021] Execute a corresponding payment channel between each corresponding first party and the intermediary, where executing the corresponding payment channel includes:

[0022] Obtain a corresponding channel opening transaction, where the corresponding channel opening transaction includes a corresponding input signed by the intermediary and a corresponding output locked to the corresponding public key of the corresponding first party and the public key of the intermediary, where the corresponding output locks the corresponding maximum value;

[0023] Obtain one or more corresponding channel closing transactions, where the one or more corresponding channel closing transactions include a corresponding final channel closing transaction, where the corresponding final channel closing transaction includes a corresponding input (the corresponding input references the corresponding output of the corresponding channel opening transaction and includes the corresponding signature of the corresponding first party and the signature of the intermediary), 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 intermediary, where the corresponding first output locks a corresponding first amount of the corresponding maximum value, and where the corresponding second output locks a corresponding second amount of the corresponding maximum value.

[0024] In this regard, the intermediary is used to facilitate payments between a payer and a plurality of payees. The intermediary receives a fund transaction from the payer, and the payer sends a certain amount to the intermediary. Then, the intermediary establishes a payment channel with each payee. The intermediary closes (i.e., settles) the payment channel with each payee, for example, after an agreed payment amount, after an agreed time period, in response to a request from the payer, etc.

[0025] In this case, a party (e.g., Alice) can subscribe to multiple services (e.g., multiple instances of Bob), and in this case, it is more convenient (and more efficient) to let the intermediary distribute these payments to each service on his / her behalf.

[0026] In both of these aspects, using an intermediary increases the privacy of the parties (payer and payee) because from an external perspective, a third party cannot determine the source and destination of the payment because the source or the destination is replaced by the intermediary. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] 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:

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

[0029] Figure 2 schematically shows some examples of transactions that can be recorded in a blockchain;

[0030] Figure 3 shows an example of a one-to-one payment channel;

[0031] Figure 4 shows an example of a many-to-one payment channel;

[0032] Figure 5 shows an example of a one-to-many payment channel. Detailed implementation manners

[0033] 1. Exemplary System Overview

[0034] Figure 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet switching network 101, typically a wide area network such as the Internet. The packet switching network 101 includes a plurality of blockchain nodes 104, and the plurality of blockchain nodes 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.

[0035] 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.

[0036] 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, as long as each blockchain node 150 stores the block headers of each block 151 (discussed below), the blockchain 150 can perform data pruning. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a 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 digital assets 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 solution for unlocking and thus redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0037] 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 of the early original transactions 152 in the blockchain 150 point to the genesis block 153 rather than a previous transaction.

[0038] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby 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.

[0039] 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 a predecessor in a logical sequence linked by a pointer and not necessarily the creation time or send time in a time sequence, and thus does not necessarily rule out the case of creating or sending transactions 152i, 152j out of order (see the discussion of orphan transactions below). The previous transaction 152i can equally be referred to as a preceding transaction or a predecessor transaction.

[0040] The input of the current transaction 152j also includes an input authorization, such as the signature of user 103a to which the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be encrypted and 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 that aggregate the amounts in the multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0041] 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 typically 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 typically 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 can be determined 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 throughout the network of blockchain nodes 104.

[0042] 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 handler 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.

[0043] 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 specific type of proof of work puzzle and does not exclude other types. The characteristic of a hash function is that its output is unpredictable relative to its input. Therefore, this search can only be carried out by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0044] The first blockchain node 104 that solves the puzzle announces the solution of the puzzle on network 106, providing the solution as proof, and then other blockchain nodes 104 in the network can easily check the solution (once the solution of 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 executing 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.

[0045] It should be noted that different blockchain nodes 104 competing to solve a puzzle at any given time can do so based on different snapshots of the pool 154 of transactions that have not been published 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 unpublished transactions. Then, the blockchain nodes 104 continue to compete to create a block from the newly defined ordered pool 154 of unpublished 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.

[0046] 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 it can also be called a "genesis transaction" or a "generation transaction". It typically forms the first transaction of the new block 151n. Proof-of-work signals the intention of the node that constructs the new block to follow the protocol rules, thus allowing the specific transaction to be redeemed later. Before this 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 creates the block 151n in which the transaction is published. This fee is commonly referred to as the "transaction fee" and is discussed below.

[0047] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server that includes 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.

[0048] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its respective role according to the blockchain node protocol and process transactions 152. 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 an application layer or in one or more applications in a lower layer such as an operating system layer or a protocol layer or any combination of these layers.

[0049] 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 transactions. 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., have obtained a copy of the blockchain from a blockchain node 104).

[0050] Some or all of the parties 103 can be connected as part of different networks, such as a network overlaying the blockchain network 106. 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 a 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 for convenience, they are not shown. 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 in this document can be replaced by "first party" and "second party" respectively.

[0051] 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 a corresponding instance 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 smartphone, or a wearable device such as a smartwatch. 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.

[0052] 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.

[0053] 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, and then spread it in the network of blockchain nodes 104, so as to be 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.

[0054] Note: Although various client functions can be described as integrated into a given client application 105, this is not necessarily restrictive. Instead, any client function described herein can be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application being a plugin of another application. More generally, client functions can 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 the client application 105, but it should be understood that this is not restrictive.

[0055] 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 in 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 the blockchain 150 for any transactions in which a corresponding party 103 is the recipient (or actually check the transactions of other parties in the blockchain 150, since in an embodiment, 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 a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify a transaction 152 according to a 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.

[0056] 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). She then 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 certain conditions to become "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions can be simply a built-in function of the node protocol or defined by a combination of the script and the node protocol.

[0057] 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.

[0058] Once in the pending 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 immutably 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 immutably recorded.

[0059] 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).

[0060] 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 does not define the amount transferred by referring to the UTXO of a previous transaction in the past transaction sequence, but rather by referring to the absolute account balance. The current state of all accounts is separately stored in the blockchain by the nodes of the network and is continuously updated. In such a system, transactions are ordered using the running transaction record (also known as the "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.

[0061] 2. UTXO - based Model

[0062] 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.

[0063] 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 the source of an input 202 for 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.

[0064] For example, let's 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 don't 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 unspent outputs 203 locked to Alice.

[0065] When Alice creates her new transaction Tx1, or at least when she sends this 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 one of the blocks in block 151 at this time, or it may still be waiting in the ordered set 154, in which case this 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 doesn't 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") won't 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.

[0066] 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.

[0067] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific 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.

[0068] 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., 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., through its transaction ID (TxID0), which is the hash value of the entire transaction Tx0 in the embodiment). The input 202 of Tx1 includes the 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.

[0069] 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 whether the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria). In the embodiment, this involves juxtaposing the two scripts:

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

[0071] Where "||" represents concatenation, "<...>" represents pushing data onto the stack, and "[...]" represents a function composed of a locking script (in this example, a stack-based language). Similarly, scripts can run one after another using a common stack instead of concatenating 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 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 being signed in plain text as it already exists).

[0072] 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 herein to signing a specific data fragment or part of a transaction, etc. can mean signing the hash value of that data fragment or part of the transaction.

[0073] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (and 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 adds Tx1 to the pending transactions ordered pool 154. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that it can be propagated throughout network 106. Once Tx1 is valid and included in blockchain 150, this marks 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 already been spent (i.e., whether it has already 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 whether a UTXO is considered spent depends on whether it has formed a valid input for another valid transaction in blockchain 150.

[0074] 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 transactions are not propagated or included in block 151.

[0075] Note that in a UTXO-based transaction model, a given UTXO needs to be used as a whole. It is not possible to "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.

[0076] 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 be propagated and included in blockchain 150 despite being technically valid (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept it). 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 the pointer to UTXO0 is the only input of Tx1 and Tx1 has only one output UTXO1. If the digital asset amount 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.

[0077] The digital assets of Alice and Bob 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.

[0078] 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 prefixed with 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.

[0079] 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).

[0080] The locking script, sometimes called "scriptPubKey", refers to the fact that it typically includes the public key of the party to which the corresponding transaction is locked. The unlocking script, sometimes called "scriptSig", refers to the fact 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.

[0081] 3. Side Channel

[0082] 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 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 on 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.

[0083] A side channel 107 can be established via 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 that are used for "off-chain" data exchange, i.e., 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. via 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.

[0084] 4. Payment Channel

[0085] In a typical payment channel implementation, an almost unlimited 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 set of payments. The payment channel implementation is outlined below.

[0086] First, it should be noted that

[0087] "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, i.e., 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 furthest lock time you can choose is approximately 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 / ]

[0088] Now consider the scenario where Alice 103a needs to pay Bob 103b for services, which may require Alice 103a to pay Bob 103b multiple times 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 performed.

[0089] Alice creates a 2-of-2 multisignature transaction T c , which commits 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.

[0090]

[0091] Table 1: Funding Transaction T c

[0092] 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 something goes wrong with the exchange between Alice 103a and Bob 103b, after the nLockTime has expired, this refund transaction allows Alice 103a to obtain a refund.

[0093]

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

[0095] 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 10 BSV back 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.

[0096]

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

[0098]

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

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

[0101] s r,i+1 <s r,i

[0102] 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 reclaim 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.

[0103] 6. Facilitating Blockchain Payments

[0104] Embodiments of the present disclosure provide an intermediary 303 for facilitating payments between a plurality of first parties 301 and second parties 302. In some embodiments, as Figure 4 shown, the plurality of first parties 301 are regarded as payers, and the second parties 302 are regarded as payees. In other embodiments, as Figure 5 shown, the second parties 302 are regarded as payers, and the plurality of first parties 301 are regarded as payees.

[0105] Figure 4 An exemplary system 400 is shown, in which the intermediary 303 establishes a plurality of payment channels (one for each first party 301) and forwards the payments to the second party 302. Each first party 301, intermediary 303, and second party can be configured to perform as described above with reference to Figure 1 and Figure 2 Any action described as being performed by Alice 103a and / or Bob 103b. System 400 may include any number (n) of first parties 301. In these embodiments, a second party 302 may provide corresponding goods and / or services to each first party 301 in exchange for payment.

[0106] An intermediary 303 establishes a corresponding payment channel with each first party 301, i.e., each first party 301 establishes one payment channel. Establishing a corresponding payment channel includes obtaining 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 intermediary 303 (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 or a different public key owned by that party. For example, each channel opening transaction may have an output locked to the same public key of the intermediary 303. The output of each corresponding channel opening transaction locks a corresponding maximum value, i.e., the amount (e.g., satoshis) of the underlying digital asset of the blockchain 150.

[0107] The intermediary 303 may generate one, some, or all of the corresponding channel opening transactions in the corresponding payment channels. The intermediary 303 may receive one, some, or all of the corresponding channel opening transactions in the corresponding payment channels from the corresponding first parties 301.

[0108] The intermediary 303 and each corresponding first party 301 execute the corresponding payment channels. For each corresponding payment channel, this involves obtaining one or more corresponding channel closing transactions. The channel closing transaction may also be referred to as a final transaction or a refund transaction. For each payment channel, each corresponding channel closing transaction among the one or more corresponding channel closing transactions includes a corresponding input that references the output of the corresponding channel opening transaction used to open that payment channel. The input may be signed by the intermediary 303 and / or the corresponding first party 301. Each corresponding channel closing transaction among the one or more corresponding payment channel closing transactions includes a corresponding output locked to the public key of the corresponding first party 301 and a corresponding output locked to the public key of the intermediary 303. The output locked to the public key of the first party locks a first amount of the corresponding maximum value locked by the output of the corresponding channel opening transaction. Similarly, the output locked to the public key of the intermediary locks a second amount of the corresponding maximum value locked by the output of the corresponding channel opening transaction. The sum of the first amount and the second amount is at most equal to the maximum value. As discussed below, the first amount and the second amount may be less than the maximum value.

[0109] For each respective payment channel, the intermediary 303 uses a respective channel closing transaction in the respective channel closing transaction for the payment channel to close the payment channel by having the closing channel transaction be committed to the blockchain network 106. The transaction used to close the payment channel is referred to as the final channel closing transaction. The intermediary 303 may submit the final channel closing transaction to the blockchain network 106, or the second party 302 may submit the final channel closing transaction to the blockchain network 106.

[0110] Once each payment channel is closed, the intermediary 303 generates a payment transaction by submitting the respective final channel closing transaction to the blockchain network 106. The payment transaction includes respective inputs that, for each respective final channel closing transaction, reference the respective output locked to the public key of the intermediary 303 for that respective final channel closing transaction. Each respective input is signed by the intermediary 303. The payment channel transaction includes an output locked to the public key controlled by the second party 302.

[0111] The payment transaction may include metadata related to one, some, or all of the payments in the payment, such as an identifier of the respective first party, a payment reference, etc. The channel opening transaction and / or the channel closing transaction may also include metadata related to the respective payment of the respective payment channel.

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

[0113] Figure 5 An exemplary system 500 is shown in which the intermediary 303 establishes multiple payment channels (one payment channel for each first party 301) to make payments to each first party 301 on behalf of the second party 302. Each first party 301, the intermediary 303, and the 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 described. The system 500 may include any number (n) of first parties 301. In these embodiments, each first party 301 may provide a respective good and / or service to the second party 302 in exchange for payment.

[0114] The intermediary party 303 obtains the funding transaction generated by the second party 302. The funding transaction includes an input signed by the second party 302 and an output locked to a public key controlled by the intermediary 303. The output lock is equal to the total amount of at least a plurality of corresponding maximum values, each maximum value being associated with a maximum payment to a corresponding first party 301. The total amount may include a service fee charged by the intermediary party 303. The intermediary party 303 may obtain the funding transaction from the blockchain 150 or from the second party 302.

[0115] The intermediary party 303 establishes a corresponding payment channel with each first party 301, i.e., one payment channel is established with each first party 301. In these embodiments, establishing a corresponding payment channel includes obtaining (e.g., generating) a corresponding channel opening transaction. Each corresponding channel opening transaction includes an input signed by the intermediary party 303. That is, the input references the output of the previous transaction, where the output is controlled by a public key owned by the intermediary party 303 (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 intermediary party 303 (e.g., the output may be a multi-signature output). The output of each 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).

[0116] The intermediary party 303 and each corresponding first party 301 execute the corresponding payment channel. For each corresponding payment channel, this involves obtaining one or more corresponding channel closing transactions. For each payment channel, each corresponding channel closing transaction in the one or more corresponding channel closing transactions includes a corresponding input that references the output of the corresponding channel opening transaction used to open the payment channel. The input may be signed by the intermediary party 303 and / or the corresponding first party 301. Each corresponding channel closing transaction in the one or more corresponding payment channel closing transactions includes a corresponding output locked to the public key of the corresponding first party 301 and a corresponding output locked to the public key of the intermediary party 303. The output locked to the public key of the first party locks a first amount of the corresponding maximum value locked by the output of the corresponding channel opening transaction. Similarly, the output locked to the public key of the intermediary party locks a second amount of the corresponding maximum value locked by the output of the corresponding channel opening transaction. The sum of the first amount and the second amount is at most equal to the corresponding maximum value. As discussed below, the first amount and the second amount may be less than the maximum value.

[0117] For each corresponding payment channel, the intermediary party 303 uses one corresponding channel closing transaction in the corresponding channel closing transactions to close the payment channel by causing the closed channel transaction to be submitted to the blockchain network 106. The transaction used to close the payment channel is called the final channel closing transaction. The intermediary party 303 may submit the final channel closing transaction to the blockchain network 106, or the corresponding first party 302 may submit the final channel closing transaction to the blockchain network 106.

[0118] The fund transaction may include metadata related to one, some, or all of the payments, such as the identifier of the corresponding first party, payment reference, etc. The channel opening transaction and / or the channel closing transaction may also include metadata related to the corresponding payment of the corresponding payment channel.

[0119] Table 11, Table 12, and Table 13 below respectively show examples of fund transactions, channel opening transactions, and channel closing transactions.

[0120] It should be understood that the terms used herein (such as "fund", "payment", "channel opening", "channel closing", etc.) are only used as labels for specific transactions.

[0121] 7. Payment Channel Aggregator Example

[0122] 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 intermediate party (I - Ivan) between two parties (A - Alice and B - Bob), who previously directly used a payment channel between themselves (Alice and Bob).

[0123] 7.1 One - to - One

[0124] Figure 3 An exemplary system 300 for using an intermediate party 303 to facilitate payments between a first party 301 and a second party 302 is shown. For convenience, the first party 303 is referred to as Alice 103a, the second party is referred to as Bob 103b, and the intermediate party is referred to as Ivan 303. For a one - to - one payment, 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 the described scenario, an intermediate party (Ivan) 303 is utilized to handle the payment from Alice 103a to Bob 103b.

[0125] The PCA involves the following steps:

[0126] - Ivan 303, Alice 103a, and Bob 103b reach an agreement that Ivan 303 will collect funds from Alice 103a, and Ivan 303 will then transfer these funds to Bob 103b (possibly before a specified deadline).

[0127] - Alice 103a and Ivan 303 create a payment channel between themselves, which will be used to facilitate intermittent payments to Ivan 303. This includes creating a funding transaction that can refund (or pay to Ivan 303) the maximum amount Max BSV to Alice 103a. At the end of Alice's payment, the "payment channel is closed" (i.e., the settlement transaction is submitted to the blockchain 150).

[0128] - Ivan 303 transfers the value of the settlement transaction x f to Bob 103b. (Ivan 303 may deduct a previously agreed personal service fee sc before paying x f to Bob 103b). It should be noted that this service fee is not a fixed fee but may be proportional to the amount that Ivan can collect (on behalf of Bob 103b) from Alice 103a. This is because the service fee sc r,i+1 of the refund transaction T i+1 will be higher than the service fee sc r,i of the refund transaction T i .

[0129] - To prevent the increased service fee from reducing the payment to Bob 103b, additional inputs can be added to the refund transaction responsible for funding the service fee.

[0130] For the payment channel utilized, examples of one of the refund transactions in the funding transaction T c and the refund transaction T r,i are shown in Tables 5 and 6 respectively. The OP_RETURN output can be included in both transactions to store metadata related to the agreement between Alice 103a, Bob 103b, and Ivan 303. This metadata can include data related to the transaction. For example, if it is a Netflix subscription, the metadata can include the hash of the license agreement, the subscription ID, the start date, the end date, and the specific service level requested, etc.

[0131]

[0132] Table 5: Funding Transaction, PCA, One-to-One

[0133]

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

[0135] When Ivan 303 wants to pay Bob 103b, this can be done using the P2PKH transaction (T Payment ) shown in Table 7. This transaction spends Ivan's settlement T r,k UTXOs of the transaction. The metadata can be included in a payment transaction that associates the payment with Alice's subscription. This can include the previously mentioned metadata such as the subscription ID and additional information such as the signed final iteration (e.g., payment up to June 2022), the hash of the settlement refund transaction, etc.

[0136]

[0137] Table 7: Ivan pays Bob all the funds received as of iteration k

[0138] 7.2 Many - to - One

[0139] Figure 4 An exemplary system 400 is shown for facilitating payments between multiple 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 as Bob 103b, and the intermediary as Ivan 303. For many-to-one, assume there are multiple Alices {Alice j | j ∈ [1, n]} will intermittently pay Bob 103b for services or goods. (For example, multiple subscribers need to pay Netflix monthly).

[0140] For each subscriber Alice j , this was previously performed through separate corresponding payment channels (e.g., Netflix) between each Alice and Bob. 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 transactions are finally submitted to the blockchain 150. Then, Ivan 303 forwards the aggregate value of these n settlement transactions to Bob 103b.

[0141] The following steps are performed:

[0142] - Each Alice j agrees with both Bob 103b and Ivan 303; Ivan 303 will collect funds from Alice j and Ivan 303 will subsequently transfer the value of the corresponding settlement transaction to Bob 103b (possibly before a specified deadline).

[0143] - Alice j and Ivan 303 create a payment channel between themselves; this payment channel will be used as a regular payment channel to facilitate intermittent payments to Ivan 303.

[0144] - After Alice's payment ends, the "payment channel is closed".

[0145] - After n channels are closed, Ivan 303 transfers the total value of n settlement transactions to Bob 103b. This can be in the form of one or more payment transactions.

[0146] Suppose Ivan 303 makes a single final payment to Bob 103b (an example of the transaction shown in Table 8), and there is an agreed deadline s for Ivan's payment to Bob 103b close , which requires that the latest nLockTime value of any payment channel among the n payment channels is less than s close . It should be noted that when s r,i+1 < s r,i , the "latest lock time" of the payment channel is the nLockTime of the first iteration of the refund transaction of that channel. Therefore, the latest lock times of the n payment channels will be the first iteration refund transactions of these channels with the latest time. For the payment channels used by Alice j and Ivan 303, examples of a refund transaction in the funding transaction and the refund transaction are shown in Table 9 and Table 10 below.

[0147]

[0148] Table 8: Funding Transaction, PCA, Many-to-One, Trusted

[0149]

[0150] Table 9: Refund Transaction, PCA, Many-to-One, Trusted

[0151] After Ivan 303 has received all settlement transactions of all payment channels, he can then continue to pay the total amount to Bob (e.g., Netflix). He makes the payment by spending the appropriate UTXO of the settlement refund transaction. Table 10 shows an example of this payment made by Ivan to Bob. The metadata in this transaction can include details associating the payment with the settlement refund transaction between Alice j and Ivan 303. More specifically, the metadata can include the hash of the settlement transaction and details of each "subscription".

[0152]

[0153] Table 10: Ivan Pays All Funds to Bob After All Alice j Settlements.

[0154] 7.3 One - to - Many

[0155] Figure 5 An exemplary system 500 is shown for facilitating payments between a second party 302 and multiple first parties 301a, 301b... 301n using an intermediary 303 (where n can be any number). 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 individually, Alice 103a makes a one-time payment to the intermediary Ivan 303, who then processes the payments to each provider.

[0156] In the scenario, PCA technology is used, and again the intermediary Ivan 303 is utilized to manage these payments. This intermediary 303 will accept a one-time payment from Alice 103a and then establish m payment channels among a group of Bobs.

[0157] The following steps are performed:

[0158] - Alice 103a discusses with Ivan 303 the criteria for when to submit a settlement transaction (i.e., no longer increasing the amount paid to Bob in a refund transaction).

[0159] - Alice 103a pays Ivan 303 a service fee sc + the sum of the different maximum amounts that can be paid per channel, i.e.,

[0160] - Ivan 303 creates m payment channels between him and each Bob k . These payment channels will all be used as regular payment channels to facilitate intermittent payments to the corresponding Bob k .

[0161] - After Ivan 303 and the corresponding Bob k reach an agreement on the final refund transaction (settlement transaction), each payment channel is closed.

[0162] For the payment channel Ivan → Bob k , an example of a fund transaction and a refund transaction in one of the refund transactions is shown below.

[0163]

[0164] Table 11: Fund transaction, PCA, one-to-many

[0165]

[0166] Table 12: Refund Transaction, PCA, One-to-Many

[0167] Alice 103a will fund the intermediary Ivan through a regular P2PKH transaction as shown in Table 13. It should be noted that the service fee sc is included in the funds.

[0168]

[0169] Table 13: Transaction to Fund All Payment Channels for All Parties, PCA, One-to-Many

[0170] 8. Further Comments

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

[0172] 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 to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above can be replaced by reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. The blockchain, blockchain network, and / or 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.

[0173] 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 blocks (keep in mind that these entities are not considered nodes of the preferred Bitcoin network 106).

[0174] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "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.

[0175] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with 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 functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0176] Some embodiments have been described in terms of a blockchain network that is used to implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general embodiments, any type of suitable consensus mechanism may be used, 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 its tokens for a period of time in order to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest time is most likely to become the next validator.

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

[0178] Statement 1. A computer-implemented method for facilitating multiple corresponding payments between multiple corresponding first parties and a second party, where the method is performed by an intermediary party and includes:

[0179] Performing a corresponding payment channel between each corresponding first party and the intermediary party, where performing the corresponding payment channel includes:

[0180] Obtaining 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 intermediary party, where the corresponding output locks a corresponding maximum value;

[0181] Obtain one or more corresponding channel closing transactions, the one or more corresponding channel closing transactions including corresponding final channel closing transactions, where the corresponding final channel closing transactions include corresponding inputs, and corresponding first outputs locked to the corresponding public keys of the corresponding first parties and corresponding second outputs locked to the public keys of the intermediate parties, the corresponding inputs of the corresponding final channel closing transactions reference the corresponding outputs of the corresponding channel opening transactions and include the corresponding signatures of the corresponding first parties and the signatures of the intermediate parties, where the corresponding first outputs lock corresponding first amounts of the corresponding maximum values, and where the corresponding second outputs lock corresponding second amounts of the corresponding maximum values; and,

[0182] Generate a payment transaction, where the payment transaction includes a plurality of corresponding inputs, and an output locked to the public key of the second party, each corresponding input references the corresponding second output of the corresponding final channel closing transaction and includes the signature of the intermediate party, where the output locks a value based on the sum of the corresponding second amounts locked by the corresponding second outputs.

[0183] Statement 2. The method according to statement 1, wherein the payment transaction includes metadata related to one, part, or all of the corresponding payments.

[0184] Statement 3. The method according to statement 1 or 2, wherein for each corresponding payment channel, 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 minus a 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.

[0185] Statement 4. A computer-implemented method for facilitating multiple corresponding payments between multiple corresponding first parties and a second party, where the method is executed by an intermediate party and includes:

[0186] Obtain a funding transaction generated by the second party, where the funding transaction includes an input containing the signature of the second party, and an output locked to the public key of the intermediate party, where the output locks an amount at least equal to the sum of multiple corresponding maximum values; and,

[0187] Execute corresponding payment channels between each corresponding first party and the intermediate party, where executing the corresponding payment channels includes:

[0188] Obtain corresponding channel opening transactions, the corresponding channel opening transactions including corresponding inputs signed by the intermediate party, and corresponding outputs locked to the corresponding public keys of the corresponding first parties and the public key of the intermediate party, where the corresponding outputs lock corresponding maximum values;

[0189] Obtain one or more corresponding channel closing transactions, the one or more corresponding channel closing transactions including corresponding final channel closing transactions, wherein the corresponding final channel closing transactions include corresponding inputs, as well as corresponding first outputs locked to corresponding public keys of the corresponding first party and corresponding second outputs locked to public keys of the intermediate party, the corresponding inputs of the corresponding final channel closing transactions reference the corresponding outputs of the corresponding channel opening transactions and include corresponding signatures of the corresponding first party and signatures of the intermediate 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.

[0190] Statement 5. The method according to statement 4, wherein the funding transaction includes metadata related to one, part, or all of the corresponding payments.

[0191] Statement 6. The method according to statement 4 or 5, wherein the output of the funding transaction locks an amount equal to the sum of the corresponding maximum value plus the service fee.

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

[0193] Statement 8. The method according to any one of the preceding statements, wherein the corresponding output of the corresponding channel opening transaction and / or the corresponding output of the corresponding channel closing transaction includes a multi-signature locking script.

[0194] Statement 9. The method according to statement 1 or any of its dependent statements, wherein the second party provides the corresponding first party with corresponding goods and / or corresponding services in exchange for the corresponding payment.

[0195] Statement 10. The method according to statement 4 or any of its dependent statements, wherein each corresponding first party provides the second party with corresponding goods and / or corresponding services in exchange for the corresponding payment.

[0196] Statement 11. A computer device, the computer device comprising:

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

[0198] 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 statements 1 to 10.

[0199] Statement 12. A computer program, the computer program being embodied on a computer-readable memory and configured to perform the method according to any one of Statements 1 to 10 when run on one or more processors.

[0200] According to another aspect disclosed herein, a method may be provided that includes actions of the intermediary party and one or both of the following: i) the plurality of first parties; ii) the second party.

[0201] According to another aspect disclosed herein, a system may be provided that includes computer devices of the following: i) the plurality of first parties; and ii) the second party.< / pa>

Claims

1. A computer-implemented method for facilitating multiple corresponding payments between multiple respective first parties and a second party, wherein the method is performed by an intermediary party and comprises: Performing a corresponding payment channel between each respective first party and the intermediary party, wherein performing the corresponding payment channel comprises: Obtaining a corresponding channel opening transaction, the corresponding channel opening transaction comprising 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 intermediary party, wherein the corresponding output locks a corresponding maximum value; Obtaining one or more corresponding channel closing transactions, the one or more corresponding channel closing transactions comprising a corresponding final channel closing transaction, wherein the corresponding final channel closing transaction comprises a corresponding input, and a first output locked to the corresponding public key of the corresponding first party and a second output locked to the public key of the intermediary party, the corresponding input of the corresponding final channel closing transaction references the corresponding output of the corresponding channel opening transaction, and comprises the corresponding signature of the corresponding first party and the signature of the intermediary party, wherein the first output locks a corresponding first amount of the corresponding maximum value, and wherein the second output locks a corresponding second amount of the corresponding maximum value; and Generating a payment transaction, wherein the payment transaction comprises a plurality of corresponding inputs, and an output locked to the public key of the second party, each corresponding input references the corresponding second output of the corresponding final channel closing transaction, and comprises the signature of the intermediary party, wherein the output locks a value based on the sum of the corresponding second amounts locked by the corresponding second outputs.

2. The method according to claim 1, wherein, The payment transaction comprises metadata related to one, part or all of the corresponding payments.

3. The method according to claim 1 or 2, wherein For each corresponding payment channel, 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 minus a 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.

4. A computer-implemented method for facilitating multiple corresponding payments between multiple respective first parties and a second party, wherein the method is performed by an intermediary party and comprises: Obtaining a funding transaction generated by the second party, wherein the funding transaction comprises an input comprising the signature of the second party, and an output locked to the public key of the intermediary party, wherein the output locks an amount at least equal to the sum of the multiple corresponding maximum values; And Performing a corresponding payment channel between each respective first party and the intermediary party, wherein performing the corresponding payment channel comprises: Obtaining a corresponding channel opening transaction, the corresponding channel opening transaction comprising a corresponding input signed by the intermediary party, and a corresponding output locked to the corresponding public key of the corresponding first party and the public key of the intermediary party, wherein the corresponding output locks a corresponding maximum value; Obtain one or more corresponding channel closing transactions, the one or more corresponding channel closing transactions including corresponding final channel closing transactions, wherein the corresponding final channel closing transactions include corresponding inputs, and corresponding first outputs locked to corresponding public keys of the corresponding first party and corresponding second outputs locked to public keys of the intermediate party, the corresponding inputs of the corresponding final channel closing transactions referencing the corresponding outputs of the corresponding channel opening transactions and including corresponding signatures of the corresponding first party and signatures of the intermediate party, wherein the corresponding first outputs lock corresponding first amounts of the corresponding maximum values, and wherein the corresponding second outputs lock corresponding second amounts of the corresponding maximum values.

5. The method according to claim 4, wherein The funding transaction includes metadata related to one, some, or all of the corresponding payments.

6. The method according to claim 4 or 5, wherein The outputs of the funding transaction lock an amount equal to the sum of the corresponding maximum value plus the service fee.

7. The method according to any one of the preceding claims, wherein, For one, some, or all of the corresponding payment channels, the corresponding channel opening transaction and / or the corresponding final channel closing transaction include metadata related to the corresponding payment.

8. The method according to any one of the preceding claims, wherein, The corresponding outputs of the corresponding channel opening transaction and / or the corresponding outputs of the corresponding channel closing transaction include multisignature locking scripts.

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

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

11. 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, the code being configured to, when run on the processing device, perform the method according to any one of claims 1 to 10.

12. A computer program, the computer program being contained on a computer-readable memory and being configured to, when run on one or more processors, perform the method according to any one of claims 1 to 10.

Images