Payment Channel Aggregator

Abstract

A computer-implemented method for facilitating payments between multiple first and second parties, comprising: executing a respective payment channel between each respective first party and an intermediate party by obtaining a channel open transaction having an output that locks a maximum value; obtaining one or more channel close transactions, including a final channel close transaction, the final channel close transaction having a first output and a second output, the first output locking a first amount of the maximum value and the second output locking a second amount of the maximum value; and generating a payment transaction having a plurality of inputs, each input referencing the second output of the final channel close transaction, and an output locked to the public key of the second party, the output locking value based on the sum of the second amounts locked by the second outputs.

Description

[Technical Field]

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

[0002] A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform a solution to a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through the mere publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes to data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0004] Nodes in the blockchain network (often called "miners") perform a distributed transaction registration and validation process, described in more detail below. Briefly, during this process, nodes validate transactions and insert them into block templates, from which they attempt to identify valid proof-of-work solutions. Once a valid solution is found, a new block is propagated to other nodes in the network, thus allowing each node to record a new block on the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be propagated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to execute the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into blocks. Assuming the transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) then remains registered and indexed as such at each of the nodes in the blockchain network as an immutable public record.

[0005] The node that successfully solves the proof-of-work puzzle and creates the latest block is typically awarded a new transaction, called a "coinbase transaction," that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, which act as agents of the network and are encouraged to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node behavior. The mere publication of block headers allows participants to guarantee the continued validity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying an amount of a digital asset derivable from the evolving series of transactions. A consumable output is sometimes called a UTXO (“unspent transaction output”). The output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that specifies the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, a pair of transactions is considered, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that specifies one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlock script meets all of one or more conditions specified in the lock script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction specifies the amount to be transferred by reference to absolute account balances rather than by referencing backwards the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Problem to be solved by the invention]

[0009] In a blockchain context, a payment channel is a set of transactions between two parties (each transaction representing at least one payment) and a corresponding protocol for signing and submitting transactions that allows a valid and secure set of payments to occur between two parties without committing the entire set of transactions to the blockchain. Of a payment channel's set of transactions, only two transactions are submitted to the blockchain, regardless of the number of transactions created. One of these submitted transactions may represent the final agreed-upon payment at the end of iterative negotiations or may be the summation of a set of periodic payments.

[0010] For the latter, one may consider the example of a one-year subscription (e.g., to a streaming platform such as Netflix) with 12 monthly payments. Each month, a valid and secure copy of the transaction is given by the customer to the streaming platform. The streaming platform can submit transactions to the blockchain if the customer so wishes. Each month's transaction includes a payment that is an accumulation of the amount owed for the current and previous months. However, the streaming platform only submits the final transaction to the blockchain. This transaction includes the accumulated payments for the entire 12 months.

[0011] Typically, one would expect a payment channel to be established between two parties: a payer (e.g., Alice) and an intended recipient of the payment (e.g., Bob), where Bob would be the provider of the goods / services. However, as recognized herein, in some situations, an intermediary may be desired. [Means for solving the problem]

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, the method being performed by an intermediate party and comprising: executing a respective payment channel between each respective first party and an intermediate party; obtaining respective channel opening transactions, each comprising a respective input signed by a respective first party and a respective output locked to a respective public key of the respective first party and a public key of the intermediate party, each output locking a respective maximum value; Obtaining one or more respective channel closing transactions, including a respective final channel closing transaction, wherein the respective final channel closing transactions have respective inputs that reference respective outputs of the respective channel opening transactions and comprise respective signatures of the respective first parties and signatures of the intermediate parties, and respective first outputs locked to respective public keys of the respective first parties and respective second outputs locked to public keys of the intermediate parties, wherein the respective first outputs lock respective first amounts of the respective maximum values ​​and the respective second outputs lock respective second amounts of the respective maximum values; and executing a respective payment channel comprising: generating a payment transaction, the payment transaction comprising a plurality of respective inputs, each respective input referencing a respective second output of a respective final channel close transaction and comprising a signature of an intermediate party, and an output locked to a public key of a second party, the output locking a value based on a sum of respective second amounts locked by the respective second outputs; Equipped with.

[0013] In this aspect, an intermediary is used to facilitate payments between multiple payers and payees. The intermediary establishes a payment channel with each payer. As each payment channel closes (i.e., settles), the intermediary submits a payment transaction to the blockchain that transfers an amount to the payee based on the outcome of each separate payment channel.

[0014] This intermediary (e.g., Ivan) receives payments from multiple payers (e.g., multiple instances of Alice) on behalf of a payee (e.g., Bob) and then makes the payments to Bob. As an example, a streaming platform may outsource the collection of its subscription fees to a third-party collection agency, which collects all subscription fees and then pays the accumulated fees to the platform in one or more payments. This is a more efficient process than having each user engage with the streaming platform separately.

