QUIC Transactions

Abstract

A computer-implemented method for sharing blockchain transactions, the method being executed by a first party and comprising the steps of receiving a payee from a second party over a QUIC connection, the payee including a public key and / or a public key-based address, and sending a transaction to the second party over the QUIC connection, the transaction including an output locked to the payee.

Description

[Technical Field]

[0001] The present disclosure relates to a method for sending and receiving blockchain transactions using the QUIC network protocol. [Background technology]

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

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

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

[0005] The node that successfully solves the proof-of-work puzzle and creates the latest block is awarded a new transaction, typically called a "coinbase transaction," that distributes a digital asset amount, i.e., multiple tokens. Detecting and rejecting invalid transactions is performed by competing nodes, who act as agents of the network and are incentivized to report and block misbehavior. Widespread publication of information allows users to continuously audit node performance. Publication of simple block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying the amount of a digital asset derivable from the progression sequence of transactions. A spendable output is sometimes called a UTXO ("unspent transaction output"). An output may further comprise a locking script that specifies the conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coin-based transaction) comprises a pointer (i.e., a reference) to such output in a prior transaction and may further comprise an unlocking script for unlocking the pointed-to output's locking script. Thus, we consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input that includes a pointer to the output of the first transaction and an unlock script that unlocks the output of the first transaction.

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

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of all accounts is stored and constantly updated by a node separate from the blockchain. Summary of the Invention [Problem to be solved by the invention]

[0009] The Bitcoin blockchain was originally designed to provide an electronic cash system that allowed the direct exchange of value, for example, between users and between users and machines. However, the direct exchange of unpublished transactions (i.e., transactions that had not yet been broadcast to the network for verification) was quickly ruled out due to their vulnerability to man-in-the-middle attacks. Today, the direct exchange of transactions (i.e., between users, between users and machines, and between machines) is being reintroduced.

[0010] The need for fast and secure communication is highest when sending and receiving private transactions between two parties. Secure communication is essential to prevent man-in-the-middle attacks and other similar attacks. Fast communication is essential from a performance perspective, and is especially important when two parties are exchanging many private transactions, for example, for content streaming, contract negotiation, etc. [Means for solving the problem]

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for sharing blockchain transactions, the method being executed by a first party and including the steps of receiving a payment destination from a second party over a QUIC connection, the payment destination including a public key and / or a public key-based address; and sending a transaction to the second party over the QUIC connection, the transaction including an output locked to the payment destination.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method for sharing blockchain transactions, the method being executed by a second party and including: receiving a transaction from a first party over a QUIC connection, the transaction including a payee, the payee including a public key and / or a public key-based address; and sending the transaction to one or more blockchain nodes of a blockchain network.

[0013] The present invention uses the QUIC network protocol to send and receive blockchain transactions between a first party and a second party, e.g., between users. The first party acts as the sending party and the second party acts as the receiving party. The sending party sends a transaction to the receiving party. The receiving party then submits the received transaction to the blockchain network. The transaction is an unpublished transaction, which is defined as a transaction that has not yet been verified by a blockchain node and therefore not yet incorporated into a block of the blockchain.

[0014] QUIC (Quick UDP Internet Connections) is an alternative to TCP / IP. QUIC allows for fast handshakes, secure and authenticated sessions, and supports network switches (e.g., Wi-Fi to 4G). Transactions sent between a first party and a second party using QUIC are referred to herein as QUIC transactions. They support all the features of QUIC and provide a secure way to exchange private transactions between users and / or machines, which are then presented to the network, e.g., when most convenient for the user. Additionally, some embodiments of the present invention involve the use of a "QUIC channel," which is a fast, encrypted payment channel based on QUIC and QUIC streams.

[0015] The many benefits of using QUIC to share unpublished transactions are discussed in more detail below. [Brief explanation of the drawings]

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

[0017] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic mockup of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 1 is a schematic diagram illustrating a comparison between a TCP+TLS handshake and a QUIC handshake. [Figure 5] FIG. 1 illustrates a schematic diagram of an exemplary system for sharing unpublished transactions using QUIC. [Figure 6] FIG. 1 illustrates a schematic diagram of an exemplary sequence diagram for sharing unpublished transactions using QUIC. [Figure 7] FIG. 10 is a schematic diagram of another exemplary sequence diagram for sharing unpublished transactions using QUIC. [Figure 8] FIG. 10 is a schematic diagram of another exemplary sequence diagram for sharing unpublished transactions using QUIC. [Figure 9] FIG. 1 illustrates generally an exemplary sequence diagram for implementing a payment channel using QUIC. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0020] A blockchain 150 comprises a chain of blocks of data 151, where a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may prune data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where transaction, in this context, refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain will use one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property a monetary amount representing an amount of digital assets, such as a user 103, to which the output is cryptographically locked (requiring that user's signature or other solution to unlock and thereby redeem or spend). Each input points to an output of a previous transaction 152, thereby linking the transactions.

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

[0022] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not intended to be limited to any particular blockchain, protocol, or model. This refers to an ordered set of transactions that the node 104 accepts as valid and obligates the node 104 not to accept any other transactions attempting to use the same output.

[0023] For a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or sent to the network 106, but the previous transaction 152i must exist and be verified for the current transaction to be valid. Thus, as used herein, "preceding" refers to a predecessor in the logical sequence linked by a pointer, not necessarily to a creation or transmission time in the temporal sequence, and therefore does not necessarily preclude transactions 152i, 152j from being created or sent out of order (see the discussion below regarding orphan transactions). Antecedent transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0024] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. Similarly, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b as defined by the output of the current transaction 152j. In some cases, a transaction 152j has multiple outputs, dividing the input amount among multiple users or entities (one of which may be the original user or entity 103a to make the change). In some cases, a transaction can also have multiple inputs, collecting amounts from multiple outputs of one or more previous transactions and redistributing them into one or more outputs of the current transaction.

[0025] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (either manually or by an automated process used by that party), the enacting party then transmits the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient will eventually transmit this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is also not excluded that the party 103 enacting a new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104 and in some instances not to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to the blockchain node protocol applied in each of the blockchain nodes 104. Blockchain node protocols typically require blockchain nodes 104 to check that the cryptographic signature of a new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may include checking that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i to which the new transaction assigns it, where the condition typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i.Alternatively, it may simply be a fix to the blockchain node protocol alone, or a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

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

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

[0028] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof that can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the hash output satisfies the conditions). The first blockchain node 104 propagates the block to a threshold consensus of other nodes, who accept the block and enforce the protocol rules. The ordered set of transactions 154 will then be recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 1561n-1 in the chain. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction; otherwise, it is known as a double-spend. Once created, blocks 151 cannot be changed because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. Transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, thus providing an immutable public ledger of transactions.

[0029] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool 154 of transactions not yet published at any given time, depending on when they began searching for a solution or the order in which they received transactions. Whoever solves the respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unpublished transactions. There is also a protocol for resolving any "forks" that may occur, which ensures that two blockchain nodes 104 solve the puzzle within a very short time of each other and that competing views of the blockchain are propagated between nodes. In essence, the longest stretch of either branch of the fork becomes the final blockchain 150. Note that this does not affect users or agents of the network, as the same transactions appear in both forks.

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

[0031] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server or an entire data center comprising one or more physical server units. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

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

[0033] Also connected to the network 101 are computing devices 102 for each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., obtaining a copy of the blockchain from a blockchain node 104).

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

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

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

