Payment Channel Aggregator

Abstract

1. A computer-implemented method for facilitating payments between a first party and a second party, wherein each first party and second party is configured to create a respective payment channel by generating a channel opening transaction including an input signed by the second party and an output locked to the respective first party's public key and the second party's public key, the output locking a respective maximum value; the method comprising: for each respective first party, obtaining one or more channel closure transaction templates from the second party, each channel closure transaction template including an input referencing the output of the respective channel opening transaction and including a signature of the second party, as well as a first output locked to the first party's public key and a second output locked to the second party's public key, the first output locking a first amount of the respective maximum value and the second output locking a second amount of the respective maximum value; and sending a selected one of the one or more channel closure transaction templates to the respective first party.

Description

[Technical Field]

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

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

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to convey digital assets (i.e., numbers of digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. Blockchains can 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 in transactions. There is no pre-specified limit to 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 in the blockchain.

[0004] Nodes (often called "miners") in a blockchain network implement a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a block template to attempt to identify a valid proof-of-work solution. Once a valid solution is found, the new block is propagated to other nodes in the network, thus enabling each node to record the new block in 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 the new block. Each node is configured to enforce 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) therefore remains registered and indexed at each of the nodes in the blockchain network as an immutable official record.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are generally rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e., the number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, who act as agents of the network and are incentivized to report and prevent fraud. Large-scale publication of information allows users to constantly audit node performance. Publication of a few block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Every spendable output includes an element specifying the amount of a digital asset derivable from the transaction's procedural sequence. A spendable output is sometimes called a UTXO (unspent transaction output). This output may further include a locking script that specifies the conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to activate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such output in a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as the first and second transactions (or “target” transactions). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input that includes 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 the second, target transaction is sent to the blockchain network for propagation and recording in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but potentially to register an invalid transaction) or include it in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of a previous transaction in a sequence of past transactions, but rather by reference to absolute account balances. The current state of all accounts is stored and frequently updated by nodes separate from the blockchain. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] https: / / nchain.com / payment-channels-and-smart-contracts-on-bitcoin / Summary of the Invention [Means for solving the problem]

[0010] In the blockchain context, a payment channel refers to 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 be made between two parties without putting the entire set of transactions into 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 repeated negotiations, or it may be the sum of a set of periodic payments.

[0011] For the latter, the example of a one-year subscription (e.g., to a streaming platform such as Netflix) may be considered, which includes 12 monthly payments. For each month, a valid and secure copy of the transaction is given by the customer to the streaming platform. The streaming platform can submit the transaction to the blockchain if it wishes to do so. Each month's transaction includes a payment that is the accumulation of the amount due for the current month and previous months. However, the streaming platform only submits the final transaction to the blockchain. This transaction includes the accumulated payments for all 12 months.

[0012] Typically, it is expected that a payment channel will be established between two parties: a payment source (e.g., Alice) and an intended recipient of payment (e.g., Bob), where Bob will be the provider of goods / services, although as recognized herein, in some situations an intermediary may be desirable.

[0013] According to one aspect disclosed herein, a computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and second party is configured to create a respective payment channel by generating a respective channel opening transaction including a respective input signed by the second party and a respective output locked to a respective public key of the respective first party and a public key of the second party, the respective outputs locking a respective maximum value, the method being performed by an intermediary party and comprising: obtaining one or more respective channel closure transaction templates from the second party, each respective channel closure transaction template including a respective input referencing a respective output of a respective channel opening transaction and including a respective signature of the second party, and a respective first output locked to a respective public key of a respective first party and a respective second output locked to a public key of the second 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 sending to each first party a selected one of the one or more respective channel closure transaction templates.

[0014] In this embodiment, an intermediary is used to facilitate payments between one or more payment sources and payment destinations. A payment channel is first established between each payment source and payment destination. However, instead of the payment channel being executed by the payment source and payment destination, the intermediary is used to remove the burden from these parties. The intermediary collects channel closure transactions (i.e., refund or settlement transactions) from the parties and closes each individual payment channel using one of the closure transactions, e.g., a transaction that transfers the largest amount to the payment destination.

[0015] As an example, a streaming platform may outsource the collection of its subscription fees to a third-party collection agency that collects transactions that transfer the subscription fees to the platform and submits the transactions to the blockchain, e.g., after payment of an agreed amount, after an agreed amount of time, in response to a request from the payment source, etc. This is a more efficient process than each user having to individually engage with the streaming platform for each iteration of the payment channel, e.g., each payment round.

[0016] According to another aspect disclosed herein, a computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and second party is configured to create a respective payment channel by generating a respective channel opening transaction including a respective input signed by the second party and a respective output locked to a respective public key of the respective first party and a public key of the second party, the respective outputs locking a respective maximum value, the method being performed by an intermediary party and comprising: obtaining one or more respective channel closure transaction templates from the second party, each respective channel closure transaction template including a respective input referencing a respective output of a respective channel opening transaction and including a respective signature of the second party, and a respective first output locked to a respective public key of a respective first party and a respective second output locked to a public key of the second 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 sending to each first party a selected one of the one or more respective channel closure transaction templates.