[0015] According to another aspect disclosed herein, there is provided a computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, the method being performed by an intermediate party and comprising: capturing a funding transaction generated by a second party, the funding transaction comprising an input comprising the signature of the second party and an output locked to the public key of the intermediate party, the output locking an amount at least equal to the sum of a plurality of respective maximum values; executing a respective payment channel between each respective first party and an intermediate party; and executing each payment channel, obtaining respective channel open transactions, each comprising a respective input signed by an intermediate party and a respective output locked to a respective public key of a respective first party and a public key of the intermediate party, each output locking a respective maximum value; obtaining one or more respective channel close transactions including a respective final channel close transaction, wherein each final channel close transaction comprises a respective input that references a respective output of a respective channel open transaction and comprises a respective signature of a respective first party and a signature of an intermediate party, and a respective first output locked to a respective public key of the respective first party and a respective second output locked to a public key of the intermediate party, wherein each first output locks a respective first amount of a respective maximum value and each second output locks a respective second amount of a respective maximum value.

[0016] In this aspect, an intermediary is used to facilitate payments between a payer and multiple payees. The intermediary receives a funds transfer transaction from the payer that sends an amount to the intermediary. The intermediary then establishes a payment channel with each payee. The intermediary closes (i.e., settles) the payment channel with each payee, for example, after payment of an agreed-upon amount, after an agreed-upon amount of time, in response to a request from the payer, etc.

[0017] In this scenario, a party (e.g., Alice) may subscribe to multiple services (e.g., multiple instances of Bob), in which case it is more convenient (and efficient) to have an intermediary distribute these payments to the various services on his / her behalf.

[0018] In either aspect, the use of an intermediary improves the privacy of the parties (payer and payee) as, from an outside perspective, a third party cannot determine both the source and destination of a payment, since either the source or destination is replaced by the intermediary.

[0019] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded in a blockchain. [Figure 3] FIG. 1 illustrates an example of a one-to-one payment channel. [Figure 4] FIG. 1 illustrates an example of a many-to-one payment channel. [Figure 5] FIG. 1 illustrates an example of a one-to-many payment channel. DETAILED DESCRIPTION OF THE INVENTION

[0021] 1. Example System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, i.e., typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0022] Each blockchain node 104 comprises a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0023] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing a quantity of a digital asset, one example of a property being the user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backward to the output of a preceding transaction 152, thereby linking the transactions.

[0024] Each block 151 also has a block pointer 155 that points back to previously created blocks 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer back to an earlier transaction to define an order for the series of transactions (note that the series of transactions 152 is allowed to diverge). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0025] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. 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 often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions attempting to consume the same output.

[0026] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction onward. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and even sent to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or submission in a temporal sequence, and therefore does not necessarily preclude a transaction 152i, 152j from being created or submitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0027] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input of the preceding transaction 152i to the new user or entity 103b as specified in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a for providing change). In some cases, a transaction may also have multiple inputs to aggregate the amount from multiple outputs of one or more preceding transactions and redistribute it among one or more outputs of the current transaction.

[0028] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or organization, wishes to establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party sends the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately sends this transaction to one or more blockchain nodes 104 of the network 106 (which today is typically a server or data center, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may, in some instances, send the transaction directly to one or more of the blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise checking that a cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition specified in the output of a prior transaction 152i that the new transaction consumes (or "allocates"); this condition typically comprises at least checking that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the prior transaction 152i to which the input of the new transaction is linked. The condition may be specified at least in part by a script included in the output of the prior transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or may result from a combination of these.Either way, 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 tests according to the same blockchain node protocol, and so forward the new transaction 152j onto one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0029] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has yet been validly redeemed by the input of another transaction 152j forward according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless flagged as invalid and propagated to warn) or recorded in the blockchain 150. This protects against double spend, whereby a transactor attempts to allocate the same transaction output more than once. On the other hand, the account-based model protects against double spend by maintaining an account balance. Again, because there is a defined order of transactions, the account balance always has a defined single state.

[0030] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, in a process supported by "proof of work," commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that, when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition might be that the output of the hash has some predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that the hash has an output that is unpredictable given its input. Therefore, this search can only be performed by brute force, and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0031] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the solution satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it up to threshold agreement of other nodes enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155, which points back in the chain to the previously created block 151n-1, is also assigned to the new block 151n. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction; otherwise, known as double spending. Once created, blocks 151 cannot be modified since they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0032] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool 154 of unissued transactions at any given time, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unissued transactions is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unissued transactions, and so on. The protocol also exists to resolve any "forks" that may occur, which are cases where two blockchain nodes 104 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 104. In essence, whichever prong of the fork grows the longest becomes the final blockchain 150. Note that when the same transaction appears in both forks, this should not affect users or agents of the network.

[0033] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional accepted amounts of digital assets in a new special type of transaction that distributes a specified additional quantity of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is typically called a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node’s intent to construct the new block to comply with protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0034] Due to the resources involved in transaction validation and publishing, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may also take the form of a user terminal or a group of user terminals networked together.

[0035] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer or in a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0036] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as accumulating entities that accumulate copies of the blockchain 150 (e.g., obtain copies of the blockchain from blockchain nodes 104).

[0037] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It is understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0038] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any actions attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

[0039] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0040] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second functionality comprises reconciling the amounts specified in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0041] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented within a set of two or more separate applications that interface via, for example, an API, or one plugged into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0042] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, to truly inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet function on each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to jointly implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0043] When a given party 103, for example, Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction according to the relevant transaction protocol (using a wallet function in her client application 105). Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 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 respective role. This involves first checking whether the newly received transaction 152j meets some conditions for being “valid,” examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be specified by a combination of the script and the node protocol.