[0037] The client application 105 has at least a "wallet" functionality. It has two main functions: one is to allow each party 103 to create, approve (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104 for propagation throughout the network of blockchain nodes 104 and thereby inclusion in the blockchain 150; and the other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0038] It should be noted that while various client functionality may be described as being integrated into a given client application 105, this is not necessarily a limitation; instead, any client functionality described herein may be implemented in a suite of two or more separate applications, for example, interfacing via an API or one plugging into the other. More generally, client functionality may be implemented at the application layer or a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be understood that this is not a limitation.

[0039] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet functionality of the client 105 to submit transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in some embodiments, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides transaction authenticity in part through its public visibility). The wallet functionality on each computing device 102 is configured to formulate and submit transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol and forward the transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol works in conjunction with a given node protocol to jointly implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0040] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the associated transaction protocol. She then sends the transaction 152j from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, these may be the blockchain nodes 104 with the best connection to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

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

[0042] Upon entering the ordered pool 154 of pending transactions maintained by a given blockchain node 104, that blockchain node 104 will begin a race to solve the proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions, but whoever gets there first will initially define the set of transactions contained in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once proof-of-work is complete for the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 has a pointer to the previous transaction, so the order of the transactions is also immutably recorded.

[0043] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have competing views about which instance is "valid" 151 before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and then discovers that a second instance has been recorded in the blockchain 150, that blockchain node 104 must then accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one that was not published in block 151).

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

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

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

[0047] For example, suppose Alice 103a wishes to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of the digital asset locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 can refer to any previous (i.e., earlier) transaction that still has unspent output 203 locked for Alice.

[0048] By the time Alice creates new transaction Tx1, or at least by the time Alice submits new transaction Tx1 to network 106, predecessor transaction Tx0 may already have been validated and included in block 151 of blockchain 150. It may already be included in one of blocks 151 at that point, or it may still be waiting in ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to network 106 together, or Tx0 may be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. As used herein in the context of a sequence of transactions, the terms “predecessor” and “successor” refer to the order of transactions in the sequence (e.g., which transaction points to which other transaction), as defined by the transaction pointers specified in the transactions. These may equally be interchanged with “predecessor” and “successor,” or “earlier” and “later,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated until the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered orphaned. It may be discarded or buffered for a period of time to wait for its parent, depending on the node's protocol and node behavior.

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

[0050] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S), used by blockchain networks. A lock script specifies the information needed to spend the transaction output 203, such as Alice's signature requirements. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script's criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

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

[0052] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the condition defined in the lock script (where this condition may comprise one or more criteria). In embodiments, this involves concatenating the two scripts: <Sig P A > <P A > || [Checksig P A ] where '||' denotes concatenation, '<...>' means to place data on the stack, and '[...]' is a function composed by the lock script (a stack-based language in this example). Similarly, rather than concatenating scripts, one may run them one after the other using a common stack. Either way, when run together, the scripts will use Alice's public key P, which is included in the lock script in the output of Tx0. A, to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data comprises Tx1 in its entirety (so a separate element specifying the signed portion of the data does not need to be included in the clear, as it is essentially already there).

[0053] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then, given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature with the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that, in this specification, references to signing a particular portion of data, part of a transaction, etc., may, in embodiments, mean signing a hash of that portion of data or part of a transaction.

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

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

[0056] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" part of the amount defined as spent in the UTXO while another part is spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1, or to pay another party.

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

[0058] Alice and Bob's digital assets consist of the UTXOs locked to them anywhere in any transaction 152 within the blockchain 150. Thus, typically, a given party's 103 assets are distributed across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of the wallet functionality of the client application 105 to reconcile the values ​​of all the various UTXOs locked to each party that have not yet been spent in another subsequent transaction. This can be done by querying the copy of the blockchain 150 stored in one of the Bitcoin nodes 104.

[0059] Note that script code is often represented generally (i.e., without using a precise language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to specific opcodes in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a lock script, stores data within the transaction, thereby creating an unspendable output of the transaction that can be immutably recorded in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

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

[0061] A lock script is sometimes referred to as a "scriptPubKey," which typically refers to the fact that each transaction includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," which typically refers to the fact that it provides the corresponding signature. However, more generally, it is not essential in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, any one or more conditions can be defined using a scripting language. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

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

[0063] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a local area network like a mobile cellular network or a local wireless network, or even over a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, the side channel 107 referred to anywhere herein may comprise any one or more links over one or more network technologies or communications media for exchanging data “off-chain,” i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is said that Alice and Bob exchange particular pieces of information, data, etc. over the side channel 107, this does not necessarily mean that all of these pieces of data must be transmitted over the exact same links or the same type of network.

[0064] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing an embodiment of the presently disclosed scheme. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and / or send transactions and / or other data via side channels 301, and send transactions to one or more nodes 104 to be propagated through the blockchain network 106, e.g., according to the schemes discussed above and in more detail below.

[0065] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of each user's computing device 102, including outputting information to each user 103 via user output means of the device 102 and receiving input from each user 103 via user input means of the device 102. For example, the user output means may include one or more display screens (touch or non-touch screens) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may comprise, for example, one or more touch screens (the same or different from those used for the output means); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and speech or voice recognition algorithms for receiving speech or audio input; one or more gesture-based input devices for receiving input in the form of manual or physical gestures; or an input array, such as one or more mechanical buttons, switches, or joysticks.

[0066] It should be noted that while various functionalities herein may be described as being integrated into the same client application 105, this is not necessarily a limitation; instead, they may be implemented in a set of two or more separate applications, for example, one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between two or more applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Herein, where reference is made anywhere in this specification to a single or given application 105, etc., it will be recognized that this is merely by way of example, and more generally, the described functionality may be implemented in any form of software.

[0067] 3B provides a mockup of an example user interface (UI) 500 that may be rendered by the UI layer 402 of client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b or by any other party's client.

[0068] 3B shows a UI 500 from Alice's perspective. The UI 500 may comprise one or more UI elements 501, 502, 503 rendered as separate UI elements via user output means.

[0069] For example, the UI elements may comprise one or more user-selectable elements 501, which may be different on-screen buttons, different options in a menu, etc. User input means are arranged to allow user 103 (in this case Alice 103a) to select or otherwise manipulate one of the options by clicking or touching the on-screen UI element, speaking the name of the desired option, etc. (Note: as used herein, the term "manual" is meant merely to contrast with automatic and is not necessarily limited to the use of hands or both hands.)

[0070] Alternatively or additionally, the UI element may comprise one or more data entry fields 502. These data entry fields may be rendered via user output means, for example on a screen, and data may be entered into the fields via user input means, for example a keyboard or touch screen, or data may be received orally, for example based on voice recognition.

[0071] Alternatively or additionally, the UI element may comprise one or more information elements 503 that are output to output information to the user, for example this / these may be rendered on a screen or audibly.

[0072] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not material. The functionality of these UI elements will be discussed in more detail below. It will also be understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0073] Network Protocol This section briefly describes some concepts and techniques that will be used in the remainder of the description when describing the main embodiment of the present invention. First, we discuss IP-to-IP transactions and their possible implementation using IPv4 and IPv6 protocols. Next, we discuss how payment channels work, and finally introduce the QUIC protocol.

[0074] A discussion of QUIC is also provided, particularly its use to improve IP-to-IP transactions, exchange fast, secure, private, and undisclosed transactions, and to create payment channels.

[0075] IP to IP transactions Bitcoin was designed with built-in IP-to-IP transactions, meaning that a client wanting to send a transaction could contact the recipient's IP address, retrieve their Bitcoin address, and send the transaction directly to the recipient. However, the initial implementation was removed in 2011 due to its vulnerability to man-in-the-middle (MITM) attacks.