[0017] In this aspect, an intermediary is used to facilitate payments between a payment source and multiple payment destinations. A payment channel is first established between the payment source and each payment destination. However, instead of the payment channel being executed by the payment source and the payment destination, the intermediary collects a channel closure transaction (i.e., a refund or settlement transaction) from the payment source and sends the channel closure transaction to the payment destination for submission to the blockchain, e.g., after signing the channel closure transaction.

[0018] 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 collect these payments on the party's behalf.

[0019] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be put into practice, 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 on 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. Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore strongly connected to other blockchain nodes 104.

[0022] Each blockchain node 104 comprises a peer's computing equipment, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing units 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 utilizing 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 includes 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 or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (discussed later) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain consistently uses one particular transaction protocol. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, an example of which is a 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 to an output of a previous transaction 152, thereby linking the transactions.

[0024] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain, defining a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to the previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to branch). The chain of blocks 151 stretches all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 pointed to the genesis block 153 rather than to a predecessor transaction earlier in the chain 150.

[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 its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is 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 has accepted as valid and that the node 104 is obligated not to accept any other transactions that attempt to spend the same output.

[0026] For a given current transaction 152j, the (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output must be redeemed or "spent" in the current transaction 152j. Spending or redemption does not necessarily imply a transfer of financial assets, although that is certainly one common use. More generally, spending may be described as consuming an output or allocating it to one or more outputs in another, subsequent transaction. In general, a previous transaction may be any transaction in an ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist when a current transaction 152j is created or sent to the network 106, but a previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "predecessor" herein refers to a predecessor in a logical sequence, linked by a pointer, not necessarily to a time of creation or transmission in a time sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may also be referred to as an ancestor or predecessor transaction.

[0027] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to which the output of the previous transaction 152i is locked. In contrast, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. The current transaction 152j can thus transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 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 to pass on change). In some cases, a transaction may also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and reallocate them to 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 an organization, wishes to enact a new transaction 152j (either manually or through an automated process employed by that party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient ultimately sends this transaction to one or more blockchain nodes 104 of the network 106 (which nowadays is typically a server or data center, but could in principle be other user terminals). It is not excluded that the party 103 enacting the new transaction 152j can send the transaction directly to one or more of the blockchain nodes 104, and in some instances not to a recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain node protocol applied at each of the blockchain nodes 104. Blockchain node protocols generally require blockchain nodes 104 to check that a cryptographic signature in a new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may include checking that a cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction spends (or “allocates”), which condition generally includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input is linked. The condition may be defined, at least in part, by a script included in the output of the previous transaction 152i.Alternatively, the conditions may be solely determined by the blockchain node protocol, or a combination thereof. In either case, 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 thus forward the new transaction 152j onto one or more additional nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

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

[0030] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work." 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. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Generally, this involves searching for a nonce value such that, when the "nonce" value is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has some predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. The property of a hash function is that it has an unpredictable output 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] A first blockchain node 104 that solves a 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 (when the solution is provided as a hash, it is easy to check that the hash output satisfies the conditions). The first blockchain node 104 propagates the block until threshold consensus of other nodes accepts the block and thus enforces the protocol rules. The ordered set of transactions 154 is then recorded in the blockchain 150 as a new block 151 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The significant amount of work, e.g., in the form of a hash, required to create the proof-of-work solution 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 spends or allocates the same output as a previously validated transaction, commonly known as a double spend. Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, thus providing an immutable public ledger of transactions.

[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 of not-yet-published transactions 154, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves each 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 unpublished transactions is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unpublished transactions, and so on. Protocols also exist to resolve any "forks" that may occur, where two blockchain nodes 104 solve a puzzle within a very short time interval of each other so that conflicting views of the blockchain are propagated between the nodes 104. In essence, the longest branch of the fork becomes the final blockchain 150. Note that this should not affect users or agents of the network, as the same transaction will appear on both branches.

[0033] According to the Bitcoin blockchain (and most other blockchains), nodes that successfully construct a new block 104 are granted the ability to allocate additional allowances of digital assets in a new, special type of transaction that distributes an additional defined amount of the digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a fixed 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.” This generally forms the first transaction of a new block 151n. The proof of work signals the node’s intent to construct the new block to follow 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 canonical (non-generational) 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 discussed below.

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

[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 handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action 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 at a lower layer, such as the operating system layer or the protocol layer, or any combination thereof.

[0036] Also connected to the network 101 are computer devices 102 for each of a number of parties 103 in the role of consuming users. 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 storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0037] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on 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 roles required of blockchain nodes. Instead, each party 103 may use the blockchain 150 by interacting with the blockchain network 106 and, in doing so, connecting to (i.e., communicating with) a blockchain node 104. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computing device 102a, and a second party 103b and its respective computing device 102b. It will be understood that more such parties 103 and their respective computing devices 102 may be present and participating 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, first party 103a is referred to herein as Alice and second party 103b is 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 includes 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 includes memory, i.e., computer-readable storage, in the form of one or more non-transitory computer-readable media. This memory may include one or more memory units utilizing 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 including a respective instance of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed to a given party 103 herein may be performed using software running on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 includes 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 include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0039] The client application 105 may initially be 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 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, a CD or DVD ROM, or an optical disk such as a removable optical drive.

[0040] The client application 105 includes at least a "wallet" function. This 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 are then propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other function is to report back to each party on the amount of digital assets that it currently owns. In an output-based system, this second functionality involves reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0041] NOTE: While various client functionalities may be described as being integrated into a given client application 105, this is not necessarily limiting, and any client functionality described herein may instead be implemented in a series of two or more separate applications that interface, for example, by an API or one that is a plug-in to the other. More generally, client functionality may be implemented at the application layer or 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 enables a wallet function on 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 in which the respective party 103 is a recipient (or indeed to inspect other parties' transactions in the blockchain 150, since in some embodiments, the blockchain 150 is a public facility that grants trust to transactions, in part due to public recognition). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 runs 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 synchronized with a given node protocol, and together they 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, e.g., Alice, wishes to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in her client application 105) according to an appropriate transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which Alice 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 handles it according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or defined by a combination of the script and the node protocol.

[0044] Provided that the newly received transaction 152j passes the checks to be considered valid (i.e., 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 toward one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction will quickly propagate throughout the entire network 106.

[0045] Once a pending transaction is approved for addition to the ordered pool 154 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 each pool 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 the first node to solve it defines the set of transactions included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, the transaction immutably becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0046] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid" before one instance is published in a new block 151 and 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 must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

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

[0048] 2. UTXO-based model Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol, although this is not limiting for all possible embodiments. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but may be similarly implemented on other exemplary blockchain networks.

[0049] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens in a distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In some 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, suppose Alice 103a wishes to create transaction 152j that transfers a certain amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are simply arbitrary labels. 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 may point to any previous (i.e., ancestor) transaction that still has unspent output 203 locked to Alice.

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

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

[0053] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. The locking script specifies what information is needed to spend the transaction output 203, for example, Alice's signature is needed. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, the script might include Bob's signature. The unlocking script appears in the transaction input 202.

[0054] Thus, in the illustrated example, UTXO0 in Tx0's output 203 must have Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for subsequent transactions attempting to redeem UTXO0 to be valid). A Locking 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. Tx1's input 202 includes a pointer to Tx1 (e.g., using its transaction ID, i.e., TxID0, which in some embodiments is a hash of all transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script created by Alice that applies Alice's private key from a key pair to a predefined portion of data (sometimes called a "message" in cryptography), including Alice's cryptographic signature. <Sig P A The data (or "message") that needs to be signed by Alice to give a valid signature may be defined by the locking script, or by the node protocol, or a combination of these.

[0055] When a new transaction Tx1 arrives at a blockchain node 104, the node applies its node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (which may include one or more criteria). In some embodiments, this involves running the two scripts in <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function provided by the locking script (a stack-based language in this example). Equivalently, the scripts can be executed one after the other using a common stack rather than concatenating them. Either way, when executed together, the scripts will use Alice's public key P, which is included in the locking script in the output of Tx0.A to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected data portion. The expected data portion itself (the "message") must also be included to perform this authentication. In some embodiments, the signed data includes the entirety of Tx1 (thus a separate element specifying the signed data portion in plaintext need not be included, 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 with her private key and then provides 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 generally involves hashing the message, signing the hash, and attaching this as a signature to 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, part of a transaction, etc., can, in some embodiments, mean signing a hash of that piece of data or part of a transaction.

[0057] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, in the illustrated example, if Alice's signature is given in Tx1 and authenticated), 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, thereby propagating the transaction 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 become valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether a referenced UTXO in a prior transaction Tx0 has already been 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 defined order on transactions 152. Indeed, while a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, ultimately what defines whether a UTXO has been 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 pointed to by all of its inputs 202, this is another ground of 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 bulk. A small portion of the amount defined to be spent in a UTXO cannot be "left over" while another small portion is spent. However, an amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to pay another party.

[0060] In fact, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully included 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 and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do 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 that specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or spent) by the node 104 that won the proof-of-work competition to create the block containing UTXO1. However, this does not necessarily exclude that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0061] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, in general, a given party 103's assets are scattered across all of the UTXOs in various transactions 152 throughout the blockchain 150. No single number defining a given party's 103 total balance is stored anywhere in the blockchain 150. It is the responsibility of a wallet function in the client application 105 to reconcile the values ​​of all of the various UTXOs locked to each party that have not yet been spent in another subsequent transaction. This function can do this by querying a copy of the blockchain 150 stored in one of the Bitcoin nodes 104.

[0062] Note that script code is often represented generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode 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 locking script, stores data within the transaction, thereby creating an unspendable output of the transaction that can be immutably recorded on the blockchain 150. For example, the data may include a document that is desired to be stored on the blockchain.

[0063] In general, the input for a transaction is a public key P AIn some embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs one 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 parts of the outputs it signs depend on the SIGHASH flag, which is typically a four-byte code included at the end of the signature (and therefore determined at the time of signing) that selects which outputs are signed.

[0064] A locking script is sometimes referred to as a "scriptPubKey" in reference to the fact that it generally includes the public key of the party whose respective transaction is locked. An unlocking script is sometimes referred to as a "scriptSig" in reference to the fact that it provides the corresponding signature. However, more generally, it is not essential in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may also be used to define 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 102a, 102b, respectively, may include additional communication functionality. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 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 (yet) being registered on the blockchain network 106 or advancing to 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.” The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 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 different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 referred to anywhere herein may include any one or more links over one or more networking technologies or communication media for exchanging data “off-chain,” i.e., separately from the blockchain network 106. Where multiple links are used, the bundle or collection of off-chain links may be collectively referred to as the side channel 107. Thus, when Alice and Bob are said to exchange some information or data, etc., over the side channel 107, it should be noted that this does not necessarily imply that all of this data must be sent over the exact same links or the same type of network.

[0067] 4. Payment Channels A typical payment channel implementation allows an almost unlimited number of payments to be made, but requires only two transactions to be added to the blockchain 150. In addition to the reduced number of transactions being added to the blockchain and the associated reduction in cost, storage, and bandwidth usage, payment channels also provide the advantage of speed and the ability for the payment source to have funds withdrawn if things do not go as planned or if either party decides not to proceed beyond a particular set of payments. A description of payment channel implementations is outlined below.

[0068] First, Note that "for each Bitcoin transaction, there can be multiple inputs. For each input, there is a parameter called a sequence number. This number is an indication of whether the transaction containing this input is finished. If this parameter does not have its maximum value (0xFFFFFFFF), the validation process consults the lock time field (defined at the transaction level), which specifies the time when the transaction becomes valid; i.e., the transaction will not become valid until the lock time. This can be useful when the specified time is in the future. (The furthest time that can be chosen for the lock time is approximately 9,500 years into the future, as of this writing.) Before the lock time of a given transaction has elapsed, a new version of that transaction with a higher sequence number can invalidate an earlier version that spends the same inputs but has a lower sequence number." [https: / / nchain.com / payment-channels-and-smart-contracts-on-bitcoin / ]

[0069] Now consider a scenario in which Alice 103a needs to pay Bob 103b for a service, which may require multiple payments from Alice 103a to Bob 103b over a period of time, depending on the circumstances. Alice 103a expects to spend at most 15 BSV (in total) to Bob 103b in a set of possible exchanges. To facilitate this, a payment channel is established between Alice 103a and Bob 103b, which operates as follows:

[0070] Alice sends a 2-of-2 multi-signature transaction, T, which inserts 15 BSV from Alice 103a. c The multi-signature locking script requires that any transaction that spends the corresponding locked output be signed by two individuals (Alice and Bob). 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, returning all funds from the multi-signature control fund 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 be executed only after a specified time has elapsed. Bob 103b signs the blockchain transaction. This refund transaction allows a refund to Alice 103a after nLockTime diverges if the exchange between Alice 103a and Bob 103b does not go well.

[0075] [Table 2]

[0076] Alice 103a transfers the original transaction T cAt this point, Alice 103a and Bob 103b may proceed to create new withdrawal transactions to reflect the (off-chain) payments made from Alice 103a to Bob 103b. These withdrawal transactions reflect the net amount Alice 103a is required to pay Bob 103b at that time. As an example, if Alice 103a is to pay Bob 103b 5 BSV, then a new withdrawal transaction, T, with outputs sending 5 BSV to Bob 103b and 10 BSV back to Alice 103a, may be created. r,i If Alice 103a needs to pay another 5 BSV to Bob 103b, she creates a new refund transaction, T, with outputs sending 10 BSV to Bob 103b and 5 BSV to Alice 103a. r,i+1 For each new refund transaction, assuming they agree on the details, both parties sign the transaction but do not necessarily submit it to the network 106.

[0077] [Table 3]

[0078] [Table 4]

[0079] Each successive refund transaction created has a lower nLockTime and a higher sequence number than the previous refund transaction, i.e. s r,i+1 r,i Note that a party has a T r,i If the complaining party refuses to sign the T r,i-1 In the worst case scenario, Alice 103a can submit T r,0 ​, and submits it to the network 106, recovering all of Alice's funds (after nLockTime expires). The final withdrawal transaction constructed represents the net amount of funds transferred from Alice 103a to Bob 103b. This transaction is submitted to the network 106. A withdrawal transaction submitted to the blockchain network 106 is referred to herein as a settlement transaction.

[0080] 6. Facilitating Blockchain Payments Embodiments of the present disclosure provide an intermediary 303 for facilitating payments between one or more first parties 301 and second parties 302. In some embodiments, the first party 301 is considered the payment source and the second party 302 is considered the payment recipient, as shown in Figures 3 and 4. In other embodiments, the second party 302 is considered the payment source and multiple first parties 301 are considered the payment recipient, as shown in Figure 5.

[0081] 3 shows an example system 300 in which an intermediary 303 is used to facilitate payments between a first party 301 and a second party 302. The first party 301, the intermediary 303, and the second party 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. In these embodiments, the second party 302 may supply the first party 301 with respective goods and / or services in exchange for payment.

[0082] 4 shows an example system 400 in which an intermediary 303 is used to facilitate payments between multiple first parties 301 and 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. In these embodiments, the second party 302 may supply each first party 301 with respective goods and / or services in exchange for payment.

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

[0084] The second party 302 sends to the intermediary 303 one or more respective channel closure transaction templates for each respective payment channel, i.e., for each first party 301 with whom the second party 302 established a respective payment channel by generating a respective channel opening transaction. A channel closure transaction template may also be referred to as a final transaction template or a refund transaction template. For each payment channel, each of the one or more respective channel closure transaction templates includes a respective input that references the output of the respective channel opening transaction used to open that payment channel. The input is signed by the second party 302. In some examples, the second party's signature may sign all of the outputs of the respective channel closure transaction template. Each of the one or more respective payment channel closure transaction templates includes a respective output locked to the public key of the respective first party 301, and each output has locked the public key of the second party 302. The output locked to the public key of the first party 301 locks a first amount of a respective maximum value locked by the output of the respective channel opening transaction. Similarly, the output locked to the public key of the second party 302 locks a second amount of each maximum value locked by the output of each channel opening transaction. Together, the first and second amounts are at most equal to the respective maximum values. As discussed below, the first and second amounts may be less than the maximum values. Note that the closed transaction template is called a template because it is missing at least one data item, in this case the signature of each first party 301.

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

[0086] For each respective payment channel, the intermediary 303 closes the payment channel by selecting one of the respective channel closure transactions and submitting the closure channel transaction to the blockchain network 106. The transaction used to close the payment channel is called the final channel closure transaction. The intermediary 303 may submit the final channel closure transaction to the blockchain network 106, or the intermediary 303 may send the final channel closure transaction to the second party 302, which may submit the final channel closure transaction to the blockchain network 106. The selected transaction may be the transaction with the highest amount locked in the public key of the second party 302.

[0087] The channel opening and / or channel closing transactions may include metadata about the payment associated with a particular payment channel, such as the respective first party 301 identifier, second party 302 identifier, payment reference number, etc.

[0088] In some examples, the intermediary 303 may deduct a service fee to facilitate payment, examples of which are shown below in Tables 5 and 6 (for a scenario with a single first party 301) showing example channel opening and closing transactions, respectively. Another example is shown below in Tables 7 and 8 (for a scenario with multiple first parties 301) showing example channel opening and closing transactions, respectively.

[0089] 5 shows an example system 500 in which an intermediary 303 is used to facilitate payments between multiple first parties 301 and 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 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 second parties 302 in exchange for payment.

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

[0091] The second party 302 sends to the intermediary 303 one or more respective channel closure transaction templates for each respective payment channel, i.e., for each first party 301 with whom the second party 302 established a respective payment channel by generating a respective channel opening transaction. For each payment channel, each of the one or more respective channel closure transaction templates includes a respective input that references the output of the respective channel opening transaction used to open that payment channel. The input is signed by the second party 302. In some examples, the second party's signature may sign all of the outputs of the respective channel closure transaction template. Each of the one or more respective payment channel closure transaction templates includes a respective output locked to the public key of the respective first party 301, and each output locked to the public key of the second party 302. The output locked to the public key of the first party 301 locks a first amount of a respective maximum value locked by the output of the respective channel opening transaction. Similarly, the output locked to the public key of the second party 302 locks a second amount of a respective maximum value locked by the output of the respective channel opening transaction. Together, the first and second amounts are at most equal to their respective maximum values. As discussed below, the first and second amounts may be less than their respective maximum values.

[0092] For each respective payment channel, the intermediary 303 selects one of the respective channel closure transaction templates and sends the selected channel closure transaction template to the respective first party 301. The selected transaction may be the transaction with the highest amount locked in the public key of the respective first party 301. The first party 301 then signs the respective channel closure transaction template, thereby completing the transaction. The completed channel closure transaction is then used to close the payment channel by submitting the channel closure transaction to the blockchain network 106.

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

[0094] 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 would previously have used a payment channel directly between the parties (Alice and Bob).

[0095] 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 301 will be referred to as Alice 103a, the second party as Bob 103b, and the intermediary party as Ivan 303. For one-to-one payments, it is assumed that party Alice 103a makes intermittent payments to Bob 103b for services or goods. This would have been previously performed via a payment channel between both parties. However, in PCA for the scenario, an intermediary (Ivan) 303 is used to handle payments from Alice 103a to Bob 103b.

[0096] If Ivan 303 cannot be trusted, then Ivan's responsibility is to collect the off-chain transactions (signed by Alice 103a) and then submit the payment transaction to the blockchain 150. These off-chain transactions have already been signed by Bob 103b. This may require Bob 103b to know in advance the possible values ​​of what these off-chain payments may be. This may be the case in an example such as Netflix, where monthly payments are a known amount and therefore the total charges over multiple months are predictable.

[0097] PCA involves the following steps: Ivan 303, Alice 103a, and Bob 103b agree that Ivan 303 will collect payment (an off-chain transaction signed by Alice 103a) from Alice 103a, and then Ivan 303 will submit a settlement transaction for the payment to the blockchain 150, e.g., before the deadline. - Alice 103a and Bob 103b create a payment channel between them, which involves creating a funding transaction that can refund an amount of Max BSV to Alice 103a. - For each payment (refund transaction) that can be made by Alice 103a to Bob 103b, Bob 103b creates a transaction template with the appropriate details in the output, signs the transaction, and gives this set of pre-signed transactions to the intermediary Ivan 303. Bob 103b signs this transaction using the sighash flag (SIGHASH_ALL|ANYONECANPAY) which signs all outputs of the transaction. An additional (e.g., OP_RETURN) output may be included with each refund transaction containing various metadata related to the transaction, for example, the month of the Netflix subscription for which the payment is being made, other client and provider details. - Ivan 303 engages with Alice 103a, and Alice signs a refund transaction each time they reach an agreement, so for example, if a Netflix subscription costs 10 BSV per month, at the end of month i, Alice 103a signs a refund transaction for 10i BSV. Alice 103a then sends this signed transaction to Ivan 303. - When Alice finishes paying (e.g., the end of a year's Netflix subscription, or Alice 103a declines to sign further refund transactions with larger accumulated fees), Ivan 303 submits the final, Alice-signed refund transaction (with the highest payment price) to the blockchain 150 as a settlement transaction, and the payment channel is closed. Intermediary Ivan 303 may be paid a service fee proportional to the cumulative fees received by Bob 103b, which serves as payment and incentive for Ivan to submit transactions and obtain higher cumulative settlement payments from Alice 103a. This service fee sc is included in each refund transaction.

[0098] For the payment channel used, the funding transaction Tc Example of a refund transaction and one of the T r,i are shown in Table 5 and Table 6, respectively. Transaction fees are not shown for simplicity.

[0099] [Table 5]

[0100] [Table 6]

[0101] Once the payment refund transaction is submitted by Ivan 303, Bob (Netflix) 103b receives the payment total (minus Ivan's service fee) from Alice 103a. Note that Ivan 303 simply passes the transaction to Bob 103b and has Bob 103b review the final transaction before submitting it to the blockchain 150 himself.

[0102] Similarly, Bob (Netflix) 103b does not necessarily have to wait until Ivan 303 submits a payment refund transaction before requesting to review the refund transaction signed by Alice. In the Netflix example, Bob 103b might request a copy of the most recent refund transaction signed by Alice for each quarter of the year, i.e., March, June, September, etc. These checkpoints allow Bob 103b to withdraw some funds if Ivan 303 does not submit a more recent iteration of the transaction that Alice returned. In this case, Bob 103b must balance the frequency of checkpoints between the risk of losing funds and the inconvenience of frequent check-ins.

[0103] 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 intermediary party 303. For convenience, each first party 301 will be referred to as Alice 103a, the second party as Bob 103b, and the intermediary party as Ivan 303. In the many-to-one case, there are multiple Alices who are to make intermittent payments to Bob 103b for services or goods, i.e., {Alice j j∈[1,n]} (e.g., multiple subscribers need to make monthly payments to Netflix).

[0104] This is for each subscriber Alice j , which would have been previously performed via each individual's respective payment channel between Alice and Bob (e.g., Netflix).

[0105] However, with PCA, an intermediary, Ivan 303, is used to manage these payments. This intermediary 303 accepts recurring payments for each channel, and then finally, a payment transaction is submitted to the blockchain 150. The aggregate value of these n payment transactions is then pay-forwarded by Ivan 303 to Bob 103b.

[0106] If Ivan 303 cannot be trusted, Ivan's responsibility is to j → Bob collects off-chain transactions for the set of payment channels, and then submits each payment channel's payment transaction to the blockchain 150. This works for each Alice, just as it works for one-to-one transactions as described in the section above. j It operates on.

[0107] For the payment channel used, the funding transaction T c Example of a refund transaction

[0108]

number

[0109] are shown in Table 7 and Table 8, respectively.

[0110] [Table 7]

[0111] Note that Bob 103b is paid in the refund transaction and Ivan 303 gets his service charge fee (see Table 8).

[0112] [Table 8]

[0113] 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 intermediary party 303. For convenience, the second party 302 will be referred to as Alice 103a, each first party as an instance of Bob 103b, and the intermediary party as Ivan 303. In the one-to-many case, there can be multiple Bobs, i.e., {Bob k Assume there are |k∈[1,m]} and one person, Alice. An example of this would be an individual who subscribes to multiple services. Consider Alice 103a, who subscribes to subscription services such as Netflix, Amazon Prime, and Disney+. Rather than transacting with multiple service providers herself, Alice 103a pays a lump sum amount to an intermediary, namely Ivan 303, who then handles payments to each provider.

[0114] Using PCA techniques for the above scenario, an intermediary, namely Ivan 303, is also used to manage these payments.

[0115] If Ivan 303 cannot be trusted, and Alice 103a pays Ivan 303 a service fee sc in advance, Ivan 303 behaves maliciously and responds to Bob k There is a risk that one, many, or all of the intermediate payment channels that make payments to the other party may not submit their payment transactions.

[0116] To mitigate this risk, a payment channel is established between Alice 103a and Bob 103b, and Ivan 303 is granted the right to make off-chain transactions.

[0117]

number

[0118] For each Bob k Alice 103a is responsible for sending the repayment transaction signed by Ivan 303 to Bob 303, either beforehand or at various times during the existence of the payment channel. k Communicate with Ivan 303 about whether to stop giving them to him.

[0119] Alice 103a then asks Bob k If Ivan 303 is not trustworthy, Alice 103a simply signs all possible iterations for the refund transaction for each of the k payment channels to Bob. k Return transaction iterations that are willing to pay

[0120]

number

[0121] (For example, you can pre-sign a refund transaction for up to 6 months for Netflix (Bob1), or you can pre-sign a refund transaction for the first 8 months of Amazon Prime (Bob2), etc.)

[0122] Service fee

[0123]

number

[0124] But the off-chain transaction k This service fee may be included in a refund transaction that pays Ivan 303 for the service of communicating with the

[0125]

number

[0126] The relatively high repetition rate of Bob k Since Alice 103a has a relatively large reward to submit, she only needs to pre-sign repeated payout transactions up to the level she is willing to pay.

[0127] Bob k The payment channel used to pay for the funding transaction

[0128]

number

[0129] Example of a refund transaction

[0130]

number

[0131] are shown in Table 9 and Table 10, respectively.

[0132] [Table 9]

[0133] Note that Ivan 303 gets his service charge fee in the refund transaction, see Table 10.

[0134] [Table 10]

[0135] 8. Further observations Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those of ordinary skill in the art. The scope of the present disclosure is limited only by the appended claims, and not by the described embodiments.

[0136] For example, some embodiments above are described with reference 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 specific example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain in any way. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with reference 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 properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

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

[0138] 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, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0139] 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, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0140] Some embodiments have been described with respect to blockchain networks that implement a proof-of-work agreement mechanism to secure the underlying blockchain. However, proof-of-work is just one type of agreement mechanism, and in general, embodiments may use any type of appropriate agreement mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-age. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The selected node is often called a validator. Blockchain nodes can lock up their tokens for a certain amount of time in order to have the opportunity to become a validator. In general, the node that locks up the greatest stake for the longest period of time has the best opportunity to become the next validator.

[0141] It will be appreciated that the above embodiments have been described for illustrative purposes only. More generally, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0142] STATEMENT 1. A computer-implemented method for facilitating respective payments between one or more respective first parties and second parties, wherein each respective first party and second party is configured to create a respective payment channel by generating a respective channel opening transaction including a respective input signed by the respective first party and a respective output locked to a respective public key of the respective first party and a public key of the second party, the respective outputs locking a respective maximum value, the method being performed by an intermediary party and comprising: obtaining one or more respective channel closure transaction templates from the second party, each respective channel closure transaction template including a respective input referencing a respective output of a respective channel opening transaction and including a respective signature of the second party, and a respective first output locked to a respective public key of a respective first party and a respective second output locked to a public key of the second 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; obtaining one or more respective channel closure transactions, each respective channel closure transaction being generated by including a respective signature of a respective first party in a respective input of a respective channel closure transaction template; sending a selected one of the one or more respective channel closure transactions to a blockchain network or sending each selected channel closure transaction to a second party; A method comprising:

[0143] Statement 2. The method of statement 1, wherein the one or more respective first parties includes a plurality of respective first parties.

[0144] Statement 3. The method of statement 1 or statement 2, wherein each second-party signature included by each input of each channel closure transaction signs each output of the respective channel closure transaction.

[0145] Statement 4. A computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and second party is configured to create a respective payment channel by generating a respective channel opening transaction including a respective input signed by the second party and a respective output locked to a respective public key of the respective first party and a public key of the second party, the respective outputs locking a respective maximum value, the method being performed by an intermediary party and comprising: obtaining one or more respective channel closure transaction templates from the second party, each respective channel closure transaction template including a respective input referencing a respective output of a respective channel opening transaction and including a respective signature of the second party, and a respective first output locked to a respective public key of a respective first party and a respective second output locked to a public key of the second 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; sending a selected one of the one or more respective channel closure transaction templates to each first party; A method comprising:

[0146] Statement 5. The method of any of statements 1 to 4, wherein each respective channel closure transaction template includes a respective third output locked to the intermediary party's public key, wherein the respective third output locks a service fee price, wherein a respective first amount of the respective maximum value is equal to the respective maximum value minus the respective maximum third amount minus the service fee price, and wherein a respective second amount of the respective maximum value is equal to the respective maximum value plus the service fee price.