[0044] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this then means that the transaction 152j will soon be propagated throughout the entire network 106, assuming the transaction 152j is valid.

[0045] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle on the latest version of their respective pool of 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions that will be included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 that includes the new transaction 152j, the new transaction 152j immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer back to earlier transactions, so that the order of transactions is also immutably recorded.

[0046] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore may have competing views of which instance is "valid" before an instance is published in a 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 one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it shall accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance not published in block 151).

[0047] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance, rather than by referencing backward the UTXO of a transaction that precedes it in the sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called its "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed with a transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0048] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0049] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0050] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0051] The preceding transaction Tx0 may already be valid and included in a block 151 of the blockchain 150 at the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or Tx0 may even be sent after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence, as defined by transaction pointers specified in the transactions (e.g., which transactions point backward to which other transactions). They may be equivalently substituted for “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or the like. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (a descendant transaction or “child”) that points to a preceding transaction (an ancestor transaction or “parent”) is not valid until and unless the parent transaction is valid. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, an orphan may be discarded or may be buffered for some time to wait for its parent.

[0052] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that specifies the condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script typically specifies an unlocking condition that includes the condition that the unlocking script in the input of the subsequent transaction comprise the cryptographic signature of the party to which the preceding transaction is locked.

[0053] A lock script (also called 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" (capital S) used by blockchain networks. A lock script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0054] So, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID, TxID0. Tx1's input 202 comprises a pointer that points backward into Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlock script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a lock script, or by a node protocol, or a combination of these.

[0055] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the lock script and the unlock script together to check whether the unlock script satisfies a condition specified in the lock script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" denotes a location within the data on the stack, and "[...]" is a function provided by the lock script (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. A, which authenticates that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (so there is no need to include a separate element in the clear specifying the signed portion of the data, as it is already inherently present).

[0056] The details of authentication via public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as a signature on the message, thus allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or part of a transaction or the like can, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0057] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (so, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 propagates throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it consumes unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 is already spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a prescribed order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0058] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground for invalidity in most transaction models. Therefore, such a transaction is not propagated or included in block 151.

[0059] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave behind" a fraction of the amount specified in the UTXO as spent while another fraction is consumed. However, the amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount specified in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount specified in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to make a payment to another party.

[0060] In practice, Alice also typically needs to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and, therefore, while technically valid, may not be propagated or included in the blockchain 150 (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of transaction 152's UTXOs 203 itself.

[0061] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. There is no single number stored somewhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party and that have not yet been spent in another transaction onward. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0062] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to specific opcodes in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a lock script, can accumulate data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data in the blockchain 150. For example, the data may comprise a document that is desired to be accumulated in the blockchain.

[0063] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portion of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0064] A locking script may be referred to as a "scriptPubKey," typically referring to the fact that the locking script comprises the public key of the party to which the respective transaction is locked. An unlocking script may be referred to as a "scriptSig," typically referring to the fact that the unlocking script provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0065] 3. Side Channels As shown in FIG. 1 , the client application on each of Alice's and Bob's computing devices 102 a and 102 b, respectively, may include additional communication functionality. This additional functionality allows Alice 103 a to establish (at the instigation of either the parties or a third party) a separate side channel 107 with Bob 103 b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner may be referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0066] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 107 may be established over a variety of networks, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, a side channel 107 as referenced elsewhere herein may comprise any one or more links, via one or more networking technologies or communications media, for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange several pieces of information or data, or the like, over the side channel 107, this does not necessarily imply that all these pieces of data must be sent over exactly the same links, or even the same type of network.

[0067] 4. Payment Channels In a typical payment channel implementation, a nearly unlimited number of payments can be made, but only two transactions need to be added to the blockchain 150 at any one time. In addition to the reduced number of transactions being added to the blockchain and the associated reduced cost, storage, and bandwidth usage, payment channels also facilitate the speed and ability of payers to have their funds refunded if things do not go as planned or if either party decides not to proceed beyond some set of payments. A description of payment channel implementations is outlined below.

[0068] First, please note the following: "For each Bitcoin transaction, there can be two or more inputs. For each input, there is a parameter called a sequence number. This number is an indication of whether the transaction containing this input will be completed or not. If that parameter does not take the maximum value (0xFFFFFFFF), the validation process looks at the lock time field (specified at the transaction level) which specifies when the transaction will become valid; i.e., the transaction will not be valid until the lock time. This can be useful when the specified time is in the future. (At the time of writing, the maximum that can be chosen for the lock time is roughly 9,500 years into the future.) Before the lock time of a given transaction matures, a new version of that transaction with a higher sequence number can invalidate an earlier version that consumes the same input but has a lower sequence number." [https: / / nchain.com / payment-channels-and-smart-contracts-on-bitcoin / ]

[0069] Consider now the scenario where Alice 103a needs to make a payment to Bob 103b for a service, where this may require multiple payments from Alice 103a to Bob 103b over a period of time, as the situation dictates. Alice 103a expects to spend at most 15 BSV (in total) to Bob 103b in the set of possible exchanges. To facilitate this, a payment channel is established between Alice 103a and Bob 103b that operates as follows:

[0070] Alice issues a 2 / 2 multi-signature transaction T that commits Alice103a to generating 15 BSV. c A multi-signature lock script requires two individuals (Alice and Bob) to sign any transaction that consumes the corresponding locked output. At this point, the transaction is not submitted to the blockchain network 106.

[0071] [Table 1]

[0072] Alice 103a issues a separate refund transaction T that returns all funds from the multisignature-controlled funds to Alice 103a. r,0 This transaction creates

[0073]

number

[0074] The transaction includes an nLockTime value, nLockTime, which is a blockchain transaction parameter that allows a blockchain transaction to become executable only after a specified time has elapsed. Bob 103a signs the blockchain transaction. This refund transaction allows Alice 103a to be refunded after nLockTime has elapsed if the exchange between Alice 103a and Bob 103b does not go well.

[0075] [Table 2]

[0076] Alice 103a transfers the original transaction T c At this point, Alice 103a and Bob 103b may proceed to create new refund transactions to reflect that payments (off-chain) are being made from Alice 103a to Bob 103b. These refund transactions will reflect the net amount of money needed by Alice 103a to make payments to Bob 103b at that point. As an example, if Alice 103a were to make a payment of 5 BSV to Bob 103b, then new refund transaction T would be created with outputs sending 5 BSV to Bob 103b and 10 BSV back to Alice 103a.r,i If Alice 103a needs to make another payment of 5 BSV to Bob 103b, a new withdrawal transaction T is created with outputs sending 10 BSV to Bob 103b and 5 BSV to Alice 103a. r,i+1 For each new refund transaction, assuming agreement with the details, both parties sign the transaction but do not necessarily submit it to the network 106.

[0077] [Table 3]

[0078] [Table 4]

[0079] Note that each successive refund transaction that is made has a smaller nLockTime and a larger sequence number than the nLockTime of the previous refund transaction. s r,i+1 r,i

[0080] Any T r,i If a party refuses to sign the T. r,i-1 In the worst case scenario, Alice 103a may submit T r,0 and submits it to the network 106 to retrieve all of her funds (after nLockTime expires). The final withdrawal transaction that is constructed represents the net sum of funds being transferred from Alice 103a to Bob 103b. This transaction is submitted to the network 106. The withdrawal transaction submitted to the blockchain network 106 is referred to herein as a settlement transaction.

[0081] 6. Facilitating Blockchain Payments​ Embodiments of the present disclosure provide an intermediary 303 to facilitate payments between multiple first parties 301 and second parties 302. In some embodiments, the multiple first parties 301 are considered payers and the second parties 302 are considered payees, as shown in Figure 4. In other embodiments, the second party 302 is considered the payer and the multiple first parties 301 are considered payees, as shown in Figure 5.

[0082] 4 shows an example system 400 in which an intermediary 303 establishes multiple payment channels, one for each first party 301, and forwards payments to second parties 302. Each first party 301, intermediary 303, and second party may be configured to perform any of the actions described above as being performed by Alice 103a and / or Bob 103b with reference to FIGS. 1 and 2. System 400 may include any number, n, of first parties 301. In these embodiments, second parties 302 may supply respective goods and / or services to each first party 301 in exchange for payment.

[0083] The intermediary 303 establishes a respective payment channel with each first party 301, i.e., one for each first party 301. Establishing a respective payment channel comprises obtaining a respective channel open transaction. A channel open transaction may also be referred to as an initial transaction or a funding transaction. Each respective channel open transaction comprises an input signed by the respective first party 301. That is, the input references the output of a previous transaction, where the output is controlled by (i.e., locked to) a public key owned by the respective first party 301. Each respective channel open transaction comprises an output locked to the public key of the respective first party 301 and the public key of the intermediary 303 (e.g., the output may be a multi-signature output). Unless the context requires otherwise, each reference herein to a party's public key may refer to the same public key or different public keys owned by that party. For example, each channel open transaction may have an output locked to the same public key of the intermediary 303. The output of each respective channel open transaction locks a respective maximum value, i.e., an amount (e.g., satoshis) of the digital asset underlying blockchain 150.

[0084] The intermediary 303 may generate one, some, or all of the respective channel open transactions. The intermediary 303 may receive one, some, or all of the respective channel open transactions from each first party 301.

[0085] The intermediary 303 and each respective first party 301 execute a respective payment channel. This involves obtaining one or more respective channel close transactions for each payment channel. The channel close transactions are sometimes referred to as final transactions or refund transactions. For each payment channel, each of the one or more respective channel close transactions comprises a respective input that references the output of the respective channel open transaction used to open that payment channel. The input may be signed by the intermediary 303 and / or the respective first party 301. Each of the one or more respective payment channel close transactions comprises a respective output locked to the public key of the respective first party 301 and a respective output locked to the public key of the intermediary 303. The output locked to the first party's public key locks a first amount of the respective maximum value locked by the output of the respective channel open transaction. Similarly, the output locked to the intermediary's public key locks a second amount of the respective maximum value locked by the output of the respective channel open transaction. Together, the first and second amounts are at most equal to the maximum value. As explained below, the first and second amounts may be less than the maximum value.