[0076] The reintroduction of IP-to-IP transactions has been proposed. Certificates can be used to guarantee the identity of hosts and validate the authenticity of Bitcoin addresses associated with IP addresses. This technology can be used in both IPv4 and IPv6. While IPv4 solutions rely on DNSSEC (Domain Name System Security Extension) and SSL (Secure Socket Layer) certificates to derive certified public keys using zone keys and prevent MITM attacks, IPv6 natively allows for the secure exchange of Bitcoin addresses using IPsec to create end-to-end authentication. Alternatively, cryptographically generated addresses (CGA) (already used to generate IPv6 addresses) can be used to generate Bitcoin addresses when the recipient is not online, allowing transactions to be sent without the need for real-time interaction between clients.

[0077] Payment Channels Payment channels are a class of technology designed to facilitate Bitcoin transactions between multiple users without registering every transaction on the blockchain. A typical payment channel only publishes two transactions to the blockchain, but allows for a nearly unlimited number of payments to be made between participants. Payment channels allow participants to communicate and exchange information quickly without paying transaction fees.

[0078] Payment channels exchange transactions using a sequence number field to indicate whether a transaction is complete. If the sequence number is at its maximum value (0xFFFFFFFF), the transaction is complete; if a transaction has a smaller value, it can be updated by incrementing its sequence number and resubmitting it (only the one with the largest sequence number is valid). A transaction can be used when it is complete or after a set lock time has elapsed. A payment channel is opened using a funding transaction (also called an initiating transaction) and a corresponding refunding transaction (which returns the initial funds to the participants after the lock time has expired). All subsequent communication occurs via Bitcoin transactions, following the rules specified by the payment channel. A user can update a transaction (and its sequence number), sign it, and send it to other participants. If the recipient is satisfied, they sign the transaction and send it back as well. This creates a checkpoint for the payment channel (the last agreed-upon transaction). If the recipient is not satisfied with the new transaction, they can either update the transaction and send it back, or reject it, wait for the lock time, and recover the funds as agreed upon in the last valid checkpoint after the lock time (or a refund transaction if there is no checkpoint).

[0079] Use cases for payment channels include micropayments for content streaming, commercial agreements with frequent payments, etc.

[0080] QUIC QUIC is a network protocol widely used to improve the performance of connection-oriented applications, which are all applications that require an end-to-end connection between devices to be established before data can be sent (e.g., web browsing, video streaming, file transfer, remote login). QUIC does not rely on TCP, but instead uses the UDP protocol to establish multiplexed connections between two clients.

[0081] Advantages of QUIC: ● QUIC exchanges setup keys during an initial handshake process: all data needed for encryption is exchanged immediately, eliminating the need to set up a TCP connection and then negotiate a security protocol (e.g. SSL) which uses additional packets. ● QUIC handles packet loss: Data flow is controlled independently at the QUIC level (UDP does not include loss recovery), which means that the protocol stack can service streams independently and errors in one stream do not block others (as happens with TCP). ● QUIC encrypts packets individually: there is no encrypted data waiting for partial packets. ● QUIC handles network switch events: it contains a connection identifier (Connection ID) that uniquely identifies the connection to the server, regardless of its source. If a connection drops, it can be re-established by sending a packet with the same Connection ID as the original, even if the sender's IP address changes. This is especially beneficial for mobile devices, which can switch from WIFI to mobile networks using the same network session (TCP has to timeout the old session and create a new one). ● QUIC is implemented in the application space: it does not require any changes to the kernel and can be easily adopted by all clients that already support UDP. This has led to the rapid adoption of this protocol worldwide compared to other network technologies (e.g. IPv6), which have been adopted much slower. ● QUIC supports fallback to TCP: QUIC and TCP connections can be opened simultaneously, allowing for zero-latency fallback for systems that do not support QUIC.

[0082] Connection ID A connection ID is used to uniquely identify a logical connection between two processes before exchanging data (e.g., a communication channel between a client and a server for requesting and receiving a web page). Each peer chooses a connection ID that is exchanged with the other peer during the QUIC handshake. Connection IDs are independently created by the endpoints and ideally do not contain any information that could be used to associate the connection with another connection (so, preferably, a new, independently created connection ID should be created for each new connection).

[0083] The Connection ID ensures that any changes in the lower protocol layers do not cause a disruption of the QUIC connection. Packets with long headers contain a source and destination Connection ID, while packets with short headers contain only the destination Connection ID. The Source Connection ID is used by other peers to set the Destination Connection ID.

[0084] TCP+TLS / SSL vs. QUIC TCP provides reliable, ordered, and error-checked delivery of streams of bytes between applications. It is connection-oriented; a connection between systems must be established before data can be transmitted. The connection is initialized using a three-way handshake. TLS / SSL cryptographic protocols run on top of TCP, used to provide communication security and ensure privacy and data integrity (the connection at this point is private, authenticated, and reliable). However, TLS / SSL adds latency because a separate connection must be established, requiring a separate handshake.

[0085] QUIC provides all of these capabilities from the transport protocol itself, and the initial QUIC handshake combines a three-way handshake with a TLS handshake to authenticate, encrypt, and speed up the initial connection establishment. Compared to the two round trips required by TCP+TLS / SSL, the QUIC handshake is completed in only a single round trip between client and server (see comparison in Figure 4).

[0086] QUIC uses the same principles as TLS, encrypting data using symmetric cryptography with a shared secret negotiated during the QUIC handshake (similar to a TLS handshake), and offers other benefits, such as encryption of additional connection metadata that can be exploited by middleboxes to intercept connections. This ensures that it is impossible to correlate activity between entities.

[0087] QUIC Transactions Embodiments of the present invention use the QUIC network protocol to share private blockchain transactions between two parties. FIG. 5 illustrates an exemplary system 500 for implementing some embodiments of the present invention. The system 500 includes a first party (Alice) 103a and a second party (Bob) 103b. The system 500 also includes one or more blockchain nodes 104 of a blockchain network 106. The first and second parties are labeled Alice 103a and Bob 103b, respectively, although the first and second parties may each be configured to perform any part or all of the functions identified as being performed by Alice 103a and Bob 103b with reference to FIGS. 1-3 . It should also be noted that, in general, either or both of the first and second parties may be autonomous machines, i.e., machines not operated by a user.

[0088] In the context of the present invention, Alice 103a acts as a sender and Bob 103b acts as a receiver. That is, Alice sends an unpublished transaction to Bob 103, and Bob 103b therefore receives the unpublished transaction. Bob 103b then submits the unpublished transaction to the blockchain network 106. The unpublished transaction will then be published in block 151 of the blockchain 150. Note that in some examples, Bob 103b may send the unpublished transaction to Alice 103a, and the unpublished transaction may then be sent to the blockchain network 106 by Alice 103a.

[0089] Generally, Bob 103b sends a public key or public key-based address (e.g., a hash of the public key) to Alice 103a over a QUIC connection. Alice 103a receives the public key or public key-based address from Bob 103b over the QUIC connection. Alice 103a then sends an unpublished transaction to Bob 103b over the QUIC connection, which is received by Bob 103b. After receiving the unpublished transaction from Alice 103a, Bob 103b transmits the unpublished transaction to one or more blockchain nodes 104 for recording in the blockchain 150.

