CN120266146A

CN120266146A - Payment channel aggregator

Info

Publication number: CN120266146A
Application number: CN202380081343.2A
Authority: CN
Inventors: 丹尼尔·约瑟夫; 克雷格·史蒂文·赖特
Original assignee: Blockchain Licensing Jsc
Current assignee: Blockchain Licensing Jsc
Priority date: 2022-11-23
Filing date: 2023-10-30
Publication date: 2025-07-04
Also published as: WO2024110153A1; GB2624641A; EP4623399A1; GB202217486D0

Abstract

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

Description

Payment channel aggregator

Technical Field

The present disclosure relates to a method of facilitating a plurality of respective payments between a plurality of respective first and second parties.

Background

Blockchains refer to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter "blockchain network"), and is widely disclosed. The blockchain includes a series of blocks of data, where each block includes one or more transactions (transactions). Except for so-called "coinbase transactions," each transaction points to a previous transaction in a sequence that may span one or more chunks, returning to one or more coinbase transactions. coinbase transactions are discussed further below. Transactions committed to the blockchain network are included in the new chunk. The creation of a new chunk is often referred to as "mining," which involves each of a plurality of nodes competing to perform "proof of work," i.e., solving an encryption challenge based on a representation of a defined ordered and verified valid pending transaction waiting to be included in the new chunk of the blockchain. It should be noted that the blockchain may be pruned (prune) at some nodes and that the publishing of the blocks may be accomplished by publishing only the block header.

Transactions in the blockchain may be used for one or more of transmitting digital assets (i.e., a number of digital token tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing time stamp entries, and/or time ordering index pointers. The blockchain may also be utilized to implement hierarchical additional functionality on the blockchain. For example, the blockchain protocol may allow additional user data or data indexes to be stored in the transaction. The maximum data capacity that can be stored in a single transaction is not limited by pre-specified limits and can therefore be incorporated into more and more complex data. This may be used, for example, to store electronic documents, audio or video data in a blockchain.

Nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and validation process, which will be described in more detail below. In summary, in the process, the node verifies transactions and inserts the transactions into the tile template, which attempt to identify a valid proof-of-work solution for the tile template. Once a valid solution is found, the new chunk is propagated to other nodes of the network, enabling each node to record the new chunk on the blockchain. To record a transaction in the blockchain, a user (e.g., a blockchain client application) transmits the transaction to one of the nodes in the network for propagation. The node receiving the transaction may contend to find a proof of work solution that incorporates the transaction that verified valid into the new block. Each node is configured to execute the same node protocol that will include one or more conditions for validating the transaction. Invalid transactions will not propagate or be incorporated into the block. Assuming that the transaction has verified valid and is thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an unalterable public record on each node in the blockchain network.

Nodes that successfully solve a proof of work puzzle that can create the latest chunk are typically rewarded with a new transaction called a "coinbase transaction" that distributes digital asset amounts, i.e., number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes that act as proxies for the network and report and prevent fraud by incentives. The widespread distribution of information allows users to continuously audit the performance of nodes. Issuing only the block header allows the participant to ensure that the blockchain has persistent integrity.

In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any expendable output includes an element specifying a digital asset amount, which may be derived from an ongoing sequence of transactions. The spent output is sometimes referred to as UTXO ("spent transaction output"). The output may also include a locking script that specifies a future redemption condition for the output. A lock script is a predicate defining conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (other than coinbase transactions) includes a pointer (i.e., a reference) to such output in the previous transaction, and may also include an unlock script for unlocking the lock script to the output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output specifying a digital asset amount and includes a locking script defining one or more conditions for unlocking the output. The second (target) transaction includes at least one input including a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

In such a model, when a second (target) transaction is sent to the blockchain network to propagate and record in the blockchain, one of the validity conditions applied at each node will be that the unlock script satisfies all of the one or more conditions defined in the lock script of the first transaction. Another condition would be that the output of the first transaction has not yet been redeemed by another early valid transaction. Any node that finds that the target transaction is invalid based on any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction) nor include the transaction in a new chunk to be recorded in the blockchain.

Another transaction model is an account-based model. In this case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored by the node alone into the blockchain and is continuously updated.

Disclosure of Invention

In a blockchain environment, a payment channel is a collection of transactions between two parties (where each transaction represents at least one payment) and a corresponding protocol for signing and submitting transactions that allows a set of valid and secure payments to be made between the two parties without submitting the entire collection of transactions to the blockchain. In the transaction set of the payment channel, only two transactions are committed to the blockchain, regardless of the number of transactions created. One of these committed transactions represents the payment that is ultimately agreed upon at the end of the iterative negotiation, or may be the sum of a set of periodic payments.

For the latter, an example of a one-year subscription (e.g., netflix, etc. streaming media platform) that includes twelve-month monthly payments may be considered. Each month, the client provides an effective and secure copy of the transaction to the streaming platform. The streaming platform may submit the transaction to the blockchain if desired. Each month's transaction contains a payment that is the accumulation of the amount owed in the current month and the previous months. However, the streaming platform only commits the final transaction to the blockchain. The transaction contains a cumulative payment of twelve months in length.

Typically, it is contemplated that the payment channel is established between both parties, i.e., the payer (e.g., alice) and the intended recipient of the payment (e.g., bob), where Bob will be the goods/service provider. However, as recognized herein, in some cases, an intermediary party may be required.

According to one aspect disclosed herein, there is provided a computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and the second party are configured to create a respective payment channel by generating a respective channel opening transaction comprising 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, wherein the respective output locks a respective maximum value, wherein the method is performed by an intermediary party, and the method comprises, for each respective first party:

Obtaining one or more respective channel closing transaction templates from the second party, wherein each respective channel closing transaction template comprises a respective input referencing the respective output of the respective channel opening transaction and comprising 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 output locks a respective first amount of the respective maximum value, and wherein the respective second output locks a respective second amount of the respective maximum value, and

And sending selected ones of the one or more respective channel-closing transaction templates to the respective first party.

In this aspect, the intermediary party is used to facilitate payment between one or more payers and the recipient. A payment channel is initially established between each payer and recipient. However, the payment channel is not performed by the one or more payers and the recipient, but the burden on each party is relieved by the intermediary party. The intermediary receives channel closing transactions (i.e., refund transactions or settlement transactions) from the parties and closes each individual payment channel using one of the closing transactions (e.g., a transaction that transfers a maximum amount to the recipient).

For example, the streaming platform may outsource its subscription fee collection to a third party collection authority. The institution charges a transaction that transfers the subscription fee to the platform and submits the transaction to the blockchain, e.g., after an agreed amount of payment, after an agreed amount of time, in response to a request by the payer, etc. This process is more efficient at each iteration of the payment channel (e.g., each round of payment) than each user has to interact with the streaming platform individually.