[0086] For each payment channel, the intermediary 303 uses one of the respective channel close transactions to close the payment channel by submitting that close channel transaction to the blockchain network 106. The transaction used to close a payment channel is called a final channel close transaction. The intermediary 303 may submit the final channel close transaction to the blockchain network 106, or the second party 302 may submit the final channel close transaction to the blockchain network 106.

[0087] As each payment channel is closed by submitting the respective final channel close transaction to the blockchain network 106, the intermediary 303 generates a payment transaction. The payment transaction comprises, for each final channel close transaction, a respective input that references the respective output of that respective final channel close transaction, which is locked to the public key of the intermediary 303. Each respective input is signed by the intermediary 303. The payment channel transaction includes an output locked to a public key controlled by the second party 302.

[0088] A payment transaction may include metadata related to one, some, or all of the payments, e.g., a respective first party identifier, a payment reference, etc. A channel open transaction and / or a channel close transaction may also comprise metadata related to each payment in each payment channel.

[0089] In some examples, the intermediary 303 may deduct a service fee for facilitating the payment, examples of which are shown below in Tables 8, 9, and 10, which show examples of a channel open transaction, a channel close transaction, and a payment transaction, respectively.

[0090] 5 shows an example system 500 in which an intermediary 303 establishes multiple payment channels, one for each first party 301, to make payments to each first party 301 on behalf of the second party 302. Each first party 301, intermediary 303, and second party may be configured to perform any of the actions described above as being performed by Alice 103a and / or Bob 103b with reference to FIGS. 1 and 2. The system 500 may include any number, n, of first parties 301. In these embodiments, each first party 301 may supply respective goods and / or services to the second party 302 in exchange for payment.

[0091] The intermediary 303 obtains a funding transaction being generated by a 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 locks an amount equal to at least a plurality of respective maximum values, each maximum value associated with a maximum payout to a respective first party 301. The amount may include a service fee for collection by the intermediary 303. The intermediary 303 may obtain the funding transaction from the blockchain 150 or from the second party 302.

[0092] The intermediary 303 establishes a respective payment channel with each first party 301, i.e., one for each first party 301. In these embodiments, establishing the respective payment channel comprises obtaining (e.g., generating) a respective channel open transaction. Each respective channel open transaction comprises an input signed by the intermediary party 303. That is, the input references the output of a previous transaction, where the output is controlled by (i.e., locked to) a public key owned by the intermediary party 303. Each respective channel open transaction comprises an output locked to the public key of the respective first party 301 and the public key of the intermediary 303 (e.g., the output may be a multi-signature output). The output of each respective channel open transaction locks a respective maximum value, i.e., an amount (e.g., satoshis) of the digital asset underlying the blockchain 150.

[0093] The intermediary 303 and each respective first party 301 execute a respective payment channel. This involves obtaining one or more respective channel close transactions for each respective payment channel. For each payment channel, each of the one or more respective channel close transactions comprises a respective input that references the output of the respective channel open transaction used to open that payment channel. The input may be signed by the intermediary 303 and / or the respective first party 301. Each of the one or more respective payment channel close transactions comprises a respective output locked to the public key of the respective first party 301 and a respective output locked to the public key of the intermediary 303. The output locked to the first party's public key locks a first amount of the respective maximum value locked by the output of the respective channel open transaction. Similarly, the output locked to the intermediary's public key locks a second amount of the respective maximum value locked by the output of the respective channel open transaction. Together, the first and second amounts are at most equal to the respective maximum value. As explained below, the first and second amounts may be less than the maximum value.

[0094] For each payment channel, the intermediary 303 uses one of the respective channel close transactions to close the payment channel by submitting that close channel transaction to the blockchain network 106. The transaction used to close a payment channel is called a final channel close transaction. The intermediary 303 may submit the final channel close transaction to the blockchain network 106, or each first party 301 may submit the final channel close transaction to the blockchain network 106.

[0095] The funding transaction may include metadata related to one, some, or all of the payments, e.g., respective first party identifiers, payment references, etc. The channel open transaction and / or channel close transaction may also comprise metadata related to each payment in each payment channel.

[0096] Tables 11, 12, and 13 below show examples of a funding transaction, a channel open transaction, and a channel close transaction, respectively.

[0097] It will be appreciated that terms used herein such as "funding," "payment," "channel opening," "channel closing," etc. are merely used as labels for particular transactions.

[0098] 7. Exemplary Payment Channel Aggregator This section describes an exemplary payment channel aggregator (PCA) according to an embodiment of the present disclosure, i.e., a system that facilitates the inclusion of an intermediary (I-Ivan) between a pair of parties (A-Alice and B-Bob) who previously used a direct payment channel between them (Alice and Bob).

[0099] 7.1 One-to-one 3 illustrates an exemplary system 300 for facilitating payments between a first party 301 and a second party 302 using an intermediary party 303. For convenience, the first party will be referred to as Alice 103a, the second party as Bob 103b, and the intermediary party as Ivan 303. In the case of a one-to-one payment, it is assumed that party Alice 103a will make intermittent payments to Bob 103b for services or goods, which would previously have been done via a payment channel between both parties. However, in PCA for that scenario, an intermediary (Ivan) 303 is utilized to process payments from Alice 103a to Bob 103b.