[0090] For simplicity, the public key or public key-based address will be referred to below as the payment destination. Bob 103b may send either the public key or the public key-based address, or both, to Alice 103a, depending on the particular use case. Note that the term "payment destination" does not necessarily imply that Alice 103a is paying Bob 103b for something, e.g., goods or services. Rather, a payment destination is a destination to which an amount of digital assets (i.e., the blockchain's native token) is assigned. A payment destination may form part of a locking script (e.g., in the case of a UTXO-style blockchain).

[0091] Preferably, the public key forming the payee, or the public key on which the payee is based, is owned by Bob 103b. However, it is not excluded that Bob 103b may provide Alice 103a with a public key owned by another user or other type of entity. A payee may be linked to a certified public key, i.e., a public key that has been certified as belonging to a particular user. For example, the payee may be a certified public key, or the payee may be a hash of the certified public key. In another example, the payee may be a public key (or a hash thereof) that is deterministically derived from the certified public key.

[0092] Note that it is not excluded that Alice 103a obtains the payee using an alternative method, i.e., not over a QUIC connection: for example, Alice 103a may already have access to Bob's public key, or Bob 103b may send the payee to Alice 103a over a different connection.

[0093] Generally, a QUIC connection has three phases: a handshake phase, an open connection phase, and a closed connection phase. As described above, the handshake phase is used to exchange connection identifiers (IDs). Each message sent over QUIC includes a source connection ID and a destination ID. Each party has its own source connection ID, which is used by the other party as the destination ID for its outgoing messages. For example, when Alice 103a sends a message to Bob 103b, Alice's message includes the source connection ID set by Alice 103a and the destination ID set by Bob 103b. The exception is the first handshake message, in which case the destination ID may initially be set as arbitrary data. Thereafter, Bob's message includes the source connection ID set by Bob 103b. The destination connection ID in Bob's message corresponds to Alice's source connection ID. Those skilled in the art will be familiar with the QUIC handshake. The open connection phase may involve one or more messages being sent between Alice 103 and Bob 103b, where the source and destination connection IDs were established during the handshake phase, followed by the closed connection phase by closing the QUIC channel.

[0094] Bob 103b may send the payee to Alice 103a during the QUIC handshake phase, i.e., as part of an outgoing QUIC handshake message. Bob's outgoing handshake message may be the initial QUIC handshake message. Alternatively, Alice 103a may send the initial QUIC handshake message to which Bob 103b responds. For example, Alice 103a may send a QUIC handshake message to Bob 103b that includes a request for a payee.

[0095] If Bob's outgoing QUIC handshake message is the initial handshake message, Bob 103b sets the source connection ID using data unique to him. For example, the source connection ID may include a public key linked to Bob 103b (which may or may not be the same as the payee's underlying public key). The source connection may include additional or alternative data, such as other types of identifiers. More details are provided below. Because this is the initial handshake message, the destination connection ID can be set as any arbitrary data.

[0096] If Bob's outgoing QUIC handshake is in response to an initial incoming QUIC handshake message from Alice 103a, Alice's QUIC handshake message will include a source connection ID. Bob 103b uses Alice's source connection ID as the destination connection ID in his outgoing QUIC handshake message. For example, Alice 103a may use her public key or a different type of identifier as her source connection ID.

[0097] A typical QUIC message, including a QUIC handshake message, includes a source connection ID field, a destination connection ID field, and a payload field. In some embodiments, the payee may be included in the payload field of Bob's QUIC handshake message.

[0098] Optionally, the payload field may include a transaction template. A transaction template is an unpublished blockchain transaction that includes data in one or more inputs and / or one or more outputs of the transaction. For example, Bob 103b may include data in an unusable output of the transaction template, such as an OP_FALSE OP_RETURN output. In some examples, the transaction template may include a payee. The payee may be included as part of a locking script. That is, Bob 103b may include a locking script that is locked to (i.e., directed to) the payee. For example, the locking script may include a pay-to-public-key-hash (P2PKH) script that is locked to a public key hash.

[0099] As mentioned above, Bob's handshake message may be sent in response to an incoming handshake message from Alice 103. In that case, Alice 103a may include a payment request in the source connection ID field and / or payload field of her outgoing QUIC handshake message. The payment request may include a request for a payee and / or a transaction template.

[0100] Upon obtaining the payee (e.g., included as part of a transaction template), Alice 103a creates a transaction that includes the payee (e.g., an output locked to the payee) and sends the transaction to Bob 103b over the QUIC connection. The transaction is included in the payload field of a QUIC message. The QUIC message includes the source connection ID and destination connection ID established during the handshake phase. Bob 103b may optionally respond with an acknowledgement message.

[0101] After Bob 103b receives the transaction, he submits it to the blockchain network 106.

[0102] In some embodiments, rather than sending the unpublished transaction to Bob 103b after the handshake phase, Alice 103a may send the transaction to Bob 103b during the handshake phase. That is, Alice 103a may include the transaction in an outgoing QUIC handshake message to Bob 103b. The transaction may be included in the source connection ID field and / or the payload field of the handshake message.

[0103] Alice's handshake message may be the initial handshake message. Alternatively, Bob 103b may send the initial handshake message to Alice 103a. For example, the payee may be included in the source connection ID field of Bob's QUIC handshake message. In some examples, Bob 103b may include a transaction template in the source connection ID field. The transaction template may include the payee.

[0104] In some embodiments, Alice 103a and Bob 103b may set up a payment channel using a QUIC connection. The payment channel is used to send multiple unpublished transactions between the two parties, where only one of the unpublished transactions is presented to the blockchain network 106. The initial transaction is sent from Alice 103a to Bob 103b as described above. Bob 103b presents the initial transaction to the blockchain network 106. Alternatively, Alice 103a may submit the initial transaction to the network 106. Alice 103a then sends one or more updated versions of the initial transaction to Bob 103b. For example, the amount of native tokens locked in Bob 103b may change (e.g., increase) with each updated version of the initial transaction. Each updated version is sent as part of a respective QUIC message, e.g., included in a payload field. When the QUIC connection is closed by Alice 103a or Bob 103b, Bob 103b presents one of the updated versions of the initial transaction (e.g., the latest version) to the blockchain network 106. It is also not excluded that Alice 103a may send one of the updated versions to the blockchain network 106. Preferably, either party can close the channel; otherwise, the other party may cheat and transmit an older, more advantageous transaction to the network 106. If one party tries to cheat and transmit an older update version to the blockchain, the other party can transmit the latest update version. The node 104 accepts the transaction with the higher sequence number of the last agreed-upon update version.

[0105] In some examples, Alice 103a may send updated versions of each of the initial transactions in response to receiving a respective request message from Bob 103b. That is, Bob 103b may send a QUIC message containing a request to Alice 103a, and in response, Alice 103a sends an updated version of the initial transaction to Bob 103b. Alice 103a and Bob 103b may repeat this process multiple times before a final transaction is sent to the network 106.

[0106] In some examples, Bob 103b may stream data to Alice 103a in response to receiving each updated version of the initial transaction. For example, the data may be media content, such as an image, video, document, etc., and Bob 103b may send a portion of the media content to Alice 103a in response to each updated version. As a specific example, Bob 103b may send a one-minute portion of a video to Alice 103a upon receiving each updated version.

[0107] Further details regarding exemplary embodiments of the present invention are provided below. Note that at least some of the functionality described below is optional. In particular, the following examples are described in the context of the Bitcoin blockchain, but it should be recognized that they apply equally to other types of blockchains.