According to another aspect disclosed herein, there is provided a computer-implemented method for facilitating a plurality of respective payments between a plurality of respective first parties and a second party, wherein each respective first party and the second party are configured to create a respective payment channel by generating a respective channel-opening transaction comprising 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, wherein the respective output locks a respective maximum value, wherein the method is performed by an intermediary party, and the method comprises, for each respective first party:

In this aspect, the intermediary party is used to facilitate payment between the payer and the plurality of recipients. A payment channel is initially established between the payer and each recipient. However, the payment channel is not performed by the payer and the recipient, but the intermediary receives a channel closing transaction (i.e., a refund transaction or a settlement transaction) from the payer and sends the channel closing transaction to the recipient for submission to the blockchain, e.g., after signing the channel closing transaction.

In this case, a party (e.g., alice) may subscribe to multiple services (e.g., bob's multiple instances), in which case it may be more convenient (and efficient) for the intermediary to collect these payments on his/her behalf.

Drawings

To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings in which:

FIG. 1 is a schematic block diagram of a system for implementing a blockchain;

FIG. 2 schematically illustrates some examples of transactions that may be recorded in a blockchain;

FIG. 3 illustrates an example of a one-to-one payment channel;

FIG. 4 illustrates an example of a many-to-one payment channel;

Fig. 5 shows an example of a one-to-many payment channel.

Detailed Description

1. Exemplary System overview

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

Each blockchain node 104 includes a peer's computer device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, such as one or more Central Processing Units (CPUs), accelerator processors, special purpose processors, and/or Field Programmable Gate Arrays (FPGAs), among other devices, such as Application Specific Integrated Circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as Solid State Disks (SSDs), flash memory or electrically erasable programmable read-only memory (EEPROMs), and/or optical media such as optical drives.

The blockchain 150 includes a series of data blocks 151 with a respective copy of the blockchain 150 maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean completely storing the blockchain 150. Instead, the blockchain 150 may perform data pruning as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In one common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing a digital asset as an amount of property, an example of which is the output being cryptographically locked to the user 103 (requiring the user's signature or other solution to be unlocked for redemption or spending). Each input points to the output of a previous transaction 152, linking the transactions.

Each block 151 also includes a block pointer 155 that points to previously created blocks 151 in the blockchain to define the order of the blocks 151. Each transaction 152 (in addition to coinbase transactions) includes a pointer to the previous transaction to define the order of the sequence of transactions (note: the sequence of transactions 152 may branch). The blockchain of the blockchain 151 dates back to the start block (Gb) 153, which is the first blockin the blockchain. Early one or more original transactions 152 in the blockchain 150 point to the start block 153 instead of the previous transaction.

Each blockchain node 104 is configured to forward the transaction 152 to other blockchain nodes 104 such that the transaction 152 propagates throughout the network 106. Each blockchain node 104 is configured to create a block 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into the block 151. Ordered pool 154 is commonly referred to as a "memory pool". In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to an ordered set of transactions that node 104 has accepted as valid, and for which node 104 is forced to not accept any other transactions that attempt to expend the same output.

In a given current transaction 152j, the input (or each input) includes a pointer that references the output of the previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152 j. Spending or redemption does not necessarily mean transferring the financial asset, although this is certainly a common application. More generally, costs may be described as consuming an output or being assigned to one or more outputs in another subsequent transaction. In general, the previous transaction may be any transaction in ordered set 154 or any block 151. Although in order to ensure that the current transaction is valid, there will be a need to have the previous transaction 152i and verify that it is valid, there is no need to have the previous transaction 152i when creating the current transaction 152j and even sending the current transaction 152j to the network 106. Thus, in this context, "prior" refers to predecessors in the logical sequence linked by pointers, not necessarily creation times or transmission times in the time sequence, and thus the case of out-of-order creation or transmission transactions 152i, 152j is not necessarily precluded (see discussion below regarding isolated transactions). The previous transaction 152i may also be referred to as a look-ahead transaction or a look-ahead transaction.

The input of the current transaction 152j also includes an input authorization, such as a signature of the user 103a to which the output of the previous transaction 152i was locked. In turn, the output of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may 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 152 j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users or entities (one of which may be original user or entity 103a for alteration). In some cases, a transaction may also have multiple inputs, summarizing the amounts in multiple outputs of one or more previous transactions, and reassigning to one or more outputs of the current transaction.

According to an output-based transaction protocol, such as bitcoin, when a party 103, such as an individual user or organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuer sends the new transaction from its computer terminal 102 to the recipient. The issuer or recipient will eventually send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle other user terminals are possible as well). It is also not precluded that the party 103 issuing the new transaction 152j may send the transaction directly to one or more blockchain nodes 104, and in some examples, may not send the transaction to the recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain point protocol applied at each blockchain node 104. The blockchain point protocol typically requires the blockchain node 104 to check whether the encrypted signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of previous transaction 152i that the new transaction spends (or "allocates"), where the condition typically includes checking at least whether the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of previous transaction 152i to which the input of new transaction is linked. The condition may be defined, at least in part, by a script included in the output of the previous transaction 152i. Or this may be determined solely by the block link point protocol, or may be determined by a combination thereof. Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain point protocol and thus forward the new transaction 152j to one or more other nodes 104, and so on. In this way, new transactions propagate throughout the network of blockchain nodes 104.

In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it is effectively redeemed by the input of another subsequent transaction 152j according to the blockchain point protocol. Another condition that the transaction is valid is that the output of its previous transaction 152i attempting to be redeemed has not yet been redeemed by another transaction. Also, if invalid, the transaction 152j will not propagate (unless marked invalid and propagated for reminder) or record in the blockchain 150. This prevents the duplication of costs, i.e. the transaction processor's output allocation to the same transaction more than once. On the other hand, account-based models prevent recurring costs by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at any time.

In addition to verifying that a transaction is valid, blockchain node 104 also contends to be the first node to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work". At the blockchain node 104, the new transaction is added to an ordered pool 154 of valid transactions that have not yet occurred in the blocks 151 recorded on the blockchain 150. The blockchain node then contends to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve the encryption challenge. Typically, this involves searching for a "random number" value such that when the random number is juxtaposed with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has some predefined number of leading zeros. Note that this is just one particular type of proof of work challenge and does not exclude other types. The hash function is characterized by having an unpredictable output relative to its input. Thus, the search can only be performed with brute force, consuming a significant amount of processing resources at each blockchain node 104 that is attempting to solve the puzzle.

The first blockchain node 104 to solve the problem declares the problem solution on the network 106, providing the solution as proof, and then other blockchain nodes 104 in the network can easily check the solution (once a solution for a hash value is given, can directly check if the solution has the output of the hash value meet the condition). The first blockchain node 104 propagates a block to other nodes that accept the block to achieve a threshold consensus, thereby enforcing the protocol rules. Ordered transaction set 154 is then recorded by each blockchain node 104 as a new chunk 151 in blockchain 150. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the blockchain. The significant amount of work (e.g., in the form of a hash) required to create the proof of work solution signals the intent of the first node 104 to follow the blockchain protocol. These rules include accepting no transaction as valid if it costs or allocates the same output as a transaction previously verified to be valid, otherwise referred to as a repeat cost. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointer 155 also applies an order to the block 151. Since the transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an unchangeable common ledger for transactions is provided.

It should be noted that different block chain nodes 104 that contend to solve a puzzle at any given time may do so based on different snapshots of pool 154 of transactions that have not yet been issued at any given time, depending on the order in which they begin searching for or receiving transactions. The person who solves the corresponding puzzle first defines the transactions 152 and their order included in the new block 151n and updates the current unpublished transaction pool 154. The blockchain node 104 then proceeds to contend to create a block from the newly defined unpublished transaction ordered pool 154, and so on. In addition, there are protocols that address any "bifurcation" that may occur, where two blockchain nodes 104 solve a problem within a short time of each other, propagating conflicting views of the blockchain between nodes 104. Briefly, the bifurcation direction is longest and becomes the final blockchain 150. It should be noted that this does not affect the users or agents of the network, as the same transaction will occur in both forks.

Based on the bitcoin blockchain (and most other blockchains), the node that successfully constructs the new block 104 is granted the ability to newly allocate additional, accepted amounts of digital assets in a new special type of transaction that allocates an additional defined amount of digital assets (as opposed to inter-agent or inter-user transactions that transfer a certain amount of digital assets from one agent or user to another). This particular type of transaction is commonly referred to as a "coinbase transaction," but may also be referred to as a "start transaction" or a "produce transaction. It typically forms the first transaction for the new block 151 n. The proof of work signals the intent of the node constructing the new block to follow the protocol rules, allowing the particular transaction to be redeemed at a later time. The blockchain protocol rules may require a maturity period, for example 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction cost in one of its outputs to further reward blockchain nodes 104 that create the block 151n in which the transaction was issued. This cost is commonly referred to as the "transaction cost" and is discussed below.

Because of the resources involved in transaction verification and distribution, typically at least each blockchain node 104 takes the form of a server including one or more physical server units, or even an entire data center. In principle, however, any given blockchain node 104 may take the form of one user terminal or a group of user terminals networked together.

The memory of each blockchain node 104 stores software configured to run on the processing devices of the blockchain nodes 104 to perform their respective roles and process the transactions 152 in accordance with the blockchain point protocol. It should be appreciated that any actions attributed herein to blockchain node 104 may be performed by software running on the processing means of the respective computer device. The node software may be implemented in an application layer or in one or more applications at a lower layer, such as an operating system layer or a protocol layer, or any combination of these layers.

Computer devices 102 of each of the parties 103 playing the role of a consuming user are also connected to the network 101. These users may interact with the blockchain network 106 but not participate in verifying transactions or constructing blocks. Some of the users or agents 103 may act as senders and receivers in transactions. Other users may interact with blockchain 150 without having to act as a sender or receiver. For example, some parties may act as storage entities that store copies of blockchain 150 (e.g., have obtained copies of blockchains from blockchain nodes 104).

Some or all of the parties 103 may connect as part of a different network, such as a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, however, these users are not blockchain nodes 104 because they do not perform the roles that are required by the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 to utilize the blockchain 150 by connecting to the blockchain node 106 (i.e., communicating with the blockchain node 106). For illustration purposes, both parties 103 and their respective devices 102, a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b are shown. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but are not illustrated for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as alice and the second party 103b is referred to as bob, but it should be understood that this is not limited to alice or bob, and any references herein to alice or bob may be replaced with "first party" and "second party", respectively.

The computer device 102 of each party 103 includes a respective processing means comprising one or more processors, such as one or more CPUs, graphics Processing Units (GPUs), other accelerator processors, application-specific processors, and/or FPGAs. The computer device 102 of each party 103 also includes memory, i.e., computer readable memory in the form of a non-transitory computer readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and/or optical media such as optical drives. Memory on the computer device 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to run on a processing means. It should be understood that any actions attributed herein to a given party 103 may be performed by software running on the processing means of the corresponding computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, for example a desktop or laptop computer, a tablet computer, a smart phone or a wearable device such as a smart watch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

Client application 105 may initially be provided to computer device 102 of any given party 103 by, for example, an appropriate computer readable storage medium downloaded from a server, or by a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a floppy disk or magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

Client application 105 includes at least a "wallet" function. This has two main functions. One of which is to enable the corresponding party 103 to create, authorize (e.g., sign) and send a transaction 152 to one or more bitcoin nodes 104 and then propagate through the network of blockchain nodes 104 for inclusion in the blockchain 150. Another function is to report to the corresponding party the amount of digital asset it currently owns. In an output-based system, this second function includes sorting out the amounts defined in the output of the various transactions 152 that are dispersed in the blockchain 150 that belong to the interested party.

Note that while various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead any of the client functions described herein may be implemented in a suite of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More colloquially, client functionality may be implemented at the application layer or at a lower layer such as the operating system or any combination of these layers. The description will be described below in terms of client application 105, but it should be understood that this is not limiting.

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

When a given party 103 (say alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152 from client application 105 to the blockchain node or nodes 104 to which she is connected. For example, this may be the blockchain node 104 that best connects with alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it will process according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j satisfies a particular condition to become "valid", a specific example of which will be discussed in detail later. In some transaction protocols, validity conditions may be configured on a per transaction basis by scripts contained in the transaction 152. Or the condition may be merely a built-in function of the node protocol or defined by combining a script and the node protocol.

If the newly received transaction 152j passes the validity test (i.e., in the "valid" condition), any blockchain node 104 that receives the transaction 152j will add a new validation valid transaction 152 to the ordered set of transactions 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives transaction 152j will then verify that the valid transaction 152 propagates to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will propagate soon throughout the network 106.

Upon entering the pending ordered pool of transactions 154 maintained at a given blockchain node 104, that blockchain node 104 will begin to contend for solving a proof-of-job puzzle on the latest version of its respective pool 154 containing new transactions 152 (bearing in mind that other blockchain nodes 104 may attempt to solve the puzzle based on different transaction pools 154. But the person that first solved the puzzle will define the set of transactions included in the latest block 151. Eventually, blockchain node 104 will solve a portion of the puzzle of ordered pool 154, including alice's transaction 152 j). Once pool 154, including new transaction 152j, completes the proof of work, it will invariably become part of one of blocks 151 in blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of the transactions is also recorded unchanged.

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

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

2. UTXO-based model

Fig. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (simply "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The description will be made below by referring to an output-based or "UTXO" -based protocol. But this is not limited to all possible embodiments. It should be noted that while the exemplary UTXO-based protocol is described with reference to bitcoin, it may be implemented on other exemplary blockchain networks as well.

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

Say alice 103a wishes to create a transaction 152j that transfers the amount of the associated digital asset to bob 103 b. In fig. 2, alice's new transaction 152j is labeled "Tx ₁". The new transaction obtains the digital asset amount locked to alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to bob. In fig. 2, the previous transaction 152i is labeled "Tx ₀".Tx₀ and Tx ₁ are just arbitrary labels, which does not necessarily mean that Tx ₀ refers to the first transaction in the blockchain 151 and Tx ₁ refers to the subsequent transaction in the pool 154. Tx ₁ may point to any previous (i.e., look ahead) transaction that still has the spent output 203 locked to alice.

When alice creates her new transaction Tx ₁, or at least when she sends the new transaction to the network 106, the previous transaction Tx ₀ may already be valid and included in the block 151 of the blockchain 150. The transaction may already be included in one of the blocks 151 at this time, or may still wait in the ordered set 154, in which case the transaction will soon be included in the new block 151. Or Tx ₀ and Tx ₁ may be created and sent together to the network 106, or Tx ₀ may even be sent after Tx ₁ if the node protocol allows buffering "orphaned" transactions. The terms "prior" and "subsequent" as used herein in the context of a transaction sequence refer to the order of the transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may also be replaced with "predecessors" and "successors", "ancestors" and "offspring" or "parents" and "children", etc. This does not necessarily refer to the order in which it was created, sent to the network 106, or arrived at any given blockchain node 104. However, subsequent transactions (offspring transactions or "children") that point to a previous transaction (ancestor transaction or "parent") are not valid unless the parent is valid. Child parents that arrive at blockchain node 104 before parent are considered orphaned. Depending on the node protocols and/or node behavior, it may be discarded or buffered for a period of time to wait for the parent.

One of the one or more outputs 203 of the previous transaction Tx ₀ includes a particular UTXO, labeled UTXO ₀. Each UTXO includes a value specifying the digital asset amount represented by the UTXO and a locking script defining the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction to validate the subsequent transaction to successfully redeem the UTXO. Typically, a locking script locks an amount to a particular party (beneficiary of the transaction of that amount). That is, the locking script defines an unlocking condition that typically includes a condition that the unlocking script in the input of a subsequent transaction includes an encrypted signature of the party to which the previous transaction was locked.

A lock script (also known as scriptPubKey) is a piece of code written in a domain-specific language identified by a node protocol. A specific example of such a language is called "Script" (S uppercase), which may be used by blockchain networks. The lock script specifies information required to spend the transaction output 203, such as alice signed requirements. An unlock script appears in the output of the transaction. An unlock script (also known as SCRIPTSIG) is a piece of code written in a domain-specific language that provides the information required to meet the lock script standard. For example, it may contain bob's signature. An unlock script appears in the input 202 of the transaction.

Thus in the example shown, the UTXO ₀ in the output 203 of Tx ₀ includes a locking script CHECKSIG P _A that requires alice's signature Sig P _A to redeem the UTXO ₀ (strictly speaking, to validate subsequent transactions attempting to redeem the UTXO ₀). [ CHECKSIG P _A ] contains a representation (i.e., hash) of public key P _A of Alice's public-private key pair. The input 202 of Tx ₁ includes a pointer to Tx ₁ (e.g., by its transaction ID (TxID ₀), which in an embodiment is a hash of the entire transaction Tx ₀). The input 202 to Tx ₁ includes an index identifying UTXO ₀ in Tx ₀ to identify it among any other possible outputs to Tx ₀. The input 202 of Tx ₁ further includes an unlock script < Sig P _A >, which includes alice's encrypted signature created by applying alice's private key in its key pair to predetermined partial data (sometimes referred to as a "message" in cryptography). Data (or "messages") that alice needs to sign to provide a valid signature may be defined by a lock script, a node protocol, or a combination thereof.

When a new transaction Tx ₁ arrives at the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies a condition defined in the locking script (where the condition may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

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

Where "||" represents juxtaposition "<.>" represents placing data on a stack, "[.]" represents a function consisting of a locking script (in this example, a stack-based language). Also, rather than concatenating scripts, scripts may run one after another using a common stack. Either way, when run together, the script uses alice's public key P _A (included in the locked script of the output of Tx ₀) to authenticate whether the unlocked script in the input of Tx ₁ contains the signature when alice signed the data of the intended portion. It is also necessary to include the expected portion of the data itself ("message") in order to perform this authentication. In an embodiment, the signed data includes the entire Tx ₁ (and thus need not include a separate element to explicitly specify the signed portion of the data, as it already exists itself).

Those skilled in the art will be familiar with the details of authentication by public and private passwords. Basically, if alice has encrypted signed a message using his private key, then given alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by alice. Signing typically involves hashing the message, signing the hash value and signing this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Thus, it should be noted that in an embodiment, any reference herein to signing a particular data segment or transaction portion, etc., may mean signing the hash value of that data segment or transaction portion.

If the unlock script in Tx ₁ satisfies one or more conditions specified in the lock script of Tx ₀ (and thus, in the example shown, if Alice's signature is provided and authenticated in Tx ₁), then the blockchain node 104 considers Tx ₁ valid. This means that the blockchain node 104 will add Tx ₁ to the pending transaction ordered pool 154. The blockchain node 104 may also forward the transaction Tx ₁ to one or more other blockchain nodes 104 in the network 106 so that it may propagate throughout the network 106. Once Tx ₁ is valid and included in the blockchain 150, this will define UTXO ₀ as spent from Tx ₀. It should be noted that Tx ₁ is only active when it spends the unused transaction output 203. If it tries to spend the output that another transaction 152 has spent, tx ₁ will be inactive even if all other conditions are met. Thus, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx ₀ has already spent (i.e., whether it has already formed a valid input for another valid transaction). This is one of the reasons why it is important that the blockchain 150 impose a defined order on the transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXOs 203 of spent transactions 152, but ultimately defining whether a UTXO has spent depends on whether a valid input for another valid transaction is formed in the blockchain 150.

If the total number specified in all outputs 203 of a given transaction 152 is greater than the total number pointed to by all of its inputs 202, this is another basis for failure in most transaction models. Thus, such transactions are not propagated or included in block 151.

Note that in the UTXO-based transaction model, a given UTXO needs to be used as a whole. A portion of the amount defined as spent in the UTXO cannot be "left behind" while another portion is spent. The amount of UTXOs may be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXOs ₀ of Tx ₀ may be split among multiple UTXOs in Tx ₁. Thus, if alice does not want to give bob all the amounts defined in UTXO ₀, she can use the remainder to make his own change in the second output of Tx ₁ or pay the other party.

In practice alice typically also needs to include a fee for the bitcoin node 104, which bitcoin node 104 successfully contains alice's transaction 104 in block 151. If alice does not include such fees, tx ₀ may be rejected by blockchain node 104 and thus, while technically effective, may not propagate and be included in blockchain 150 (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept). In some protocols, the transaction cost does not require its own separate output 203 (i.e., a separate UTXO is not required). Instead, any difference between the total pointed to by the input 202 and the total pointed to by the output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that the pointer to UTXO ₀ is the only input to Tx ₁ and that Tx ₁ has only one output UTXO ₁. If the digital asset amount specified in UTXO ₀ is greater than the amount specified in UTXO ₁, the difference may be allocated (or spent) by node 104 that wins the proof of work contest to create a block containing UTXO ₁. Alternatively or additionally, this does not necessarily preclude that the transaction cost may be explicitly specified in one of the UTXOs 203 of its own transaction 152.

Alice and bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered throughout the UTXOs of the various transactions 152 of the blockchain 150. No location in blockchain 150 stores a number defining the total balance of a given party 103. The purpose of the wallet function of the client application 105 is to put together the various UTXO values that are locked to the respective party and that have not yet been spent in other subsequent transactions. To achieve this, it may query the copy of the blockchain 150 stored at any of the bitcoin nodes 104.

It should be noted that script code is typically represented schematically (i.e., in a non-precise language). For example, an operation code (opcode) may be used to represent a particular function. "op_," refers to a specific opcode of the scripting language. For example, op_return is a scripting language opcode that, when op_false is added before the opcode at the beginning of the locking script, creates an inexpensible output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include files that need to be stored in a blockchain.

Typically, the input of the transaction contains a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using an elliptic curve secp k 1. Digital signatures sign specific data segments. In an embodiment, for a given transaction, the signature will sign part of the transaction input as well as part or all of the transaction output. Signing a particular portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically 4-byte code contained at the end of the signature to select the output of the signature (and thus fixed at the time of signing).

The locking script is sometimes referred to as "scriptPubKey" meaning that it typically includes the public key of the party to which the corresponding transaction is locked. The unlock script is sometimes referred to as "SCRIPTSIG" meaning that it typically provides a corresponding signature. But more colloquially, the UTXO redemption conditions do not necessarily include verification of the signature in all applications of the blockchain 150. More colloquially, a scripting language may be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

3. Side channel

As shown in FIG. 1, the client application on each of the computer devices 102a, 120b of Alice and Bob may include additional communication functionality. This additional functionality may enable alice 103a to establish a separate side channel 107 with bob 103b (under the initiative of either party or a third party). The side channel 107 enables exchange of data off the blockchain network. Such communications are sometimes referred to as "under-chain" communications. For example, this may be used to exchange transaction 152 between alice and bob without registering the transaction (not yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it on the network 106. Sharing transactions in this manner is sometimes referred to as sharing a "transaction template (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, bargained amounts or terms, data content, etc.

The side channel 107 may be established through the same packet switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network, such as a mobile cellular network, or a local area network, such as a wireless local area network, or even via a direct wired or wireless link between alice and bob's devices 102a, 102 b. In general, the side channels 107 referred to anywhere herein may comprise any one or more links for "under-chain" exchange of data, i.e., exchange of data off of the blockchain network 106, via one or more networking technologies or communication mediums. Where multiple links are used, the bundle or set of links may be referred to as a side channel 107 as a whole. It should therefore be noted that if alice and bob are said to exchange some information or data etc. via the side channel 107, this does not necessarily mean that all of these data must be sent over exactly the same link or even the same type of network.

4. Payment channel

In a typical payment channel implementation, an almost unlimited number of payments may be made, but only two transactions need to be added to the blockchain 150. In addition to reducing the number of transactions added to the blockchain and reducing the associated cost, storage, and bandwidth usage, the payment channel provides speed advantages and enables payors to refund funds in the event that something is not planned or any party decides not to proceed with more than a certain set of payments. The payment channel implementation is outlined below.

It should be noted at first that,

"You can have multiple inputs for each bitcoin transaction. For each input, there is a parameter called a serial number. The number indicates whether the transaction including the input was finalized. If the parameter does not take the maximum value (0 xFFFFFFFF), the verification process will look at a lock time field (defined at the transaction level) that specifies the time the transaction was in effect, i.e., the transaction was invalidated before the lock time. This may be useful when the specified time is in the future. (at the time of writing this document, you can choose a lock time furthest to about 9,500 years into the future.) before the lock time of a given transaction expires, the new version of the transaction with the larger serial number can invalidate the earlier version that costs the same input but has the smaller serial number. "[ https:// nchain. Com/parent-channels-and-smart-compositions-on-bitcoin /)

Consider now the scenario in which alice 103a needs to pay bob 103b for a service fee, where this may require alice 103a to pay bob 103b multiple times over a period of time, as the case may be. Alice 103a expects to spend up to 15BSV (total) with bob 103b in the possible set of exchanges. To facilitate this, a payment channel is established between alice 103a and bob 103b, and operates as follows.

Alice creates a 2/2 multi-signed transaction T _c that commits 15BSV from alice 103 a. Multiple signature lock scripts require two people (alice and bob) to sign any transaction that spends the corresponding lock output. At this point, the transaction is not committed to the blockchain network 106.

TABLE 1 funds transaction T _c

Alice 103a creates a separate refund transaction T _r,0, refunds all funds in the "multiple signature control funds" to alice 103a. The transaction includesNLockTime values of (a). nLockTime is a blockchain transaction parameter that allows a blockchain transaction to be executable only after a specified time has elapsed. Bob 103a signs the blockchain transaction. If there is a problem with the exchange between alice 103a and bob 103b, after nLockTime has expired, the refund transaction allows alice 103a to obtain a refund.

TABLE 2 refund transaction T _r,0

Alice 103a signs the original transaction T _c. At this point alice 103a and bob 103b may continue to create new refund transactions to reflect the (in-chain) payments made from alice 103a to bob 103 b. These refund transactions will reflect the net amount alice 103a needs to pay bob 103b at that point in time. For example, if alice 103a were to pay 5BSV to bob 103b, a new refund transaction T _r,i is created that has an output that sends 5BSV to bob 103b and 10BSV back to alice 103 a. If alice 103a needs to pay for 5BSV to bob 103b again, a new refund transaction T _r,i+1 is created with an output that sends 10BSV to bob 103b and 5BSV to alice 103 a. For each new refund transaction, both parties sign the transaction, assuming the detailed information is agreed upon, but do not have to submit the transaction to network 106.

TABLE 3 refund transaction T _r,1

TABLE 4 refund transaction T _r,2

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

s_r,i+1<S_i,i

If a party refuses to sign any T _r,i, the victim can only commit T _r,i-1. In the worst scenario alice 103a signs T _r,0 and submits it to network 106 to withdraw all her funds (after expiration of nLockTime). The final refund transaction constructed represents the net amount of funds transferred from alice 103a to bob 103 b. The transaction is committed to the network 106. Refund transactions submitted to the blockchain network 106 are referred to herein as settlement transactions.

6. Facilitating blockchain payments

Embodiments of the present disclosure provide an intermediary party 303 for facilitating payment between one or more first parties 301 and a second party 302. In some embodiments, as shown in fig. 3 and 4, the first party 301 is considered a payer, and the second party 302 is considered a recipient. In other embodiments, as shown in fig. 5, the second party 302 is considered a payor and the plurality of first parties 301 are considered recipients.

Fig. 3 illustrates an exemplary system 300 in which an intermediary party 303 is used to facilitate payment between a first party 301 and a second party 302. The first party 301, the intermediary party 303, and the second party may be configured to perform any of the actions performed by alice 103a and/or bob 103b as described above with reference to fig. 1 and 2. In these embodiments, the second party 302 may provide the corresponding goods and/or services to the first party 301 in exchange for payment.

Fig. 4 illustrates an example system 400 in which an intermediary party 303 is used to facilitate payment between a plurality of first parties 301 and second parties 302. Each of the first party 301, the intermediary party 303, and the second party may be configured to perform any of the actions performed by alice 103a and/or bob 103b as described above with reference to fig. 1 and 2. In these embodiments, the second party 302 may provide each first party 301 with a corresponding good and/or service in exchange for payment.

Each first party (whether there is a single first party 301 or a plurality of first parties 301) establishes a respective payment channel with the second party. Each of the first party 301 and the second party 302 establishes a respective payment channel by generating a respective channel opening transaction. The channel open transaction may also be referred to as an initial transaction or a funds transaction (funding transaction). Each respective channel-opening transaction includes an input signed by a respective first party 301. That is, the input references the output of the last transaction, where the output is controlled by (i.e., locked to) the public key owned by the respective first party 301. Each respective channel-opening transaction includes an output (which may be, for example, a multiple signature output) that is locked to the public key of the respective first party 301 and the public key of the second party 302. Unless the context requires otherwise, each reference herein to a public key of a party may mean the same public key or a different public key owned by the party. The output of the corresponding channel-opening transaction locks to a corresponding maximum, i.e., the number (e.g., smart) of the underlying digital assets (underlying DIGITAL ASSET) of the blockchain 150.

The second party 302 sends one or more respective channel-closing transaction templates (templates) for each respective payment channel to the intermediate party 303, i.e. for each first party 301 with which the respective payment channel was established by generating a respective channel-opening transaction for the second party 302. The channel closing transaction template may also be referred to as a final transaction template or refund transaction template. For each payment channel, each respective channel-closing transaction template of the one or more respective channel-closing transaction templates includes a respective input referencing an output of a respective channel-opening transaction for opening the payment channel. The input is signed by the second party 302. In some examples, the signature of the second party may sign all of the outputs of the corresponding channel shutdown transaction template. Each respective payment channel closing transaction template of the one or more respective payment channel closing transaction templates comprises a respective output locked to the public key of the respective first party 301 and a respective output locked to the public key of the second party 302. The output lock locked to the public key of the first party 301 is a first amount of the respective maximum of the output lock of the transaction opened by the respective channel. Similarly, locking to the output lock of the public key of the second party 302 is by a second amount of the respective maximum of the output locks of the respective channel unlocking transactions. The sum of the first and second amounts is at most equal to the respective maximum value. As discussed below, the first amount and the second amount may be less than a maximum value. It should be noted that closing transaction templates is referred to as templates because they lack at least one data item, in this case the signature of the respective first party 301.

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

For each respective payment channel, the intermediary 303 selects a respective one of the respective channel shutdown transactions to shutdown the payment channel by causing the shutdown channel transaction to be committed to the blockchain network 106. The transaction for closing the payment channel is referred to as the final channel closing 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 highest amount of transactions with the public key locked to the second party 302.

The channel-open transaction and/or the channel-close transaction may include metadata related to payments associated with a particular payment channel, such as an identifier of the respective first party 301, an identifier of the second party 302, a payment reference, and the like.

In some examples, intermediary 303 may deduct a service fee for facilitating payment, examples of which are shown in tables 5 and 6 below (for scenarios where a single first party 301 is present), which show examples of channel-on transactions and channel-off transactions, respectively. Another example is shown in tables 7 and 8 below (for a scenario in which there are multiple first parties 301), which show examples of channel-on transactions and channel-off transactions, respectively.

Fig. 5 illustrates an exemplary system 500 in which intermediary 303 is used to facilitate payment between a plurality of first parties 301 and second parties 302. Each of the first party 301, the intermediary party 303, and the second party may be configured to perform any of the actions performed by alice 103a and/or bob 103b as described above with reference to fig. 1 and 2. The system 500 may include any number (n) of first parties 301. In these embodiments, each first party 301 may provide the corresponding goods and/or services to the second party 302 in exchange for payment.

Similar to the above-described embodiments, 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 the last transaction, where the output is controlled by (i.e., locked to) the public key owned by the second party 302. Each respective channel-opening transaction includes an output (which may be, for example, a multiple signature output) that is locked to the public key of the respective first party 301 and the public key of the second party 302. The output of the corresponding channel-opening transaction locks to a corresponding maximum, i.e., the number of underlying digital assets of blockchain 150 (e.g., smart).

The second party 302 sends one or more respective channel closing transaction templates for each respective payment channel to the intermediate party 303, i.e. for each first party 301 with which the second party 302 established the respective payment channel by generating a respective channel opening transaction. For each payment channel, each respective channel-closing transaction template of the one or more respective channel-closing transaction templates includes a respective input referencing an output of a respective channel-opening transaction for opening the payment channel. The input is signed by the second party 302. In some examples, the signature of the second party may sign all of the outputs of the corresponding channel shutdown transaction template. Each respective payment channel closing transaction template of the one or more respective payment channel closing transaction templates comprises a respective output locked to the public key of the respective first party 301 and a respective output locked to the public key of the second party 302. The output lock locked to the public key of the first party 301 is a first amount of the respective maximum of the output lock of the transaction opened by the respective channel. Similarly, locking to the output lock of the public key of the second party 302 is by a second amount of the respective maximum of the output locks of the respective channel unlocking transactions. The sum of the first and second amounts is at most equal to the respective maximum value. As discussed below, the first amount and the second amount may be less than a maximum value.

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

In some examples, intermediary 303 may deduct a service fee for facilitating payment, examples of which are shown in tables 9 and 10 below, which show examples of channel-on transactions and channel-off transactions, respectively.

7. Payment channel aggregator examples

This section describes an exemplary payment channel aggregator (PAYMENT CHANNEL aggregator, PCA) according to embodiments of the present disclosure, a system that facilitates joining an intermediary party (I-iswan) between two parties (a-alice and B-bob) who previously used the payment channel directly between themselves (alice and bob).

7.1 One-to-one

Fig. 3 illustrates an exemplary system 300 for facilitating payment between a first party 301 and a second party 302 using an intermediary party 303. For convenience, the first party 303 is referred to as alice 103a, the second party is referred to as bob 103b, and the intermediate party is referred to as Ivan (Ivan) 303. For one-to-one payments, assume that party alice 103a will pay bob 103b intermittently for a service or commodity. This was previously done through the payment channel between the two parties. However, in PCA of the scenario, payment from alice 103a to bob 103b is processed with an intermediary (iswan) 303.

If Ewan 303 is not trusted, then Ewan is responsible for collecting the under-chain transaction (signed by Alice 103 a) and then submitting the settlement transaction to blockchain 150. These under-chain transactions have been signed by bob 103 b. This may require bob 103b to know in advance the possible values of these in-chain payments. This may apply to the Netflix et al example, where monthly payments are a known amount, so the sum of the fees for multiple months is predictable.

PCA involves the following steps:

Islam 303, alice 103a and Bob 103b agree that Islam 303 will collect payments from Alice 103a (under-chain transactions that have been signed by Alice 103 a), and then Islam 303 submits the settlement transactions for these payments to blockchain 150 (e.g., before the expiration date).

Alice 103a and bob 103b create a payment channel between themselves. This includes creating a funds transaction that can refund the amount Max BSV to alice 103 a.

For each payment (refund transaction) alice 103a may make to bob 103b, bob 103b creates a transaction template that includes the appropriate details in the output, signs the transaction, and provides the set of pre-signed transactions to intermediate party iswan 303. Bob 103a signs the transaction with the sighash flag (SIGHASH _all| ANYONECANPAY) that signs ALL outputs of the transaction.

Additional (e.g., op_return) outputs may be included in each refund transaction that contain various metadata related to the transaction, such as Netflix subscription payment month, other customer and provider details.

The illite 303 cooperates with alice 103a, which signs the refund transaction every time an agreement is reached, e.g. if Netflix subscribes to 10BSV per month, alice 203a signs the refund transaction of 10i BSV at the end of month i. Alice 103a then sends the signed transaction to the iwany 303.

At the end of alice's payment (e.g., netflix annual subscription expires, or alice 103a refuses to sign other refund transactions with greater fee accumulation), the final refund transaction signed by alice (the transaction with the highest payment value) is submitted to blockchain 150 as a settlement transaction, and the payment channel is closed.

The intermediate Fang Yimo may be paid a service fee proportional to the accumulated fee received by bob 103 b. This serves as a payment and incentive for the illion to submit transactions and obtain higher cumulative settlement payments from alice 103 a. The service fee sc is included in each of the refund transactions.

Examples of one of the funds transaction T _c and refund transaction T _r,i are shown in tables 5 and 6, respectively, for the payment channels utilized. For simplicity, transaction costs are not depicted.

Table 5 fund transaction, PCA, one-to-one.

Table 6 refund transaction, PCA, one-to-one.

After the illite 303 commits the settlement refund transaction, bob (Netflix) 103v will receive the total payment from alice 103a (minus the service fee of illite). It should be noted that the Islam 303 may pass the transaction to Bob 103b and let Bob 103b review the final transaction before Bob 103b itself submits the transaction to blockchain 150.

Likewise, bob (Netflix) 103b may not have to wait until the refund transaction is committed by illion 303 to request a review of the refund transaction signed by alice. In the Netflix example, bob 103b may request a copy of the latest refund transaction signed by alice every quarter of the year (3 months, 6 months, 9 months, etc.). These checkpoints allow bob 103b to withdraw some funds if isn't able to submit update iterations of transactions returned by alice 303. In this case, bob 103b must balance the frequency of checkpoints with the risk of lost funds and the inconvenience of frequently checking in.

7.2 Many-to-one

Fig. 4 illustrates an example system 400 for facilitating payment between a plurality of first parties 301a, 301b. For convenience, each first party 303 is referred to as alice 103a, the second party as bob 103b, and the intermediate party as iswan 303. For many-to-one, assume that there are multiple Alice _j j e 1, n will pay bob 103b intermittently for a service or commodity. (e.g., multiple subscribers need to pay monthly to Netflix).

This was previously performed for each subscriber Alice _j through a separate respective payment channel (e.g., netflix) between each Alice and bob.

However, using PCA, these payments are managed with the intermediary party isn 303. The intermediary 303 will accept the iterative payment for each channel, and then the settlement transaction is eventually committed to the blockchain 150. The aggregate value of the n settlement transactions is then forwarded by the illite 303 to bob 103b.

If Ewan 303 is not trusted, ewan is responsible for collecting the under-chain transactions for a set of Alice _j - > Bob payment channels, and then submitting the settlement transactions for each payment channel to blockchain 150. This operates in the same manner for each Alice _j as the one-to-one operation described in the previous section.

For the payment channels utilized, funds transaction T _c and refund transactionExamples of one refund transaction are shown in tables 7 and 8, respectively.

Table 7 fund transaction, PCA, many-to-one.

It should be noted that bob 103b gets paid in the refund transaction while the isn 303 gets his service fee (see table 8).

Table 8 refund transaction, PCA, many-to-one.

7.3 One-to-many

Fig. 5 illustrates an example system 500 for facilitating payment between a second party 302 and a plurality of first parties 301a, 301b. For convenience, the second party 302 is referred to as alice 103a, each first party is referred to as an instance of bob 103b, and the intermediate party is referred to as iswan 303. For one-to-many, it is assumed that there are multiple Bob { Bob _k |k e [1, m ] } and one alice. One example is a person subscribing to multiple services. Alice 103a subscribed to a subscription service such as Netflix, amazon Prime, disney+ is considered. Alice 103a does not physically make a transaction with multiple service providers, but instead pays once to intermediate Fang Yimo, which then processes the payment to each provider.

These payments are managed again with the intermediary party isn 303 using PCA technology in the scenario.

If illite 303 is not trusted, then there is a risk that if alice 103a pays service charge sc to illite 303 in advance, then illite 303 takes malicious action and never commits one, more or all of the settlement transactions between the payment channels paid to the corresponding Bob _k.

To mitigate this risk, a payment channel is established between alice 103a and Bob 103b, with iswan 303 responsible for sending out the in-chain transactions to each Bob _k Is used to perform the appropriate iteration of (a). Alice 103a communicates with the iswan 303 at various times in advance or before the payment channel exists, as to when the iswan 303 should cease communicating refund transactions signed by alice to Bob _k.

Alice 103a then signs all possible iterations of the refund transaction for each of the k payment channels to Bob _k. Since illite 303 is not trusted, alice 103a can only iterate over return transactions that do not exceed her (alice) wish to pay Bob _k And signing. (e.g., sign refund transactions of Netflix (Bob ₁) for up to 6 months in advance, sign transactions of Amazon Prime (Bob ₂) for up to 8 months in advance, etc.)

The refund transaction may include a service feeThe service fee pays the illion 303 for the service that communicates the chain of transactions to Bob _k. The service fee may be proportional to the iteration of the refund transaction. Since Ewan 303 will therefore have more power to commit higher iteration refund transactions to Bob _k Alice 103a may pre-sign only iterative refund transactions up to the level she is willing to pay.

For a payment channel for payment to Bob _k, a funds transactionRefund transactionExamples of one refund transaction are shown in tables 9 and 10, respectively.

TABLE 9 fund transaction, PCA, one-to-many.

It should be noted that the illite 303 gets his service fee in the refund transaction. See table 10.

TABLE 10 refund transaction, PCA, one-to-many.

8. Further comment on

Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art once the disclosure herein is given. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

For example, some of the embodiments above have been described in terms of bitcoin network 106, bitcoin blockchain 150, and bitcoin node 104. However, it should be appreciated that a bitcoin blockchain is one specific example of a blockchain 150, and that the above description is generally applicable to any blockchain. That is, the present invention is in no way limited to a bitcoin blockchain. More generally, any of the references above to the bitcoin network 106, bitcoin blockchain 150, and bitcoin node 104 may be replaced with reference to the blockchain network 106, blockchain 150, and blockchain node 104, respectively. The blockchain, blockchain network, and/or blockchain nodes may share some or all of the characteristics of the bitcoin blockchain 150, bitcoin network 106, and bitcoin node 104 as described above.

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

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

Even more colloquially, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element" wherein such entities/elements are configured to perform some or all of the roles of creating, publishing, propagating, and storing a chunk. The functionality of such network entities/elements may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

Some embodiments have been described in terms of a blockchain network for implementing a workload proof consensus mechanism to protect underlying blockchains. However, workload certification is only one type of consensus mechanism, and any type of suitable consensus mechanism may be used in general embodiments, such as equity certification, delegated equity certification, capacity certification, or time-lapse certification. As one particular example, the equity proof uses a randomization process to determine which blockchain node 104 has an opportunity to generate the next block 151. The selected node is commonly referred to as a verifier. The blockchain node may lock its token for a period of time to have an opportunity to become a verifier. Typically, the node that locks the maximum mortgage for the longest time is most likely to be the next verifier.

It should be understood that the above embodiments are described by way of example only. More colloquially, a method, apparatus or program may be provided in accordance with any one or more of the following statements.

Statement 1a computer-implemented method for facilitating respective payments between one or more respective first parties and a second party, wherein each respective first party and the second party is configured to create a respective payment channel by generating a respective channel-opening transaction comprising 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, wherein the respective output locks a respective maximum value, wherein the method is performed by an intermediary party, and the method comprises, for each respective first party:

Obtaining one or more respective channel closing transaction templates from the second party, wherein each respective channel closing transaction template comprises a respective input referencing the respective output of the respective channel opening transaction and comprising 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 output locks a respective first amount of the respective maximum value, and wherein the respective second output locks a respective second amount of the respective maximum value;

Obtaining one or more respective channel closing transactions, each respective channel closing transaction generated by including a respective signature of the respective first party in the respective input of a respective channel closing transaction template, and

A selected respective channel closure transaction of the one or more respective channel closure transactions is sent to a blockchain network or to the second party.

Statement 2 the method of statement 1 wherein the one or more respective first parties comprise a plurality of respective first parties.

Statement 3. The method of statement 1 or 2 wherein each output of the respective channel closure transaction is signed by the respective signature of the second party included by the respective input of the respective channel closure transaction.

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 the second party are configured to create a respective payment channel by generating a respective channel-opening transaction comprising 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, wherein the respective output locks a respective maximum value, wherein the method is performed by an intermediary party, and the method comprises, for each respective first party:

Obtaining one or more respective channel closing transaction templates from the second party, wherein each respective channel closing transaction template comprises a respective input referencing the respective output of the respective channel opening transaction and comprising 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 output locks a respective first amount of the respective maximum value, and wherein the respective second output locks a respective second amount of the respective maximum value, and

And sending a selected one of the one or more respective channel closing transaction templates to the respective first party.

Statement 5 the method of any preceding statement wherein each respective channel closing transaction template comprises a respective third output of a public key locked to the intermediary party, and wherein the respective third output locks a service charge value, wherein the respective first amount of the respective maximum value equals the respective maximum value minus a third amount of the respective maximum value minus the service charge value, and the respective second amount of the respective maximum value equals the third amount of the respective maximum value plus the service charge value.

Statement 6 the method of any preceding claim, wherein, for each respective first party, the selected respective channel shutdown transaction is the respective channel shutdown transaction having the highest respective second number of the respective maximum value locked by the second output of the respective channel shutdown transaction.

Statement 7 the method of any preceding claim wherein the respective channel-on transaction and/or the respective channel-off transaction comprises metadata relating to the respective payment.

Statement 8. The method according to statement 1 or any dependent statement thereof, wherein said second direction provides said respective first party with a respective good and/or a respective service in exchange for said respective payment.

Statement 9. The method according to statement 4 or any dependent statement thereof, wherein each respective first party provides a respective commodity and/or a respective service to the second party in exchange for the respective payment.

Statement 10. A computer device, the computer device comprising:

a memory comprising one or more memory cells, and

A processing device comprising one or more processing units, wherein the memory stores code arranged to run on the processing device, the code being configured to perform the method according to any of clauses 1 to 9 when run on the processing device.

Statement 11 a computer program embodied on a computer readable memory and configured to perform the method according to any one of statements 1 to 9 when run on one or more processors.

According to another aspect disclosed herein, a method may be provided that includes acts of one or both of i) the one or more first parties, ii) the second party, and the intermediary party.

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

Claims

1. A computer-implemented method for facilitating respective payments between one or more respective first parties and a second party, wherein each respective first party and the second party are configured to create a respective payment channel by generating a respective channel-opening transaction comprising 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, wherein the respective output locks a respective maximum value, wherein the method is performed by an intermediary party, and the method comprises, for each respective first party:

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

3. The method of claim 1 or 2, wherein each output of the respective channel shutdown transaction is signed by the respective signature of the second party included by the respective input of the respective channel shutdown transaction.

4. A computer-implemented method for facilitating a plurality of respective payments between a plurality of 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 comprising 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, wherein the respective output locks a respective maximum value, wherein the method is performed by an intermediary party, and the method comprises, for each respective first party:

5. The method of any preceding claim, wherein each respective channel closing transaction template comprises a respective third output of a public key locked to the intermediary party, and wherein the respective third output locks a service charge value, wherein the respective first amount of the respective maximum value is equal to the respective maximum value minus the third amount of the respective maximum value minus the service charge value, and the respective second amount of the respective maximum value is equal to the third amount of the respective maximum value plus the service charge value.

6. The method of any preceding claim, wherein, for each respective first party, the selected respective channel shutdown transaction is the respective channel shutdown transaction having the highest respective second number of the respective maximum value locked by the second output of the respective channel shutdown transaction.

7. The method of any preceding claim, wherein the respective channel-on transaction and/or the respective channel-off transaction comprises metadata relating to the respective payment.

8. A method according to claim 1 or any claim dependent thereon, wherein the second direction provides the respective first party with a respective commodity and/or a respective service in exchange for the respective payment.

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

10. A computer device, the computer device comprising:

a memory comprising one or more memory cells, and

A processing device comprising one or more processing units, wherein the memory stores code arranged to run on the processing device, the code being configured to perform the method according to any of claims 1 to 9 when run on the processing device.

11. A computer program embodied on a computer readable memory and configured to perform the method of any of claims 1 to 9 when run on one or more processors.