[0100] PCA involves the following steps: - Ivan 303, Alice 103a, and Bob 103b come to an agreement whereby Ivan 303 will collect payments from Alice 103a, and then Ivan 303 will subsequently (possibly by a specified deadline) transfer these funds to Bob 103b. - Alice 103a and Ivan 303 create a payment channel between them that will be utilized to facilitate intermittent payments to Ivan 303. This involves creating a funding transaction that may refund Alice 103a (or pay Ivan 303) a maximum amount of Max BSV. At the conclusion of Alice's payment, the "payment channel is closed" (i.e., the settlement transaction is submitted to the blockchain 150). - Ivan 303 is the value of the payment transaction x f to Bob103b. (Ivan303 transfers x to Bob103b.) f (Note that rather than being a flat fee, this service fee may be proportional to the amount that Ivan (on behalf of Bob 103b) is able to collect from Alice 103a. This is reflected in the refund transaction T r,i+1 Service fee for SC i+1Refund transaction T r,i Service fee for SC i Because it will be greater than To prevent the increased service fee from reducing the payment to Bob 103b, an additional input may be added to the refund transaction that serves to fund the service fee.

[0101] For the payment channel used, a funding transaction T c , and a refund transaction T r,i An example of one of these is shown in Table 5 and Table 6, respectively. An OP_RETURN output may be included in both transactions to accumulate metadata about the agreement between Alice 103a, Bob 103b, and Ivan 303. This metadata may include data about the transaction. For example, in the case of a Netflix subscription, the metadata may include a hash of the license agreement, a subscription ID, a start date, an end date, and the particular tier of service requested, etc.

[0102] [Table 5]

[0103] [Table 6]

[0104] When Ivan 303 is to make a payment to Bob 103b, this is done through a P2PKH transaction (T Payment ) This transaction can be done using the payment T r,kConsume Ivan's UTXO in the transaction. Metadata may be included in the payment transaction that will link the payment to Alice's subscription. This may include the metadata mentioned above, such as the subscription ID, plus additional information, such as the last iteration to be signed (e.g., paid out until June 2022), the hash of the payment refund transaction, etc.

[0105] [Table 7]

[0106] 7.2 Many-to-One 4 illustrates an exemplary system 400 for facilitating payments between multiple first parties 301a, 301b, ..., 301n and a second party 302 using an intermediate party 303. For convenience, each first party is referred to as Alice 103a, the second party as Bob 103b, and the intermediate party as Ivan 303. In the many-to-one case, there are multiple Alices {Alice} who will make intermittent payments to Bob 103b for services or goods. j j∈[1,n]}. (For example, multiple subscribers need to pay monthly to Netflix.)

[0107] This means that subscriber Alice j For each, this was previously carried out between Alice and Bob via their individual respective payment channels (e.g., Netflix).

[0108] However, with PCA, an intermediary, Ivan 303, is utilized to manage these payments. This intermediary 303 accepts recurring payments per channel, and then finally submits the payment transaction to the blockchain 150. The combined value of these n payment transactions is then transferred by Ivan 303 to Bob 103b.

[0109] The following steps are performed: - Each Alice j reaches their agreement with Bob 103b and Ivan 303, which means that Ivan 303 can j The agreement is that Ivan 303 will collect payments from Bob 103b, and then Ivan 303 will subsequently (possibly by a specified deadline) transfer the value of each payment transaction to Bob 103b. - Alice j and Ivan 303 create a payment channel between them, which will be utilized as a regular payment channel to facilitate intermittent payments to Ivan 303. - At the end of Alice's payment, the payment channel is closed. - After n channels are closed, Ivan 303 receives the combined value of n payment transactions.

[0110]

number

[0111] to Bob 103b. This may take the form of one or more payment transactions.

[0112] A single final payment from Ivan 303 to Bob 103b (the example transaction shown in Table 8) and an agreed-upon final deadline s for Ivan's payment to Bob 103b. close , this means that the latest nLockTime value for any of the n payment channels is s close The latest lock time of the payment channel must be less than s r,i+1 r,i Note that the latest lock time of the n payment channels is the nLockTime of the first iteration of the refund transaction of the channel with the latest time. Therefore, the latest lock time of the n payment channels will be the first iteration of the refund transaction of these channels with the latest time.

[0113] ​Alice j and the payment channel used for Ivan 303, the funding transaction

[0114]

number

[0115] An example of a refund transaction

[0116]

number

[0117] One of these is shown below in Table 9 and Table 10.

[0118] [Table 8]

[0119] [Table 9]

[0120] After all payment transactions for all payment channels have been received by Ivan 303, Ivan 303 can then proceed to make a payment of the combined total to Bob (e.g., Netflix). He makes this payment by consuming the appropriate UTXO in a payment refund transaction. An example of this payment from Ivan to Bob is shown in Table 10. The metadata in this transaction is stored in the j and Ivan 303. More specifically, it may include a hash of the payment transaction as well as individual "subscription" details.

[0121] [Table 10]