[0108] The present invention enables fast and secure direct transfer of Bitcoin (or other types of tokens, or more generally, data) using the QUIC protocol. QUIC actually improves the performance of web applications in terms of speed (only one handshake is required and multiple connections can be used) and improved stability (support for network switches). Furthermore, previous approaches have several limitations: on the one hand, IP-to-IP transactions using IPv4 require the recipient to possess a certificate issued by a certificate authority. While this is not a serious problem for enterprises, it is a limitation for private users who want to receive IP-to-IP transactions. On the other hand, IP-to-IP transactions using IPv6 solve this problem using IPsec and CGA to generate new Bitcoin addresses. However, IPv6 is not yet widely supported.

[0109] As already discussed, the QUIC protocol is designed to be a secure transport protocol by default. It provides authentication and encryption, and the initial connection handshake is fast. QUIC is also easily integrated into current systems, allowing for rapid and widespread adoption of the protocol (unlike IPv6). QUIC is indeed embedded in the application space; by using UDP as its underpinning, it avoids requiring modifications to traditional client operating systems, making it easy to implement on existing machines.

[0110] QUIC uses a connection ID to identify connections, even across network changes. Since it is chosen independently by each peer, this field can be used to exchange Bitcoin public keys and incorporate any other information used to send and receive payments. This prevents MITM attacks and remains constant in case of network switch events, facilitating the creation of reliable, fast, encrypted payment channels.

[0111] Authentication Before sending a Bitcoin payment, the identity of the recipient (and optionally the sender) is preferably validated using an authentication protocol. Authentication protocols differ depending on the fact that the host either possesses a trusted certificate or does not. This section analyzes both scenarios.

[0112] Authentication using trusted certificates When a Bitcoin transaction recipient (and optionally the sender) has a certificate issued by a certificate authority (CA), they can transmit it to other hosts to prove their identity (similar to SSL / RLS). Alternatively, they can use DNSSEC authentication: DNSSEC is a suite of Internet Engineering Task Force (IETF) specifications that secure DNS records and information using certificate authorities (CAs) and a public key infrastructure (PKI). Finally, authentication can also be ensured using a CA on-chain. A CA on-chain can formulate, issue, and revoke digital certificates that link an individual's identity to a certified public key. Furthermore, a CA on-chain can build a public key infrastructure (PKI) on-chain using the links in the transaction to create a chain of trust. This method facilitates KYC identity management on the Bitcoin network.

[0113] It is expected that the majority of QUIC transactions (i.e., transactions shared using the described technology) will be to online shops or remotely accessed machines using trusted certificates issued by a CA, and thus authentication using trusted certificates will be the primary use case.

[0114] Self-Certification If the recipient does not have a trusted certificate, self-certifying addresses, such as cryptographically generated addresses (CGA) and Host Identity Protocol (HIP), can be used to self-certify public keys (and derived Bitcoin addresses) without the need for a CA or PKI. Self-certifying addresses allow a host to prove it has the address it claims to have, without relying on a trusted authority. These addresses are generated using underlying public key cryptography: in a very basic form, the name or address of an object is the public key corresponding to that object, and public keys are assumed to be unique per host, making addresses easy to generate and validate. The public key of a Bitcoin address can be cryptographically linked to a public-private key pair, so anyone validating the correct generation of a self-certifying address can be assured with some security that the link is valid. The generation of self-certifying addresses is necessary because the addresses used as identities in QUIC transactions must be renewed with each new connection.

[0115] Authentication can easily be performed as a function of how CGAs function: they can be easily extended to derive session keys (via Diffie-Hellman or RSA) to provide confidentiality over the secure channel between sender and receiver, similar to how TLS works. Traditional PKI and Internet key exchange are not required when using CGAs was the entire purpose of creating them. End-to-end authentication and encryption can be performed using IPsec, and the IPsec suite consists of three main protocols: Security Associations (SAs), Authentication Headers (AHs), and Encapsulating Security Payloads (ESPs). The SA protocol is used to provide the necessary algorithms and data exchange bundle for the AH and / or ESP protocols. AH is used to ensure the authentication and integrity of the data being transmitted. ESP is used to provide data confidentiality plus what AH provides.

[0116] The described technique allows validating that a payment is sent to an address associated with a particular public key (preventing MITM and other attacks), but it cannot guarantee that the public key is associated with a particular user. A way to overcome this limitation is to validate the public key using an external authentication service such as Paymail. More details on this technique are given below.

[0117] Payment addresses Once a permanent or semi-permanent address is linked to an identity using a certificate, a self-certified address, or provided by a Paymail service, this "main" address can be used to generate linked addresses that will be used to receive payments. These payment addresses can be generated using hierarchical deterministic wallets where the main node is the permanent or semi-permanent address and the derived keys are used as payment addresses according to BIP32 rules and specifications.

[0118] Alternatively, a new public key can be generated using a payment-related message. In this case, the new public key can be generated as follows: new_pub_key=main_pub_key+SHA256(m)xG

[0119] The message m may be payment-related or something else. G is the base point of the elliptic curve.

[0120] The private key associated with the new public key can be calculated as follows: new_pr_key=main_pr_key+SHA256(m)

[0121] For any other application, a new public key should preferably be generated for any new payment received.

[0122] QUIC Transactions In the following sections, we describe how a client, Alice (e.g., a user), can use a QUIC transaction to send a payment directly to a recipient, Bob (who wishes to receive the payment). The payment flow can be initiated by the sender or the receiver, and we discuss both scenarios here.

[0123] In the first case, sender Alice 103a contacts receiver Bob 103b and tells him the amount she wishes to pay. Bob's wallet software creates a new public key and sends Alice 103a a BIP270 request payment template. Sender Alice 103a then pays the payment request by constructing, signing, and sending a transaction to the public key specified in the payment request. An exemplary process can be described as follows: 1. Client Alice 103a (sender) contacts receiver Bob 103b and confirms that she will accept payment using QUIC. ● If QUIC is not supported by the recipient, the process will be aborted and you will need to choose another payment method. 2. Client Alice 103a sends an HTTP request over QUIC specifying its source connection ID (and optionally authenticating itself). During the handshake, a packet with a long header is used to establish the source and destination connection IDs that each endpoint will use (each endpoint specifies in its source connection ID field the ID that it must use in the destination connection ID field of the other peer). 3. Receiver Bob 103b populates the Source Connection ID field with an identifier (e.g., using a key-linked trusted certificate or CGA to authenticate himself) and includes in the payload a BIP270 payment request template with the new Bitcoin public key linked to the master public key. 4. Client Alice 103a validates the recipient's identity (using one of the methods described above), populates a payment template to pay the provided Bitcoin address (received in the payload of the message received from Bob 103b), and sends the payment template to recipient Bob 103b using a QUIC channel. 5. Receiver Bob 103b collects the payment template and submits the transaction to the blockchain 150. 6. Optionally, Bob 103b responds to Alice 103a to acknowledge receipt of the signed payment template.

[0124] A diagram of a QUIC transaction initiated by sender Alice 103a is shown in FIG.

[0125] In the second case, receiver Bob 103b sends a payment request to sender Alice 103a. Bob's wallet software creates a BIP270 payment request template that specifies a new public key and the amount to be paid. Sender Alice 103a then pays the payment request by constructing, signing, and sending a transaction to the public key specified in the payment request. An exemplary process can be described as follows: 1. Receiver Bob 103b contacts sender Alice 103a and confirms that payment can be sent using QUIC. ● If QUIC is not supported by the sender, the process will be aborted and you will need to choose another payment method. 2. Receiver Bob 103b sends an HTTP request over QUIC. Bob 103b includes a source connection ID identifying itself (e.g., using a key linked to a trusted certificate or using CGA), and in the payload includes a BIP270 payment request template with the new Bitcoin public key linked to its master public key. During the handshake, a packet with a long header is used to establish the source and destination connection IDs that each endpoint will use (each endpoint specifies in its source connection ID field the ID that must be used in the destination connection ID field of the other peer). 3. Sender Alice 103a validates the identity of receiver Bob 103b, then chooses its source connection ID (which can be random or can use CGA to authenticate itself) and responds to Bob 103b to complete the handshake. 4. Client Alice 103a submits a payment template to pay to the provided Bitcoin address (received in the payload of the message received from Bob 103b) and sends the payment template to recipient B using a QUIC channel. 5. Receiver Bob 103b collects the payment template and submits the transaction to the blockchain. 6. Optionally, Bob 103b responds to Alice 103a to acknowledge receipt of the signed payment template.