[0147] Statement 6. The method of any of statements 1 to 5, wherein, for each respective first party, the selected respective channel closure transaction is the respective channel closure transaction having the highest respective maximum respective second amount locked by the second output of the respective channel closure transaction.

[0148] Statement 7. The method of any of statements 1 through 6, wherein each channel opening transaction and / or each channel closing transaction includes metadata about the respective payment.

[0149] Statement 8. The Second Party provides the respective goods and / or respective services to the respective First Party in exchange for the respective payment, as described in Statement 1 or any statement subordinate to Statement 1.

[0150] Statement 9. Each respective First Party provides respective goods and / or respective services to a Second Party in exchange for respective payments, as set forth in Statement 4 or any statement subordinate to Statement 4.

[0151] Statement 10. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 10. A computing device comprising: a memory storing code configured to be executed on a processor, the code configured, when on the processor, to perform a method according to any one of statements 1 to 9.

[0152] Statement 11. A computer program embodied on a computer-readable storage, the computer program being configured, when executed on one or more processors, to perform the method of any of statements 1 to 9.

[0153] According to another aspect disclosed herein, a method may be provided that includes action between an intermediary party and one or both of i) one or more first parties and ii) a second party.

[0154] According to another aspect disclosed herein, a system may be provided that includes computer equipment of an intermediary party and one or both of i) one or more first parties and ii) a second party. [Explanation of symbols]