[0122] 7.3 One-to-Many 5 illustrates an exemplary system 500 for facilitating payments between a second party 302 and multiple first parties 301a, 301b, ..., 301n using an intermediate party 303, where n can be any number. For convenience, the second party 302 will be referred to as Alice 103a, each first party as an instance of Bob 103b, and the intermediate party as Ivan 303. In the one-to-many case, multiple Bobs {Bob k |k∈[1,m]} and a single Alice. An example of this would be an individual subscribing to multiple services. Consider Alice 103a, who subscribes to subscription services such as Netflix, Amazon Prime, and Disney+. Rather than personally transacting with multiple service providers, Alice 103a makes a lump sum payment to an intermediary, Ivan 303, which then processes the payments to each provider.

[0123] Using PCA techniques for the above scenario, an intermediary, Ivan 303, is again utilized to manage these payments. This intermediary 303 accepts a lump sum payment from Alice 103a and then establishes m payment channels between the set of Bobs.

[0124] The following steps are performed: - Alice 103a discusses with Ivan 303 the criteria for when to submit a payment transaction (i.e., no longer increase the amount being paid to Bob in the refund transaction). Alice 103a calculates the service fee sc plus the maximum different sums that may be paid per channel, i.e.,

[0125]

number

[0126] Payment will be made to Ivan 303. - Ivan 303, himself and each Bob k create m payment channels between k It will be used as a regular payment channel to facilitate intermittent payments to the - Ivan 303 and corresponding Bob for the final refund transaction (payment transaction) k Once this is agreed upon, each payment channel is closed.

[0127] Payment channel, Ivan → Bob k Funding transactions

[0128]

number

[0129] An example of a refund transaction

[0130]

number

[0131] One of them is shown below:

[0132] [Table 11]

[0133] [Table 12]

[0134] Alice 103a will be funding the intermediary Ivan using a regular P2PKH transaction as shown in Table 13. Note that the funding includes the service fee sc.

[0135] [Table 13]

[0136] 8. Further Special Notes Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited not by the described embodiments, but only by the appended claims.

[0137] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0138] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, issuing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the function of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be nodes of the suitable Bitcoin network 106).

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

[0140] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 104.

[0141] Some embodiments are described with respect to a blockchain network implementing 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 may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The node that is chosen is often called a validator. Blockchain nodes can look up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

[0142] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0143] Statement 1. A computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, the method being performed by an intermediate party; executing a respective payment channel between each respective first party and an intermediate party; obtaining respective channel open transactions, each comprising a respective input signed by a respective first party and a respective output locked to a respective public key of the respective first party and a public key of the intermediate party, each output locking a respective maximum value; Obtaining one or more respective channel close transactions, including a respective final channel close transaction, wherein each final channel close transaction comprises a respective input referencing a respective output of a respective channel open transaction and comprising a respective signature of a respective first party and a signature of an intermediate party, and a respective first output locked to a respective public key of the respective first party and a respective second output locked to a public key of the intermediate party, wherein each first output locks a respective first amount of a respective maximum value and each second output locks a respective second amount of a respective maximum value; and executing a respective payment channel comprising: generating a payment transaction, the payment transaction comprising a plurality of respective inputs, each respective input referencing a respective second output of a respective final channel close transaction and comprising a signature of an intermediate party, and an output locked to a public key of a second party, the output locking a value based on a sum of respective second amounts locked by the respective second outputs; Equipped with.

[0144] Statement 2. The method of Statement 1, wherein the payment transactions comprise metadata relating to one, some, or all of the respective payments.

[0145] Statement 3. The method of Statement 1 or Statement 2, wherein, for each payment channel, each first amount of each maximum value is equal to each maximum value minus a third amount of each maximum value and minus a service fee value, and each second amount of each maximum value is equal to the third amount of each maximum value plus a service fee value.

[0146] Statement 4. A computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, the method being performed by an intermediate party; capturing a funding transaction generated by a second party, the funding transaction comprising an input comprising the signature of the second party and an output locked to the public key of the intermediate party, the output locking an amount at least equal to the sum of a plurality of respective maximum values; and executing a respective payment channel between each respective first party and the intermediate party, wherein executing the respective payment channel comprises: obtaining respective channel open transactions, each comprising a respective input signed by an intermediate party and a respective output locked to a respective public key of a respective first party and a public key of the intermediate party, each output locking a respective maximum value; obtaining one or more respective channel close transactions including a respective final channel close transaction, wherein each final channel close transaction comprises a respective input that references a respective output of a respective channel open transaction and comprises a respective signature of a respective first party and a signature of an intermediate party, and a respective first output locked to a respective public key of the respective first party and a respective second output locked to a public key of the intermediate party, wherein each first output locks a respective first amount of a respective maximum value and each second output locks a respective second amount of a respective maximum value.

[0147] Statement 5. The method of Statement 4, wherein the funding transaction comprises metadata relating to one, some, or all of the respective payments.

[0148] Statement 6. The method of Statement 4 or Statement 5, wherein the outputs of the funding transactions lock an amount equal to the sum of their respective maximum values ​​plus a service fee.

[0149] Statement 7. The method of any preceding statement, wherein, for one, some, or all of the respective payment channels, the respective channel open transaction and / or the respective final channel close transaction comprises metadata relating to the respective payment.