[0126] A diagram of a QUIC transaction initiated by recipient Bob 103b is shown in FIG.

[0127] Note that the size of a Bitcoin address is made up of the following fields: For a total size of 25 bytes, <version_byte> <20 bytes of RIPEMD-160 (SHA-256 (PublicKey))> <4 bytes of checksum> The maximum size of a connection ID is currently 255 bytes. If necessary, you can reduce the size of the address by using one of the following options: 1. Only the public key is used as the connection ID, in the format RIPEMD-160(SHA-256(PublicKey)). A version byte and a checksum can optionally be included in the payload field. 2. The Bitcoin address is completely included in the payload field, and a different connection ID is selected.

[0128] QUIC embedded transactions In the previous section, we described how Bitcoin addresses can be exchanged using QUIC transactions. In fact, the entire transaction can be embedded in the connection ID field. A simple transaction is about 250 bytes, and therefore the entire transaction can be used as the connection ID. This solution can be an alternative to the QUIC transactions proposed in the previous section, allowing payments to be sent by simply opening a QUIC connection (only a handshake is required).

[0129] This process is similar to a QUIC transaction, but is particularly useful when a user requests a payment directly from another user, such as an online shop or service provider (as opposed to a user requesting an address and then sending a payment). The process of requesting and receiving a payment consists of the following steps, assuming that user Alice 103a wishes to make a payment to user Bob 103b, and Bob 103b initiates a communication sending a payment request. An exemplary process can be described as follows: 1. Receiver Bob 103b checks if the client is using the QUIC protocol (a blockchain version with no limit on the size of the connection ID). ● If QUIC is not supported by peer Alice 130a, the process is aborted and another payment method is selected. 2. Receiver Bob 103b sends a payment request to peer Alice 103a: ● A QUIC connection is opened by the recipient Bob 103b. Receiver Bob 103b selects a source connection ID that contains the public key to send the payment to and the amount to be paid. Other information, such as a CGA, can be added to prove its identity. Other optional parameters, such as a description or an identification code, can be added. ● The destination connection ID is chosen temporarily and randomly (similar to a standard QUIC handshake). A message is sent to Alice 103a. 3. Alice 103a, the client wishing to make a payment, responds using the Bitcoin transaction as the source connection ID: Payment information (eg public key, amount) is extracted from the source connection ID received from Bob 103b, whose source connection ID is now Alice's 103a destination connection ID. Peer Alice 103a validates the identity of recipient Bob 103b by checking the information contained in Bob's 103b source connection ID. o If the identity cannot be validated, stop the process. ● User Alice 103a wishing to make a payment creates a Bitcoin transaction transferring a specified amount to the indicated public key, which is used as the source connection ID of peer Alice 103a. 4. Receiver Bob 103b receives the packet from peer Alice 103a, reads the source connection ID, extracts the Bitcoin transaction, and presents it on-chain.

[0130] A diagram of a QUIC embedded transaction is shown in Figure 8.

[0131] A QUIC handshake is used to exchange payment details and transfer bitcoins, so no further communication is required, making a QUIC embedded transaction the quickest way to receive payments.

[0132] QUIC Channel Payment channels allow multiple user-to-user Bitcoin transactions to occur without registering every transaction on the blockchain. The new form of payment channel disclosed herein, hereafter referred to as a QUIC channel, combines the benefits of current payment channels with QUIC functionality. QUIC channels use the same technology used in payment channels to update transactions and exchange information. Funding transactions (referred to above as initiating transactions) can be created using QUIC transactions or QUIC embedded transactions, where all participants can include CGA addresses or another form of authentication.

[0133] This open QUIC session can be used to directly send / receive some content (e.g., a stream of data), but it has additional features. In fact, a QUIC session automatically guarantees peer authentication and content encryption, so any Bitcoin transactions exchanged using this channel inherit these properties. Furthermore, because the session channel remains open even when networks (and IP addresses) change, transaction exchange is very fast and efficient (there is no need to re-establish a TCP connection to transmit updated Bitcoin transactions), even on mobile devices. For example, a client can continuously update transactions to increase the amount paid to a movie provider, and the provider can continue streaming the movie using the QUIC channel. This process does not require any interaction with the Bitcoin network, except for funding and refund transactions. When the client or provider wants to stop streaming, they close the QUIC connection. When the QUIC connection is closed, the last agreed-upon transaction is recorded on the blockchain.

[0134] A QUIC channel can be closed when the QUIC connection is closed (as in the previous example). Alternatively, two peers can pause the QUIC channel by closing the QUIC connection without requesting the latest agreed-upon transaction. The QUIC channel can be resumed later by reinitializing the QUIC connection using the same connection ID used in the previous connection. At any time, one of the peers can request the latest agreed-upon transaction and close the QUIC channel. By recording the latest agreed-upon transaction, the QUIC channel can always be closed, which prevents cheating attempts (e.g., if one peer records an older, more favorable transaction, the other peer can immediately record the latest agreed-upon one and claim the legitimate value after the lock time).

[0135] QUIC channels can use QUIC streams: streams provide an abstraction of a lightweight, ordered stream of bytes to applications. A single bidirectional stream frame can open a stream, carry data, update transactions, and close the stream.

[0136] The process for opening a QUIC channel is similar to that described in the previous section. An example QUIC channel flow is shown in Figure 9.

[0137] Paymail integration Paymail (see https: / / bsvalias.org / ) is an identity protocol that replaces Bitcoin hexadecimal addresses with human-readable names called paymail addresses. Paymail includes methods for service discovery, public key infrastructure and basic address resolution, provides user authentication, and enables direct exchange of BSV tokens.

[0138] The Paymail payment flow is as follows: the sender uses a service discovery process to look up the responsible Paymail service for the recipient's Paymail address, then contacts this Paymail service to discover a suitable public key associated with the recipient's Paymail address. The payment can then be completed.

[0139] Paymail uses a REST API to convert a Paymail email address into a Bitcoin public key and provides all other related services. Because a new public key is generated each time (typically using an HD derivation path), this key can be used as a unique identifier and therefore as the connection ID for QUIC connections; this public key is essentially tied to each paymail identity. Paymail and QUIC can be integrated such that the connection ID required to open a QUIC channel is provided by the user's paymail service (which uniquely authenticates both users). For example, a user who knows their paymail email address (which is always the same) can request a new public key (which is always new) from their paymail provider and use it as the connection ID to initialize a new QUIC channel with another user. Similarly, a user can validate another user's identity by checking whether the connection ID belongs to the paymail email address associated with that user (i.e., using the "public key owner validation" service provided by Paymail).