[0155] 101 Packet Switched Network 102 Computer terminals and equipment 104 Blockchain Node, Node, Bitcoin Node 105 Client Applications, Software, Clients 106 Peer-to-peer (P2P) networks, blockchain networks, networks 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151 blocks 152 transactions 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools 155 Block Pointer 300 System 400 System 500 Systems

Claims

1. 1. A computer-implemented method for facilitating respective payments between one or more respective first parties and second parties, wherein each respective first party and the second party are configured to create a respective payment channel by generating a respective channel opening transaction including a respective input signed by the respective first party and a respective output locked to a respective public key of the respective first party and a public key of the second party, the respective outputs locking a respective maximum value; the method being performed by an intermediary party and comprising: obtaining one or more respective channel closure transaction templates from the second party, each respective channel closure transaction template including a respective input referencing the respective output of the respective channel opening transaction and including a respective signature of the second party, and a respective first output locked to a respective public key of the respective first party and a respective second output locked to a public key of the second party, wherein the respective first outputs lock a respective first amount of the respective maximum values ​​and the respective second outputs lock a respective second amount of the respective maximum values; obtaining one or more respective channel closure transactions, each respective channel closure transaction being generated by including a respective signature of the respective first party in the respective input of a respective channel closure transaction template; sending a selected one of the one or more respective channel closure transactions to a blockchain network or sending the selected respective channel closure transaction to the second party; A method comprising:

2. The method of claim 1 , wherein the one or more respective first parties comprises a plurality of respective first parties.

3. 3. The method of claim 1 or claim 2, wherein the respective signatures of the second parties included with the respective inputs of the respective channel closure transactions sign each output of the respective channel closure transactions.

4. 1. A computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and the second party are configured to create a respective payment channel by generating a respective channel opening transaction including a respective input signed by the second party and a respective output locked to a respective public key of the respective first party and a public key of the second party, the respective outputs locking a respective maximum value; the method being performed by an intermediary party and comprising: obtaining one or more respective channel closure transaction templates from the second party, each respective channel closure transaction template including a respective input referencing the respective output of the respective channel opening transaction and including a respective signature of the second party, and a respective first output locked to a respective public key of the respective first party and a respective second output locked to a public key of the second party, wherein the respective first outputs lock a respective first amount of the respective maximum values ​​and the respective second outputs lock a respective second amount of the respective maximum values; sending a selected one of the one or more respective channel closure transaction templates to the respective first party; A method comprising:

5. 5. The method of claim 1, wherein each respective channel closure transaction template includes a respective third output locked to the intermediary party's public key, the respective third output locking a service charge price, the respective first amount of the respective maximum value equals the respective maximum value minus the respective maximum third amount minus the service charge price, and the respective second amount of the respective maximum value equals the respective maximum value plus the service charge price.

6. 6. The method of claim 1, wherein for each respective first party, the selected respective channel closure transaction is the respective channel closure transaction having the highest respective second amount of the respective maximum value locked by the second output of the respective channel closure transaction.

7. The method of claim 1 , wherein the respective channel opening transaction and / or the respective channel closing transaction includes metadata about the respective payment.

8. 10. The method of claim 1 or any one of claims dependent on claim 1, wherein the second party provides the respective goods and / or services to the respective first party in exchange for the respective payment.

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

10. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 10. A computing device comprising: a memory for storing code configured to be executed on the processing unit, the code being configured, when present on the processing unit, to perform the method of any one of claims 1 to 9.

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

Images