[0150] Statement 8. The method of any preceding statement, wherein each output of each channel open transaction and / or each output of each channel close transaction comprises a multi-signature lock script.

[0151] Statement 9. The method of Statement 1 or any statement subordinate thereto, wherein the second party provides the respective goods and / or respective services to the respective first party in exchange for a respective payment.

[0152] Statement 10. The method of Statement 4 or any statement subordinate thereto, wherein each respective first party provides a respective good and / or respective service to a second party in exchange for a respective payment.

[0153] Statement 11. A computing device comprising: a memory having one or more memory units; and a processing device having one or more processing units, the memory storing code configured to execute on the processing device, the code configured, when on the processing device, to perform the method of any of statements 1 to 10.

[0154] Statement 12. A computer program embodied on computer-readable storage and configured to perform the method of any of statements 1 to 10 when executed on one or more processors.

[0155] According to another aspect disclosed herein, a method may be provided that comprises an intermediate party and the actions of one or both of i) a plurality of first parties and ii) a second party.

[0156] According to another aspect disclosed herein, a system may be provided that includes i) a plurality of first party and ii) second party computer devices. [Explanation of symbols]

[0157] 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 103 Users, Entities, Parties, and Agents 103a Alice 103b Bob 104 nodes, blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Peer-to-peer (P2P) networks, decentralized networks, blockchain networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input, input field 203 Outputs, Output Fields, and UTXOs 300 System 301 First Party 302 Second Party 303 Ivan, the mediator, the middleman 400 System 500 Systems

Claims

1. 1. A computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, the method being performed by an intermediate party; executing a respective payment channel between each respective first party and said intermediate party, obtaining respective channel open transactions, the respective channel open transactions comprising respective inputs signed by the respective first parties and respective outputs locked to the respective public keys of the respective first parties and the public keys of the intermediate parties, the respective outputs locking respective maximum values; obtaining one or more respective channel close transactions, including a respective final channel close transaction, wherein the respective final channel close transactions have respective inputs that reference the respective outputs of the respective channel open transactions and comprise respective signatures of the respective first parties and signatures of the intermediate parties, and respective first outputs locked to respective public keys of the respective first parties and respective second outputs locked to public keys of the intermediate parties, wherein the respective first outputs lock respective first amounts of the respective maximum values ​​and the respective second outputs lock respective second amounts of the respective maximum values; executing said respective payment channels, generating a payment transaction, the payment transaction comprising a plurality of respective inputs, each respective input referencing a respective second output of a respective final channel close transaction and comprising a signature of the intermediate party, and an output locked to the public key of the second party, the output locking a value based on a sum of the respective second amounts locked by the respective second outputs; A method for providing the above.

2. The method of claim 1 , wherein the payment transactions comprise metadata relating to one, some, or all of the respective payments.

3. 3. The method of claim 1 or 2, wherein, for each payment channel, the respective first amount of the respective maximum value is equal to the respective maximum value minus the respective maximum value third amount and minus a service charge value, and the respective second amount of the respective maximum value is equal to the respective maximum value third amount plus the service charge value.

4. 1. A computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, the method being performed by an intermediate party; obtaining a funding transaction generated by the second party, the funding transaction comprising an input comprising the signature of the second party and an output locked to the public key of the intermediate party, the output locking an amount at least equal to the sum of a plurality of respective maximum values; and executing a respective payment channel between each respective first party and the intermediate party, wherein executing the respective payment channel comprises: obtaining respective channel open transactions, the respective channel open transactions comprising respective inputs signed by the intermediate party and respective outputs locked to the respective public keys of the respective first parties and the public keys of the intermediate parties, the respective outputs locking respective maximum values; obtaining one or more respective channel close transactions, including a respective final channel close transaction, wherein the respective final channel close transactions have respective inputs that reference the respective outputs of the respective channel open transactions and comprise respective signatures of the respective first parties and signatures of the intermediate parties, and respective first outputs locked to respective public keys of the respective first parties and respective second outputs locked to public keys of the intermediate parties, wherein the respective first outputs lock respective first amounts of the respective maximum values ​​and the respective second outputs lock respective second amounts of the respective maximum values; A method comprising:

5. The method of claim 4 , wherein the funding transaction comprises metadata relating to one, some, or all of the respective payments.

6. 6. The method of claim 4 or 5, wherein the outputs of the funding transactions lock in an amount equal to the sum of the respective maximum values ​​plus a service fee.

7. 7. The method of claim 1, wherein for one, some, or all of the respective payment channels, the respective channel open transaction and / or the respective final channel close transaction comprises metadata relating to the respective payment.

8. 8. The method of claim 1, wherein the respective output of the respective channel open transaction and / or the respective output of the respective channel close transaction comprises a multi-signature lock script.

9. 10. The method of claim 1 or any one of its dependent claims, wherein the second party provides the respective first party with the respective goods and / or services in exchange for the respective payments.

10. 10. A method according to claim 4 or any of its dependent claims, wherein each respective first party provides a respective good and / or a respective service to the second party in exchange for the respective payment.

11. A computer device comprising: a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to run on the processing device, the code being configured to perform the method of any one of claims 1 to 10 when present on the processing device.

12. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 10 when executed on one or more processors.

Images