[0140] Payment Type Paymail is designed for user-to-user interaction, such as resolving an address using an API. This interaction, using the HTTP protocol, introduces a lot of delay that is not typically relevant to human users, but can be important for machine-to-machine interaction. Furthermore, machines do not benefit from the use of human-readable addresses. Therefore, the use of Paymail may vary depending on the type of entity sending the payment. For example: ● User-to-user or user-to-machine payments: Use Paymail for simple payments (e.g. paying for a coffee) and Paymail authentication over the QUIC channel for recurring micropayments (e.g. video streaming). ● Machine-to-machine payments: Use IP-to-IP or QUIC-to-QUIC for simple payments (e.g., transfer of goods), and use QUIC channels for recurring micropayments (e.g., charging autonomous electric vehicles).

[0141] Example use cases for QUIC transactions and QUIC channels Apart from integrating with the Paymail service, QUIC transactions and QUIC channels have several other use cases, particularly in enabling microtransactions for web services. QUIC has already been adopted by many major websites, including Google®, YouTube®, and Facebook®, and these services can easily extend their services to provide premium content on demand using QUIC channels. Thanks to QUIC channels, micropayments are easy to implement and manage, and examples of premium content could include video and audio streaming, news, access to services, and games. Another use case is integrating QUIC payments and QUIC channels into mvfst, Facebook's available open-source QUIC client and server implementation. Integration with such a set of libraries would allow any company already using or planning to use that implementation to also have access to microtransactions on the blockchain.

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

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

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

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

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

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

[0148] Statement 1. 1. A computer-implemented method for sharing blockchain transactions, the method being performed by a first party and comprising: receiving a payment destination from a second party over a QUIC connection, the payment destination including a public key and / or a public key-based address; sending a transaction to the second party over the QUIC connection, the transaction including an output locked to the payee; A method comprising:

[0149] A transaction may be an unpublished transaction, which is a transaction that has not yet been submitted to the blockchain network for recording on the blockchain.

[0150] Statement 2. Receiving the payment over the QUIC connection includes: receiving an incoming QUIC handshake message from the second party, the incoming QUIC handshake message including the payee; The method described in statement 1.

[0151] QUIC handshake messages are used to exchange transport parameters and set up the QUIC connection.

[0152] Statement 3. the incoming QUIC handshake message includes a payload field, the payload field including the payee; The method described in statement 2.

[0153] Statement 4. the payload field includes a transaction template, and the transaction is generated based on the transaction template. The method described in statement 3.

[0154] Statement 5. the transaction template includes the payee; The method described in statement 4.

[0155] Statement 6. sending a payee request for the payee to the second party via the QUIC connection; A method according to any one of statements 1 to 5.

[0156] Statement 7. The step of sending the payee request includes: sending an outgoing QUIC handshake message to the second party, the outgoing QUIC handshake message including the payee request; The method according to statement 6, including:

[0157] Statement 8. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including a payment request; The method described in statement 7.

[0158] Statement 9. the outgoing QUIC handshake message includes a payload field, the payload field including a payment request; The method described in statement 7.

[0159] Statement 10. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including an identifier linked to the first party; A method according to any one of statements 7 to 9.

[0160] For example, the identifier may include a CGA, a public key, etc.

[0161] Statement 11. the incoming QUIC handshake message includes a source connection ID field, and sending the transaction to the second party over the QUIC connection includes sending an outgoing QUIC message to the second party, the outgoing QUIC message including: i) a destination connection ID field that corresponds to the source connection ID field of the incoming QUIC handshake message; and ii) a payload field that includes the transaction. A method according to any one of statements 2 to 5.

[0162] Statement 12. Sending the transaction over the QUIC connection comprises: sending an outgoing handshake message to the second party, the outgoing handshake message including the transaction; The method described in statement 2.

[0163] Statement 13. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including the transaction; The method described in statement 12.

[0164] Statement 14. the outgoing QUIC handshake message includes a payload field, the payload field including the transaction; The method described in statement 12.

[0165] Statement 15. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including the payee; 15. A method according to any one of statements 12 to 14.

[0166] Statement 16. the source connection ID of the incoming QUIC handshake includes a transaction template, the transaction template includes the payee, and the transaction is generated based on the transaction template; The method described in statement 15.

[0167] Statement 17. The transaction is an initial transaction for a payment channel, and the method comprises: sending one or more updated versions of the initial transaction to the second party over the QUIC connection, each updated version of the initial transaction being sent using a respective QUIC message. A method according to any one of statements 1 to 16.

[0168] Statement 18. receiving one or more payment update requests from the second party, each payment update request being sent to the first party using a respective QUIC message, and each updated version of the initial transaction being sent to the second party in response to receiving the respective payment update request; The method described in statement 17.

[0169] Statement 19. in response to the QUIC connection being terminated, transmitting the most recent of the one or more updated versions of the initial transaction to one or more blockchain nodes in a blockchain network; The method according to statement 17 or 18, comprising:

[0170] Statement 20. 1. A computer-implemented method for sharing blockchain transactions, the method being performed by a second party, the method comprising: receiving a transaction from a first party over a QUIC connection, the transaction including a payee, the payee including a public key and / or a public key-based address; sending the transaction to one or more blockchain nodes of a blockchain network; A method comprising:

[0171] The payee may be linked to a trusted certificate associated with the second party, such as a certificate including a public key. Alternatively, the payee may be a self-certified address, such as a cryptographically generated address. As another example, the payee may be or be linked to a Payee email address.

[0172] Statement 21. sending the payee to the first party over the QUIC connection; The method according to statement 20, including:

[0173] Statement 22. The step of transmitting the payment over the QUIC connection comprises: sending an outgoing QUIC handshake message to the first party, the outgoing QUIC handshake message including the payee; The method described in statement 21.

[0174] The outgoing QUIC handshake message includes a source connection ID field, which includes an identifier linked to the second party.

[0175] Statement 23. the outgoing QUIC handshake message includes a payload field, the payload field including the payee; The method set forth in statement 22.

[0176] Statement 24. the payload field includes a transaction template, and the transaction is generated based on the transaction template. The method set forth in statement 23.

[0177] Statement 25. the transaction template includes the payee; The method set forth in statement 24.

[0178] Statement 26. receiving a payment request for the payee from the first party via the QUIC connection; 26. A method according to any one of statements 21 to 25.

[0179] Statement 27. The step of receiving a payment request includes: receiving an incoming QUIC handshake message from the first party, the incoming QUIC handshake message including the payment request; The method set forth in statement 26.

[0180] Statement 28. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including the payment request; The method set forth in statement 27.

[0181] Statement 29. the incoming QUIC handshake message includes a payload field, the payload field including the payment request; The method set forth in statement 27.

[0182] Statement 30. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including an identifier linked to the first party; 30. The method according to any one of statements 27 to 29.

[0183] Statement 31. the outgoing QUIC handshake message includes a source connection ID field, and receiving the transaction from the first party over the QUIC connection includes receiving an incoming QUIC message from the first party, the incoming QUIC message including: i) a destination connection ID field corresponding to the source connection ID field of the outgoing QUIC handshake message; and ii) a payload field including the transaction. 31. A method according to any one of statements 22 to 30.

[0184] Statement 32. receiving the transaction over the QUIC connection, receiving an incoming handshake message from the first party, the incoming QUIC handshake message including the transaction; The method set forth in statement 22.

[0185] Statement 33. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including the transaction; The method set forth in statement 32.

[0186] Statement 34. the incoming QUIC handshake message includes a payload field, the payload field including the transaction; The method set forth in statement 32.

[0187] Statement 35. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including the payee; 35. A method according to any one of statements 32 to 34.

[0188] Statement 36. a source connection ID of the outgoing QUIC handshake message includes a transaction template, the transaction template includes the payee, and the transaction is generated based on the transaction template; Statement 35 method.

[0189] Statement 37. The transaction is an initial transaction for a payment channel, and the method comprises: receiving one or more updated versions of the initial transaction from the first party over the QUIC connection, each updated version of the initial transaction being sent using a respective QUIC message; in response to the QUIC connection terminating, transmitting a most recent of the one or more updated versions of the initial transaction to one or more blockchain nodes in a blockchain network; 37. The method according to any one of statements 20 to 36, comprising:

[0190] Statement 38. sending one or more payment update requests to the first party, each payment update request being sent to the first party using a respective QUIC message, and each updated version of the initial transaction being sent to the second party in response to the first party receiving the respective payment update request; The method set forth in statement 37.

[0191] Statement 39. transmitting a respective portion of media content in response to receiving a respective one of the one or more updated versions of the initial transaction; The method according to statement 37 or 38, comprising:

[0192] For example, a payment channel may be used to stream video, where in response to each updated transaction the next portion of the video (eg, 10 minutes) is sent to the first party.

[0193] Statement 40. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when executed on the processing device, to perform the method of any of statements 1 to 39. Computer equipment.

[0194] Statement 41. A computer program embodied on a computer readable storage and configured to, when executed on one or more processors, perform the method according to any of statements 1 to 39.

[0195] According to another aspect disclosed herein, there may be provided a method including first party and second party operations.

[0196] According to another aspect disclosed herein, there may be provided a system including first party and second party computing devices.

Claims

1. 1. A computer-implemented method for sharing blockchain transactions, the method being performed by a first party, the method comprising: receiving an incoming QUIC handshake message from a second party over a QUIC connection, the incoming QUIC handshake message including a payee, the payee including a public key and / or a public key-based address; sending a transaction to the second party over the QUIC connection, the transaction including an output locked to the payee; A method comprising:

2. the incoming QUIC handshake message includes a payload field, the payload field including the payee; The method of claim 1.

3. the payload field includes a transaction template, and the transaction is generated based on the transaction template. The method of claim 2.

4. the transaction template includes the payee; The method of claim 3.

5. sending a payment request for the payee to the second party via the QUIC connection; 5. The method according to any one of claims 1 to 4.

6. The step of sending the payment request comprises: sending an outgoing QUIC handshake message to the second party, the outgoing QUIC handshake message including the payment request; The method of claim 5.

7. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including the payment request; The method of claim 6.

8. the outgoing QUIC handshake message includes a payload field, the payload field including the payment request; The method of claim 6.

9. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including an identifier linked to the first party; 9. The method according to any one of claims 6 to 8.

10. the incoming QUIC handshake message includes a source connection ID field, and sending the transaction to the second party over the QUIC connection includes sending an outgoing QUIC message to the second party, the outgoing QUIC message including: i) a destination connection ID field corresponding to the source connection ID field of the incoming QUIC handshake message; and ii) a payload field including the transaction.

10. The method according to any one of claims 1 to 9.

11. sending the transaction to the second party over the QUIC connection, sending an outgoing QUIC handshake message to the second party, the outgoing QUIC handshake message including the transaction; The method of claim 1.

12. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including the transaction; The method of claim 11.

13. the outgoing QUIC handshake message includes a payload field, the payload field including the transaction; The method of claim 11.

14. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including the payee; 14. A method according to any one of claims 11 to 13.

15. the source connection ID field of the incoming QUIC handshake message includes a transaction template, the transaction template includes the payee, and the transaction is generated based on the transaction template; 15. The method of claim 14.

16. The transaction is an initial transaction for a payment channel, and the method comprises: sending one or more updated versions of the initial transaction to the second party over the QUIC connection, each updated version of the initial transaction being sent using a respective QUIC message.

16. The method of any one of claims 1 to 15.

17. receiving one or more payment update requests from the second party, each payment update request being sent to the first party using a respective QUIC message, and each updated version of the initial transaction being sent to the second party in response to receiving the respective payment update request; 17. The method of claim 16.

18. in response to the QUIC connection being terminated, transmitting the most recent of the one or more updated versions of the initial transaction to one or more blockchain nodes of a blockchain network; 18. The method of claim 16 or claim 17, comprising:

19. 1. A computer-implemented method for sharing blockchain transactions, the method being performed by a second party, the method comprising: sending an outgoing QUIC handshake message to a first party over a QUIC connection, the outgoing QUIC handshake message including a payee; receiving a transaction from the first party over the QUIC connection, the transaction including the payee, the payee including a public key and / or a public key based address; sending the transaction to one or more blockchain nodes of a blockchain network; A method comprising:

20. the outgoing QUIC handshake message includes a payload field, the payload field including the payee; 20. The method of claim 19.

21. the payload field includes a transaction template, and the transaction is generated based on the transaction template.

21. The method of claim 20.

22. the transaction template includes the payee; 22. The method of claim 21.

23. receiving a payment request for the payee from the first party via the QUIC connection; 23. The method of any one of claims 19 to 22.

24. The step of receiving a payment request includes: receiving an incoming QUIC handshake message from the first party, the incoming QUIC handshake message including the payment request; 24. The method of claim 23.

25. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including the payment request; 25. The method of claim 24.

26. the incoming QUIC handshake message includes a payload field, the payload field including the payment request; 25. The method of claim 24.

27. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including an identifier linked to the first party; 27. A method according to any one of claims 24 to 26.

28. the outgoing QUIC handshake message includes a source connection ID field, and receiving the transaction from the first party over the QUIC connection includes receiving an incoming QUIC handshake message from the first party, the incoming QUIC handshake message including: i) a destination connection ID field corresponding to the source connection ID field of the outgoing QUIC handshake message; and ii) a payload field including the transaction.

28. The method of any one of claims 19 to 27.

29. receiving the transaction from the first party over the QUIC connection, receiving an incoming QUIC handshake message from the first party, the incoming QUIC handshake message including the transaction; 20. The method of claim 19.

30. the incoming QUIC handshake message includes a source connection ID field, the source connection ID field including the transaction; 30. The method of claim 29.

31. the incoming QUIC handshake message includes a payload field, the payload field including the transaction; 30. The method of claim 29.

32. the outgoing QUIC handshake message includes a source connection ID field, the source connection ID field including the payee; 32. The method of any one of claims 29 to 31.

33. the source connection ID field of the outgoing QUIC handshake message includes a transaction template, the transaction template includes the payee, and the transaction is generated based on the transaction template.

33. The method of claim 32.

34. The transaction is an initial transaction for a payment channel, and the method comprises: receiving one or more updated versions of the initial transaction from the first party over the QUIC connection, each updated version of the initial transaction being sent using a respective QUIC message; In response to the QUIC connection terminating, transmitting a most recent of the one or more updated versions of the initial transaction to the one or more blockchain nodes of the blockchain network; 34. The method of any of claims 19 to 33, comprising:

35. sending one or more payment update requests to the first party, each payment update request being sent to the first party using a respective QUIC message, and each updated version of the initial transaction being sent to the second party in response to the first party receiving the respective payment update request; 35. The method of claim 34.

36. transmitting a respective portion of media content in response to receiving a respective one of the one or more updated versions of the initial transaction; 36. The method of claim 34 or claim 35, comprising:

37. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when executed on the processing device, to perform a method according to any one of claims 1 to 18. Computer equipment.

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

39. A computer device comprising: a memory including one or more memory units; a processing device including one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to perform a method according to any one of claims 19 to 36 when executed on the processing device. Computer equipment.

40. 37. A computer program embodied on a computer readable storage and configured to perform the method of any of claims 19 to 36 when executed on one or more processors.

Images