Method and system for receiver-facilitated blockchain transactions

Abstract

A system and computer-implemented method for generating a receiver-facilitated blockchain transaction, wherein the receiving device sends a receiver-outpoint to a sending device. The sending device returns a partially completed transaction including the receiver-outpoint as a receiver input to the partially completed transaction and including at least one sender input. The receiving device then adds the receiver-output script as an output to the partially completed transaction, adds the unlock script of the receiver-outpoint using digital signatures across all inputs and outputs to generate a complete transaction, and sends the complete transaction to a blockchain node of the blockchain network for propagation and inclusion in a block.

Description

[Technical field]

[0001] The present disclosure relates to blockchain networks, and more particularly to methods and apparatus for creating and implementing recipient-facilitated blockchain transactions. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which duplicate copies of the blockchain are 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"). Transactions in a blockchain are used to do one or more of the following: carry digital assets (i.e., multiple digital tokens), order a set of journal entries in a virtual ledger or registry, receive and process timestamp entries, and / or time-sequence index pointers.

[0003] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset that can be derived from the preceding transaction sequence. A spendable output is sometimes called an unspent transaction output (UTXO) or “outpoint.” An output may further include a locking script that specifies the conditions for future redemption of the output. 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 coinbase transaction) includes a pointer (i.e., a reference) to such an output in the preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output.

[0004] To make a blockchain network practical for multiple participants, end-user devices may operate client applications (sometimes called "wallets" or Simplified Payment Verification (SPV) software). Such client applications do not have full blockchain node functionality and do not have a full copy of the blockchain.

[0005] Blockchain transactions typically include a transaction fee (and / or "gas" in the case of some protocols) payable to blockchain nodes (e.g., miners) that successfully include the transaction in a properly mined valid block. A typical model is for a sending node to provide sufficient digital assets (e.g., cryptocurrency) as inputs to the transaction, with a portion of the input digital assets being used to pay the transaction fee. A specified amount of the digital assets is assigned or transferred to the receiving node's output script, and the remaining assets are assigned or sent to the sending node's output script as "change." This inverts a typical retail consumer transaction, in that the costs of the monetary transaction, such as credit card fees, are typically borne by the merchant (recipient). This presents a barrier to the adoption and use of blockchain systems for everyday transactions, and may be prohibited by law or regulation in some jurisdictions. However, a merchant / recipient cannot be expected to authorize a prospective consumer device to charge a merchant a transaction fee when constructing the transaction. This is because the receiving node would need to provide the appropriate inputs in unlocked form, essentially a "bearer check." This can impose unexpectedly high transaction fees on the recipient, can be vulnerable to abuse, and can be impractical. It would be advantageous to have a method and system for conducting recipient-facilitated blockchain transactions that addresses at least some of these shortcomings. [Brief description of the drawings]

[0006] By way of example, reference is made to the following accompanying drawings which illustrate exemplary embodiments of the present application:

[0007] [Figure 1] 1 illustrates an exemplary system for implementing a blockchain.

[0008] [Diagram 2] 1 shows an example of a transaction protocol.

[0009] [Figure 3A] 1 illustrates an example implementation of a client application.

[0010] [Figure 3B] 1 illustrates an exemplary user interface of a client application.

[0011] [Figure 4] 1 shows an example of node software for a blockchain node.

[0012] [Diagram 5] 1 illustrates, in flow chart form, one exemplary method implemented at a recipient device for generating a recipient-facilitated blockchain transaction.

[0013] [Figure 6] 1 illustrates, in flow chart form, one exemplary method implemented at a sending device for generating a partially completed blockchain transaction.

[0014] [Figure 7] 1 illustrates, in flow chart form, another exemplary method implemented at a receiving device for generating a receiving-facilitated blockchain transaction.

[0015] [Figure 8] 1 illustrates a simplified exemplary system for holding transactions.

[0016] [Figure 9A] 1 illustrates an exemplary transaction data structure. [Figure 9B] 1 illustrates an exemplary transaction data structure. [Figure 9C]1 illustrates an exemplary transaction data structure. [Figure 9D] 1 illustrates an exemplary transaction data structure. [Figure 9E] 1 illustrates an exemplary transaction data structure. [Figure 9F] 1 illustrates an exemplary transaction data structure.

[0017] Like reference numbers in the figures are used to denote like elements and features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] In one aspect, a computer-implemented method for generating a recipient-facilitated blockchain transaction may be provided, the method comprising: transmitting a receive-out point from the receive device to the sender device; receiving a partially completed transaction from the sending device, the partially completed transaction including the receiving-outpoint as a receiving-input to the partially completed transaction and including at least one sending-input; adding an unlock script for the receiver outpoint using digital signatures across all inputs and outputs to generate a complete transaction; and sending the complete transaction to a blockchain node of a blockchain network for propagation and inclusion in a block.

[0019] In some implementations, the method may include, after receiving the partially completed transaction, determining that the partially completed transaction includes one or more digital signatures applied by the sending device to the at least one sending input and fewer than all outputs. In some cases, the determining step further includes determining that the partially completed transaction does not include signatures across all outputs. The determining step may include determining that the partially completed transaction allows the addition of the receiving output script without invalidating one or more digital signatures applied by the sending device. The determining step may include determining that all signatures applied by the sending device are of type SIGHASH_SINGLE or SIGHASH_NONE. The determining step may include determining that the signatures applied by the sending device are not of type SIGHASH_ALL.

[0020] In some embodiments, the method may further include providing to the sending device maximum conditions for sending inputs and sending outputs associated with the receiving device. The method may include the receiving device determining a number of sending inputs and sending outputs in the partially completed transaction and verifying that the number of sending inputs and sending outputs is not greater than a maximum value established by the maximum conditions. The method may include determining a byte size of a sending input and a sending output in the partially completed transaction and verifying that the number of sending inputs and sending outputs is not greater than a maximum size established by the maximum conditions.

[0021] In another aspect, a computing device for generating recipient-facilitated blockchain transactions may be provided, the computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0022] In some embodiments, transmitting a receiver outpoint from the receiving device to the sending device includes generating and transmitting a transaction template including the receiver outpoint as an input to the transaction template, in some cases the transaction template further includes an output script that references the receiver output address as one output and specifies an amount to be transferred to the one output.

[0023] In some implementations, the method further comprises: determining a transaction fee; determining an excess amount from the difference between a stored amount associated with the receiving outpoint and the transaction fee; specifying the excess amount to the receiving output script; Further includes.

[0024] In some implementations, the method includes, at the sending device, selecting the at least one sending input such that a total amount associated with the at least one sending input is greater than or equal to a transfer amount; appending to the partially completed transaction a digital signature for each sending input, signing each portion of the partially completed transaction that includes fewer than all of the outputs; transmitting the partially completed transaction to the receiving device; generating the partially completed transaction by

[0025] In a further aspect, the present application describes a computing device having a memory, one or more processors, and computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the one or more processors to perform at least one of the methods described herein.

[0026] In yet another aspect, a computer-readable medium may be provided having processor-executable instructions stored thereon that, when executed by one or more processors, cause the processors to perform at least one of the methods described herein.

[0027] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art from a reading of the following detailed description in conjunction with the drawings.

[0028] As used herein, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements.

[0029] As used herein, the term "at least one of ... or ..." is intended to cover all possible combinations and subcombinations of the recited elements, including the recited elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements, and does not necessarily require all of the elements.

[0030] Example System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to the other blockchain nodes 104.

[0031] Each blockchain node 104 includes a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes processing devices implemented by one or more processors, for example, 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 includes one or more memory units using one or more memory media, for example, magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or EEPROMs, and / or optical media such as optical disk drives.

[0032] The blockchain 150 includes a chain of blocks 151 of data, each copy of which is maintained at each of multiple nodes 104 in a distributed or blockchain network 160. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context represents a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies a quantity that represents an amount of the digital asset as an asset. In this example, the outputs are cryptographically locked by a user 103 (requiring that user's signature or other solution to unlock them and thereby redeem or spend them). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0033] Each block 151 also contains a block pointer 155 that points back to a previously created block 151 in the chain to define a sequential order to the blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer to a previous transaction to define an order to the sequence of transactions (Note: sequences of transactions 152 are allowed to branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0034] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 154 is sometimes referred to as a "mempool." This term is not limited herein to any particular blockchain, protocol, or model. It represents an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0035] For a given current transaction 152j, the input (or each of them) includes a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is 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. A previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106, but a previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in a logical sequence linked by pointers, and not necessarily to a time of creation or transmission in the chronological order. Thus, it does not necessarily exclude transactions 152i, 152j from being created or sent out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

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

[0037] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as a user or a machine, wants to act on a new transaction 152j, it sends the new transaction from its computer terminal 102 to a receiver. The entity or receiver eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (these are typically servers or data centers today, but in principle other user terminals are also possible). It is not excluded that in some examples the entity 103 acting on the new transaction 152j may send the transaction to one or more of the blockchain nodes 104 instead of to a receiver. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may include checking that a cryptographic signature or other authentication of entity 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152j that the new transaction assigns, which typically includes at least checking that the cryptographic signature or other authentication in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be at least partially defined by a script included in the output of the previous transaction 152i, or may simply be fixed in the blockchain node protocol, or may be a combination of both.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction 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 node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0038] In the output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated is whether it has already been validly redeemed by an input of another onward 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 allocate or redeem has not yet been allocated / redeemed by another transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Again, because the order of transactions is defined, the account balance has a single defined state at a time.

[0039] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." Blockchain nodes 104 add new transactions to an ordered set 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. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered set 154 of transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and other types are not excluded. A property of a hash function is that it has an output that is unpredictable with respect to the input. Therefore, this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0040] The first blockchain node 104 that solves the puzzle notifies the network 106 and provides the solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the output of the hash satisfies the conditions). The first blockchain node 104 propagates the block to the consensus of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155 to point to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, for example in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0041] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the ordered set of transactions 154 that have not yet been published, depending on when they started looking for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 that will be included in the next new block 151n, in the order in which the current set of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to produce blocks from the newly defined current ordered set of unpublished transactions 154. There is also a protocol to resolve possible "forks", which is when two blockchain nodes 104 solve the puzzle within a very short time of each other and inconsistent views of the blockchain propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0042] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an approved amount of the digital asset in a new special type of transaction that distributes a predetermined amount of the digital asset (different from an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is usually called a "coinbase transaction" but may also be called an "initiation transaction". It forms the first transaction of a standard new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow the protocol rules so that this special transaction can be redeemed later. Blockchain protocol rules may require this special transaction to mature, for example 100 blocks, before it can be redeemed. A normal (non-generating) transaction 152 often specifies an additional transaction fee for one of its outputs to further reward the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is described below.

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

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

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

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

[0047] The computing equipment 102 of each party 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises a memory, i.e., a computer readable storage device 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., a magnetic medium such as a hard disk, an electronic medium such as a SSD, a flash memory or an EEPROM, and / or an optical medium such as an optical disk drive. The memory on the computing equipment 102 of each party 103 stores software, such as a respective instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any action attributed to a party 103 given herein may be performed using software executed on the processing device of each computing equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing device 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.

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

[0049] The client application 105 includes at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 that are propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. 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 amount defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0050] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, it is understood that this is not necessarily limiting and instead any client functionality described herein may be implemented in two or more different suites of applications, interfacing, for example, via an API or one plugging into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. The following is described in terms of a client application 105, but it is understood that this is not limiting.

[0051] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send 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 an embodiment, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust of transactions in part through its public visibility). The wallet function on each computing device 102 is configured to form and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate the transactions 152 according to the blockchain node protocol and to forward the transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0052] When a given party 103, for example Alice, wants 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 relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This may include first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of script and node protocol.

[0053] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the blockchain ordered set 154 maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 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 soon be propagated throughout the network 106.

[0054] Once placed in the ordered set of transactions 154 maintained at a given blockchain node 104, the blockchain nodes 104 begin a race to solve a proof-of-work puzzle for the latest version of their respective ordered sets of transactions, including the new transaction 152 (note that other blockchain nodes 104 attempt to solve the puzzle based on different ordered sets of transactions 154, but whoever is first defines the ordered set of transactions included in the latest block 151). Eventually, the blockchain nodes 104 solve the puzzle for the part of the ordered set 154 that includes Alice's transaction 152j. Once the proof-of-work has been done for the ordered set 154 that includes the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150 in an immutable way. Since each transaction 152 includes a pointer to the previous transaction, the order of the transactions is also immutably recorded.

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

[0056] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In the account-based case, each transaction transfers by referencing an absolute account balance, rather than defining the amount to be transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the successive transaction records (so-called "positions") of the accounts. This value is signed by the senders as part of their cryptographic signatures and hashed as part of the transaction reference calculation. In addition, an optional data field can also sign the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0057] <UTXOベースのモデル> FIG. 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible implementations. It is noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0058] In a UTXO-based model, each transaction ("Tx") 152 is a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. Among other information, the UTXO may also include a transaction ID for the transaction from which it originated. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields 202 and output fields 203. The header 201 may also include an ID for the transaction. In some embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the node 104.

[0059] For example, Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice into the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0060] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least when she sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and sent to the network 106, or Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may be equally replaced by "preceding" and "inheriting" or "ancestor" and "descendant", "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 (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or node behavior.

[0061] One of the one or more outputs 203 of the preceding transaction Tx0 is a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the following transaction for the following transaction to be validated, and thus for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction was locked.

[0062] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies the information needed to consume a transaction output 203, e.g., the requirements of Alice's signature. 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 criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction's inputs 202.

[0063] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx0. Input 202 of Tx1 includes a pointer to Tx0 (e.g., by its transaction ID, TxID0, which in some embodiments is a hash of the entire transaction Tx0). Input 202 of Tx1 includes an index that identifies UTXO0 within Tx0, in order to identify it among any other possible outputs of Tx0. Input 202 of Tx1 further includes an unlock script that contains 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). <SigP A The data (or "message") that Alice needs to sign in order to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0064] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which may involve running the lock script and the unlock script together to check if the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenation of the two scripts.

number

[0065] Here, "||" represents concatenation, "<...>" means to put data on a stack, and "[...]" is the function to be executed by the lock script (in this example, a stack-based language). Equivalently, the scripts may be executed one by one on a common stack rather than concatenating them. Either way, when executed together, the scripts will use Alice's public key P, which is included in the lock script in the output of Tx0. Ais used to authenticate that the unlock script in the input of Tx1 contains Alice's signature, which signs the expected portion of the data. The expected portion of the data (the "message") also needs to be included in order to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus there is no need to include a separate element that specifies the signed portion of the data in plaintext, since the signed portion of the data is already inherently present).

[0066] The details of public-private cryptographic authentication will be well known to those skilled in the art. Essentially, if Alice signs a message with her private key, then another entity, such as node 104, can authenticate that the message must have been signed by Alice, given Alice's public key and the message in plaintext. Signing typically involves hashing the message, signing the hash, and tagging this with the message as the signature, thereby allowing the owner 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 or part of a transaction, etc., can, in embodiments, mean signing a hash of that portion of data or part of a transaction.

[0067] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, 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 the ordered set of transactions 154. The blockchain node 104 forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, which causes it to be broadcast throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines it as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, the blockchain node 104 must also check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0068] If the total amount specified in all of the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction is not propagated and is not included in block 151.

[0069] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" some of the amount defined in the UTXO while another amount is spent. However, an amount from a UTXO can be split into multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split into multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0070] In particular, Alice must also typically include a fee for the Bitcoin node 104 that publishes her transaction. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's blockchain node 104, and thus, although technically valid, it will still not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount indicated 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 publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that publishes the block containing UTXO1. However, nothing in this specification necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0071] Alice and Bob's digital assets consist of the UTXOs that were locked to them in any transaction 152 in the blockchain 150. Thus, typically, the assets of a given party 103 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 the total balance of a given party 103. It is the role of the wallet function in the client application 105 to compile the values ​​of all the various UTXOs that are locked to each party and that have not yet been used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0072] Note that the scripting code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_...." represents a particular opcode in the scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of the locking script, is an opcode in the scripting language to generate an unspent output of the transaction that can store data within the transaction, thereby immutably recording the data to the blockchain 150. For example, the data can include a document that is desired to be stored in the blockchain.

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

[0074] A lock script is sometimes referred to as a "scriptPubKey" to indicate that each transaction typically includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig" to indicate that it typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions under which a UTXO is redeemed include authenticating a signature. More generally, a scripting language may be used to define one or more conditions. Thus, the more general terms "lock script" and "unlock script" are preferred.

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

[0076] The side channel 301 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, such as a mobile cellular network, or a local wireless network, or a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, the side channel 301 referred to anywhere in this specification may include any one or more links over one or more networking technologies or communication media for exchanging data "off-chain", i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, it is noted that when Alice and Bob are said to exchange certain information or pieces of data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be transmitted over exactly the same links or the same type of network.

[0077] Client Software 3A illustrates an example implementation of a client application 105 for implementing an embodiment of the disclosed scheme. The client application 105 may include a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured in accordance with the processes described above to perform the underlying transaction-related functions of the client 105, such as forming transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106.

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

[0079] It should be noted that although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting and may instead be implemented in two or more separate applications, e.g. 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 a separate application from the UI layer 402, or functionality of a given module, and the transaction engine 401 may be split between more than one application. Also, it does not exclude that some or all of the described functionality is implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, etc., it is understood that this is merely an example and, more generally, that the described functionality may be implemented in any form of software.

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

[0081] 3B illustrates a UI 500 from Alice's perspective. The UI 500 includes one or more UI elements 501, 502, 503 that are rendered as separate UI elements via user output means.

[0082] For example, the UI elements may include one or more user selectable elements 501, such as, for example, different buttons on a screen or different options in a menu. The user input means is configured to allow the user 103 (in this case Alice 103a) to select or manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: "manual" as used herein simply means the opposite of automatic and is not necessarily limited to the use of hands).

[0083] Alternatively or additionally, the UI elements may include one or more data entry fields 502. These data entry fields 502 may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or a touch screen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0084] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to a user. For example, the information may be drawn on a screen or rendered audibly.

[0085] For example, this / these may be rendered on the screen or audibly. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 500 shown in FIG. 3B is merely a schematic mockup and may in fact include one or more additional UI elements, which are not shown for simplicity.

[0086] <Node software> FIG. 4 illustrates an example of node software 450 that may be executed by each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx j The protocol engine 451 then identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and search for Tx imay be published on the blockchain 150. In this case, the protocol engine can obtain Txi from a copy of block 151 of the blockchain 150 stored in the node 104. i It is possible that Tx has not yet been published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 held by the node 154. i In either case, the script engine 451 identifies the lock script in the referenced output of Txi and passes it to the script engine 452.

[0087] The script engine 452 therefore i Lock script and Tx j 2, but the same can be applied to any pair of transactions. The script engine 452 executes the two scripts together as described above, which includes placing data on the stack 453 and retrieving data according to the script language (e.g., Script) based on the stack being used.

[0088] By executing the scripts together, the script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output in which the lock script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0089] In the output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, and Tx j the total amount of Digital Assets specified in the Outputs of does not exceed the total amount pointed to by its Inputs; i The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j 455C and / or the propagation module 455P to perform their respective blockchain-related functions as Tx j , which is to control the execution of Tx j and a consensus module 455C that adds Tx j Optionally, in embodiments, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only conditional on both the transaction being validated and having sufficient transaction fees remaining.

[0090] It is noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can represent any state that indicates a successful or positive outcome, and "false" can represent any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (where the overall outcome is considered to convey true if both individual outcomes are true).

[0091] Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon review of this specification, and the scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0092] For example, some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain in any way. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 above may be replaced with 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 above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0093] In some embodiments of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there are 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 functions of propagating and / or storing blocks, but may not generate and publish blocks (recall that these entities are not considered to be suitable Bitcoin network 106 nodes).

[0094] In some other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to represent a network entity that is configured to generate and publish blocks 151, but does not store and / or propagate the blocks 151 to other nodes.

[0095] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such an entity / element may be configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0096] Recipient-Facilitated Transactions As described above, the transfer of digital assets via a blockchain transaction typically involves a sending node constructing a transaction that includes as an input a pointer / address of at least one outpoint from a prior transaction controlled by the sending node. The transaction further includes an output to an output script associated with the receiving device, and possibly a further output to an output script associated with the sending device, and receives excess digital assets from the outpoint above the amount intended to be sent to the receiving output script. The sending device includes at least one digital signature in the transaction as part of providing an unlock script for the outpoint.

[0097] In the present description, the term "output script" may be used to refer to an output to a transaction. The term "output script" may be synonymous with the "lock script" described above. In many cases, an output script may be a pay-to-public-key-hash (P2PKH) operation associated with a public key for which a device holds a private key. The public key (or public key hash) may be referred to as an output address in some contexts, in which case digital assets assigned to that public key hash are considered to belong to that "output address," and the device holding the corresponding private key controls access to those digital assets by its ability to provide the necessary unlock script to utilize or move those digital assets. In some cases, the output script may impose more complex conditions or requirements on access to the digital assets.

[0098] Typically, a sending device that constructs such a transaction may or may not send the transaction directly to a receiving device. In some cases, the sending device may simply send the transaction to the blockchain network for propagation, validation, and inclusion in a block. The receiving device may monitor the blockchain to detect the transaction or may receive a copy directly from the sending device.

[0099] To protect against malicious or invalid changes to a transaction, a sender typically applies at least one digital signature to all inputs and outputs. In the context of the Bitcoin network, this operation can be implemented using the SIGHASH_ALL operation, which generates a digital signature by the sender using the sender's private key and a hash of substantially all data in the transaction, including all inputs and all outputs. This prevents an entity from meaningfully modifying the inputs or outputs of the transaction without invalidating the digital signature. In this sense, the transaction constructed by the sender is a "complete transaction"; that is, it is valid as a complete transaction within the meaning of the blockchain protocol and can be submitted to a Bitcoin node for validation and inclusion in a block.

[0100] To construct a valid complete transaction, the sending device typically identifies one or more controlling outpoints from a preceding transaction such that the aggregated sum of the outpoints is equal to or greater than the transfer amount transferred to the receiving device. For example, if the receiving device is to receive 100 digital tokens, the sending device may identify one or more outpoints from a preceding transaction that, when added together, total up to at least 100 digital tokens. In some examples, a single outpoint with 100 or more digital tokens may be selected. In some other examples, more than one outpoint with 100 or more digital tokens may be selected. The selected outpoint must also have enough tokens to ensure that the transaction fee or other fees or inputs (e.g., gas) are part of the input to the transaction. That is, if the transaction fee is 3 digital tokens, the sending device typically must ensure that the selected outpoint has an aggregate associated value of at least 103 digital tokens to ensure the transaction is included in a block. The amount of transaction fee varies in many blockchain networks. This may change over time depending on network congestion. This may vary depending on the size of the transaction and / or the amount of inputs and outputs within the transaction, in some cases.

[0101] Upon selecting the necessary outpoints to form the inputs to the transaction, the sending device adds an output script associated with the receiving device, specifying the amount to be transferred, e.g., P2PKH, to the receiving device's public key. The amount to be transferred is equal to or less than the sum of the input values ​​minus the transaction fee. The surplus assets can be returned to the sending device by including an output script associated with the sending device and allocating the surplus amount to that output. The sending device then digitally signs the transaction, which includes digitally signing the transaction with at least one SIGHASH_ALL signature that constitutes a signature over at least all inputs and all outputs, preventing any meaningful modification.

[0102] The above transaction generation process does not coincide with a commercial transaction that is not implemented on a blockchain. In most commercial transactions, particularly in the retail context, the receiving party, such as a merchant, incurs costs associated with receiving the transfer of funds or other such assets. As an example, a merchant typically accepts credit card payments for a listed or displayed cost of a product or service (and applicable taxes, if any) and incurs credit card transaction fees as a business expense.

[0103] The above transaction generation process, in which the sending device provides a sufficient amount of digital assets to cover the transaction fee, is a barrier to the adoption of blockchain transactions for commercial transactions, especially retail consumer transactions such as point-of-sale (POS) transactions. Indeed, in many jurisdictions, a transaction in which the consumer is charged a transaction fee may be contrary to law or regulation. It would therefore be advantageous to provide a system or method that allows for receiver-facilitated blockchain transactions, in which the receiving device provides digital assets that are transferred to the mining node as the transaction fee. The challenge is to provide a method and system in which neither the receiving device nor the sending device exposes data that could be exploited to generate a transaction that could allow malicious changes resulting in, for example, a fraudulent digital transfer, such as writing a "bearer check." At the same time, the method and system should aim to simplify and streamline the communication flow.

[0104] In one aspect, the present application provides a system and method for enabling receiver-facilitated blockchain transactions, in which the receiving device provides outpoints from a previous transaction to the sending device, so that the outpoints are included in the constructed partially completed transaction as inputs intended to offset expected transaction fees. The sending device can add one or more inputs and add one or more outputs to receive excess tokens or funds (e.g., as "change") beyond the transfer amount intended to be transferred to the receiving device. The sending device further digitally signs the inputs using at least one digital signature, but no digital signature applies to all outputs. That is, the partially completed transaction generated by the sending device is signed such that it is not possible to modify or add inputs, and it is not possible to modify outputs already present in the partially completed transaction, but it is possible to add one or more outputs. This partially completed transaction is sent to a receiving device, which inserts an output script referencing the address of the receiving device as an output to receive at least the excess from the outpoint of its input, up to an extent greater than the transaction fee of the transaction.

[0105] In another aspect, the present application provides receiver-based control over transaction fees associated with a transaction while still allowing the sending device to generate the transaction by implementing conditions, limits, or maximums on the number of inputs and / or outputs allowed in the transaction. In another implementation, the conditions, limits, or maximums may additionally or alternatively include a maximum transaction size, such as bytes. A partially completed transaction generated by the sending device is evaluated for compliance with the conditions, limits, or maximums by the receiving device. In some cases, these conditions, limits, or maximums may be transmitted to the sending device in the same communication that provides the outpoint for the transaction. In some cases, the conditions, limits, or maximums may be communicated over a separate channel or may be known to the sending device as part of a policy rule set associated with the receiving device. The receiving device may then select the conditions, limits, or maximums that constrain the size of the transaction or the number of inputs and outputs. This allows the maximum transaction fee to be ascertained in advance and an appropriate outpoint with sufficient digital assets may be selected by the receiving device.

[0106] The present application is not limited to blockchain transactions involving retail consumer transactions, such as between a merchant and a customer acquiring goods or services, although that context provides a useful illustrative example referenced below. The present application may also be applied to other contexts. Additionally, the present application may be practiced in contexts involving digital assets or tokens other than cryptocurrencies.

[0107] Referring to FIG. 8, a typical merchant-customer system 800 is shown. The system 800 may include a point-of-sale (POS) device 802 and a customer device 804. The POS device 802 may be a fixed or mobile terminal device used to input the goods or services to be purchased manually or via a scanning device. The POS device 802 may display the total payment amount required for the goods or services and one or more payment methods. In this example, a blockchain payment option may be made available.

[0108] The customer device 802 may include a smartphone, tablet, or other mobile computing device that implements a blockchain wallet application. The customer device 802 may communicate with the POS device 802 using any suitable communication medium and protocol, including Bluetooth™, near-field-communications (NFC), or other short-range communication technologies. Various authentication, verification, and pairing operations may be performed, but are not relevant to this description.

[0109] The POS device 802 in this example may transmit data regarding the potential transaction to the customer device 804. The data may include an outpoint controlled by the POS device 802 having an associated asset value sufficient to offset a maximum transaction fee for the potential transaction. In some embodiments, the POS device 802 may further transmit one or more conditions, maximum values, or upper limits regarding the number of inputs / outputs or transaction size. For example, the POS device 802 may set a maximum number of inputs n, a maximum number of outputs n′, and / or a maximum transaction size N. In some embodiments, the POS device 802 may generate and transmit a transaction template having an outpoint as a specified input with an associated asset value shown as an input for the potential transaction. The outpoint in such a transaction template has not yet been signed by the POS device 802. The transaction template may include a receiving address to which a transfer quantity (e.g., payment amount) is assigned in some examples. When a template includes such an address, the receiving address can receive only the payment amount (i.e., the purchase price paid by the customer device 804) and not any surplus from the outpoint used to cover transaction fees.

[0110] Upon receiving this data, the customer device 804 can select one or more customer outpoints from previous transactions that, collectively, have sufficient aggregate associated value to equal or exceed the transaction payment amount. If a transaction template is not received from the POS device 802, one is generated by the customer device 804 with the outpoints provided by the recipient also added as inputs. The customer device 804 can further add one or more outputs, for example, to receive "change" from the difference between the aggregate value of the customer outpoints used as inputs and the total payment amount sent to the POS device 802.

[0111] The number of inputs and outputs used by the customer device 804 is constrained by a maximum value defined by the POS device 802. In other words, the wallet application on the customer device 804 may select multiple customer outpoints to use as inputs to a transaction, but the number selected may not exceed the maximum number set by the POS device 804. In some implementations, the maximum number of inputs may apply only to customer inputs, while in some other implementations, the maximum number may include both customer inputs and recipient outpoints. Similarly, the number of outputs allowed is constrained by the maximum number of outputs defined by the POS device 804. Alternatively, the POS device 804 may set an aggregate maximum input / output condition that sets a maximum sum of inputs and outputs. These examples and other such restrictions may be collectively referred to herein as a "maximum condition on the number of inputs or outputs." Alternatively or additionally, the overall size of the transaction may be constrained by a defined maximum size, thereby limiting the number of inputs, outputs, or additional excess data in the inputs or outputs, such as OP_RETURN codes.

[0112] For each customer outpoint added to the transaction, the customer device 804 adds a digital signature that allows access to the outpoint, i.e., provides an unlock script. However, the type of digital signature used is one that does not sign all outputs. That is, the customer device 802 uses a class of digital signature (e.g., SIGHASH_SINGLE or SIGHASH_NONE) that applies each digital signature to a hash of a data portion in the transaction that includes all inputs but none of the outputs, or only one of the outputs. In other words, because the class of digital signature used does not sign all outputs, outputs can be added to the transaction later without invalidating the digital signature. Furthermore, inputs cannot be added to the transaction later without invalidating the digital signature.

[0113] It will be appreciated that other exemplary signature classes in the Bitcoin protocol include SIGHASH_ALL|ANYONECANPAY, SIGHASH_SINGLE|ANYONECANPAY, and SIGHASH_NONE|ANYONECANPAY. These types of signatures only apply to a single input, allowing the input to be changed without invalidating the signature.

[0114] The transaction constructed and signed as above is a partially-complete transaction. It is not yet complete in that the receiver has not provided a digital signature validating the input of the receiver-outpoint. Thus, the customer device 804 sends the partially-completed transaction to the POS device 802. The POS device 802 can then verify that the customer signature is valid, or at least of a class of digital signature that avoids signing the entire set of outputs. If the partially-completed transaction complies with the constraints set by the POS device 802, for example, regarding the number of inputs / outputs, and the digital signature from the customer device 804 is valid and not applied to all outputs, the POS device 802 can add a receiver output script (such as a receiver address) as an output, for example, to receive the payment and any excess funds from the receiver-outpoint that are used to fund the transaction fee. In some cases, the transaction may already include a receiver output script to receive the payment, and the receiver can add a second receiver output script to receive any excess funds from the receiver-outpoint that are used to fund the transaction fee.

[0115] The POS device 802 provides a digital signature to the receiving outpoint that is used to fund the payment of the transaction fee. This digital signature may be a class that includes all outputs in the signed message to prevent any changes to the transaction outputs. This may include all inputs and all outputs, such as SIGHASH_ALL. The resulting signed transaction is the complete transaction. The POS device 802 may then send the complete transaction to a blockchain node in the blockchain network 806. There, the complete transaction is verified, propagated, and ultimately confirmed.

[0116] While the above examples relate to point of sale terminals such as those used in traditional retail stores, it will be appreciated that in other contexts the merchant computing device may also be implemented by a mobile device, an online e-commerce platform, a web server, or other such computing device, and that the context of the interaction between the merchant device and the customer device 804 need not be a retail store or involve short-range or near-field communications.

[0117] Referring to FIG. 5, an exemplary method 550 for completing a receiver-facilitated transaction is illustrated in the form of a flow chart. The method 550 may be implemented by a networked computing device. In one example, the computing device may be a point-of-sale device. The method 550 may be implemented by processor-executable instructions that, when executed by the processor, cause the processor to perform the described operations. The operations may include memory access functions, signal or data transmission and reception functions, display operations, and other operations associated with components coupled to the processor. The instructions may be embodied in one or more software modules, applications, routines, and the like. FIG. 5 is described in conjunction with the exemplary transactions illustrated in FIGS. 9A-9F.

[0118] In this example, method 550 assumes that the receiving device and the sending device are in network communication, have completed authentication or handshaking operations, and that a payment amount has been determined. M The receiving device selects and sends to the sending device the outpoint of a previous transaction controlled by the receiving device. The outpoint is a sufficient associated value v that is greater than the expected maximum transaction fee of the transaction. MThe communication to the sending device may further include a payment amount p. In some cases, the payment amount p may have already been provided to the sending device in a previous communication or through another channel. In some cases, the communication further includes one or more upper limits or maximums, such as maximum conditions on the number of inputs and outputs, a maximum number of inputs n, a maximum number of outputs n', and / or a maximum transaction size N. The upper limits or maximums may be selected to ensure that the transaction fee is less than or equal to the maximum transaction fee.

[0119] In one example, a receiving device can send multiple outpoints, each with a corresponding set of conditions, maximums or caps. The sending device can then select one of the outpoints and be constrained in selecting inputs and outputs to the transaction based on the maximum value associated with that outpoint. Incentives can be implemented to bias the sending device to select a lower maximum value (and thus a lower transaction fee for the receiving device), for example, by associating it with a lower payment amount or by providing associated loyalty points, vouchers, etc.

[0120] Operation 552 may, in some implementations, include generating a transaction template and transmitting the outpoint within the template. Whether generated by the sending device or generated and transmitted by the receiving device, the initial transaction template may have an example format shown in FIG. 9A. M The receiving outpoint has an associated value of M Note that is shown as one of the inputs to the transaction.

[0121] 6, an example method 600 for generating a partially completed transaction is shown. The method 600 may be performed by a sending device, which may be a computing device such as customer device 804 (FIG. 8). At operation 602, the sending device receives an outpoint identifier from a receiving device. As noted above, the receiving device may optionally receive an outpoint, M , and related v M In some cases, a transaction template such as that shown in Figure 9A may be sent.

[0122] The sending device may then determine the transfer amount, e.g., the payment amount, if applicable, and one or more maximums or limits, in operation 604. In this sense, the sending device is not "setting" a maximum or limit, but is identifying or determining a maximum or limit already set by the receiving device. As described above, the receiving device may send the maximum value to the sending device. In some cases, the maximum value may be pre-set by a policy rule or other issued notification on the receiving device. In some cases, the maximum value may be specified during an authentication or handshake process between the sending device and the receiving device. The payment amount p may be specified during communication from the receiving device in some cases. The payment amount may be specified in the transaction template by inserting the receiving address as an output and assigning the payment amount p to that output (not shown in FIG. 9A).

[0123] In operation 606, the sending device selects one or more sending addresses, i.e., sending outpoints (e.g., UTXOs) from a previous transaction, that together have a value at least as large as the transfer amount (e.g., payment amount). The sending device constructs the transaction by adding the selected sending outpoints as inputs to the transaction in operation 608. The set of sending inputs added to the transaction is called the outpoint iS where index i ranges from 0 to a maximum of n. In some cases, the sending device may have one input: outpoint0 S Nonetheless, for purposes of illustration, FIG. 9B shows a transaction structure with a maximum number of inputs ranging from index 0 to index n-1. i S Each of v i S The arithmetic unit has an associated value denoted as

[0124] In operation 608, the sending device calculates the sum of the input values, e.g., Σ i S One or more sender output scripts [P j S ] can be added, where P j S denotes the jth key processed by the sender. In the edge case, the sum of the input values ​​exactly matches the payment amount, and no sender output is added. One or more sender output scripts can be specified, and each script is assigned an allocation value c specified in the transaction to be assigned to its address (i.e., the sender public key). j S The index j can range from 0 to a maximum number n′−1. In most cases, the sending device will have a single output script P0 for receiving the transfer of surplus assets from the input. S Note that the sending device is likely to provide a maximum of Σc. However, the wallet application on the sending device may be configured to preferentially allocate funds to addresses in smaller quantities or denominations, resulting in the wallet inserting multiple output scripts to receive excess funds (e.g., change). Figure 9B shows an example where the sending device includes the maximum number of output scripts. The sum of the values ​​allocated to the sending outputs, Σc i Sis the sum of the input values ​​Σv i S minus the payment p.

[0125] In operation 610, the sending device applies at least one digital signature. In this example, each sending input has an associated digital signature to unlock its UTXO. Note that the digital signature applied by the sending device is of a type that does not sign all outputs, as shown in the column labeled "Unlocking script." For example, Sig0 S An operation denoted as ||SINGLE signs inputs and a single output that have the same index value. n-1 S An operation denoted as ||NONE signs only the input and not the output. In one implementation, the sender device signs the sender output script P i S If the sender has an input, then any of the sender inputs (e.g., outpoint i S ) with SIGHASH_SINGLE. If there is no sender output script corresponding to that index i, the sender uses SIGHASH_NONE.

[0126] Figure 9C uses shading to indicate Sig0 S Figure 9D shows the part of the transaction that is included in the message signed by ||SINGLE. Note that the signed message includes some header metadata, all the inputs, and one output with the same index i=0. Figure 9D uses shading to show that Sig n-1 S||NONE indicates the parts of the transaction that are included in the signed message. Note that the signed message includes some header metadata and all inputs, but not outputs. Different blockchain protocols may include different parts of the header metadata in the digital signature process.

[0127] A transaction is "partially complete" when the sending input of the transaction has been digitally signed by the sending device. M Note that the partially completed transaction has not yet been signed by the receiving device and therefore has not yet been unlocked. Thus, the transaction is not yet valid from the perspective of the blockchain protocol. The partially completed transaction is sent from the sending device to the receiving device at operation 612. Although this description illustrates the partially completed transaction as being in a particular format or template, the partially completed transaction sent to the receiving device may include data in a different format or order, from which the receiving device rearranges the data into an appropriately compliant transaction format and / or order.

[0128] Referring again to FIG. 5, at operation 554, the sending device receives the partially completed transaction constructed by the sending device. Then, at operation 556, it verifies that the inputs have been digitally signed by the sending device. Most implementations can verify the signature (rather than relying on the blockchain node to reject the transaction if it is not valid). It can verify that the type of digital signature used is of a class that allows the receiving node to add outputs to the transaction without invalidating the signature. In the context of Bitcoin, this includes verifying that the sender's digital signature type is not SIGHASH_ALL or SIGHASH_ALL|ANYONECANPAY, or that each sender's digital signature type is SIGHASH_SINGLE or SIGHASH_NONE.

[0129] The receiving device can determine the transaction fee f of the transaction based on the number of inputs and outputs, and therefore the receiving device’s input outpoint M The value of v M The extent to which x exceeds the transaction fee f can be evaluated, and therefore the amount of excess assets to be returned to the receiving device can be determined.

[0130] If the transaction is correctly signed and formed, then in operation 558 the receiving node may add an output script to the partially completed transaction. The output script added will contain the value of its input v in addition to the payment amount p. M outpoint to the extent that exceeds the available transaction fee f M In another implementation, the receiving device may have one or more output scripts designated to receive a payment amount p, and v M -f. In some implementations, a payment address may have been provided to the sending device and may already exist in a partially completed transaction. The receiving device then determines the transaction fee f based on the number of inputs and outputs, and accepts the excess v. M -f allows you to include one or more output scripts to store.

[0131] After adding one or more output scripts, if any, the receiving device adds an unlock script to the receiving input, i.e., outpoint M Provides a digital signature using the private key associated with the . The digital signature is applied to the message text, including all inputs and outputs to the transaction, thereby preventing further modifications to the transaction. In the Bitcoin context, this is a SIGHASH_ALL operation.

[0132] FIG. 9E shows the output script P M The value assigned to the output script is the sum of the payment amount p and the receiving input v M and the transaction fee f. Also shown is the SIGHASH_ALL digital signature operation in the receiver input unlock script. Figure 9F shows the Sig M ||ALL The portions of the transaction that form the message signed by the digital signature operation are shaded. Note that the message text includes the header metadata and all inputs and outputs.

[0133] Once the transaction is digitally signed at operation 560, it becomes a complete transaction, and at operation 562, the receiving device sends the transaction to one or more blockchain nodes in the blockchain network for validation, propagation, and verification.

[0134] The foregoing examples and diagrams provide methods and systems that maintain the general communication flow of an SPV payment, including messages from the merchant device to the customer device and return messages from the customer device to the merchant device. Nevertheless, by providing an unsigned merchant / recipient input-out point, the recipient device can supply digital assets for the transaction fee, but maintain control over transaction growth and the size of the transaction fee by controlling the insertion of a final output address to receive any excess funds not consumed by the transaction fee, and applying a final digital signature to its input to complete and validate the transaction.

[0135] As mentioned above, a challenge with providing a receiving input large enough to cover the transaction fee is that freely providing that input may enable abuse and waste by the sending device by adding excess inputs and outputs. The receiving device may impose conditions, caps or maximums on the number of inputs and outputs to control the maximum transaction fee, enable pre-selection of appropriate receiving inputs to cover the fee, and prevent transaction bloat.

[0136] Referring to FIG. 7, another exemplary method 700 of completing a recipient-facilitated transaction is illustrated in flow chart form. Method 700 may be implemented by a networked computing device. In one example, the computing device may be a point-of-sale device. Method 700 may be implemented by processor-executable instructions that, when executed by a processor, cause the processor to perform the described operations. The operations may include memory access functions, signal or data transmission and reception functions, display operations, and other operations associated with components coupled to the processor. The instructions may be embodied in one or more software modules, applications, routines, and the like.

[0137] In operation 702, the receiving device can determine the transfer amount, e.g., the amount of digital assets received from the sending device. Next, in operation 704, the transfer amount, the outpoint identifier used as the receiving-side input for the transaction, and one or more input and output upper limit parameters or conditions can be sent to the sending device. As an example, the receiving device can send the maximum number of inputs n and the maximum number of outputs n'. These maximum values can each specify the maximum number of inputs and outputs that the sending device can add to the transaction. In one example, the receiving device can send a single maximum value that is the maximum total count of inputs and outputs that the sending device can add to the transaction. In another example, the maximum condition can take the form of a*n + b*n' < K, where a and b are the byte sizes of the P2PKH unlock and lock script, respectively, and K is the maximum value selected by the receiving device, whereby the sending device can select n and n' to satisfy the maximum condition. In yet another example, the maximum condition can take the form of A + B < K, where A and B are the total byte sizes of the sets of sending-side inputs and sending-side outputs, respectively, and K is the maximum value set by the receiving device. As described above, in some implementations, the receiving device can set a set of maximum values corresponding to different maximum transaction fees, and the sending device can select from the set of maximum values.

[0138] In operation 706, the receiving device receives a partially completed transaction from the sending device. The partially completed transaction includes a receiving-side outpoint as one of the inputs and at least one sending-side input. If the value of the sending-side input exceeds the transfer amount, it can further include one or more sending-side outputs for receiving the excess funds. The sending-side input includes an unlock script that includes a digital signature for the input. The digital signature does not sign all the outputs.

[0139] In this example, in operation 708, the receiving device evaluates whether the number of transmitting-side inputs within the transaction exceeds the maximum number of inputs n. If it does, the receiving device rejects the transaction in operation 710. This may include transmitting a notification of the rejected transaction to the transmitting device. The notification may include an indication of the reason for the failure, such as an excessive input exceeding the maximum allowable value. Either or both of the receiving device and the transmitting device may display or output a notification to the user indicating that the transaction failed because it did not comply with the conditions. In some cases, the receiving device and the transmitting device may resume transaction generation to correct the problem.

[0140] In operation 712, the receiving device determines whether the number of transmitting-side outputs exceeds the maximum number of outputs. If it does, the transaction is rejected in operation 710.

[0141] It will be understood that operations 708 and 712 can be modified for different formulated conditions. For example, as described above, if the maximum condition is in the form of a*n + b*n' < K, the receiving device sums the byte sizes of the inputs and outputs and determines whether the value is less than K.

[0142] In operation 714, the receiving device determines whether the digital signature applied to the sending input is of a type or class that digitally signs messages that include all inputs but not all outputs. In the context of Bitcoin, this includes verifying that digital signatures applied to sending inputs that do not have a sending output at a corresponding index are SIGHASH_NONE operations, and that digital signatures applied to sending inputs that have a sending output corresponding to the same index are SIGHASH_SINGLE operations. It may also include verifying that the digital signature operation is not a SIGHASH_ALL operation. In some cases, operation 714 further includes verifying the digital signature. Generally, operation 714 includes determining that adding an output to the transaction does not invalidate the digital signature applied by the sending device. If the digital signature does not comply, the transaction is rejected at operation 710.

[0143] Assuming the transaction satisfies the tests of operations 708, 712, and 714, then in operation 716 the receiving device calculates the value of the receiving input v M Add an output script to receive the remaining amount until f exceeds the transaction fee f. In some cases, the same output address can be used to receive the transferred amount. In some cases, a second receiving output script can be added to receive the transferred amount. In some implementations, a receiving output script may already be present in the partially completed transaction to receive the transferred amount.

[0144] At operation 718, the receiving device digitally signs the receiving inputs using a digital signature that signs all inputs and outputs. In the context of Bitcoin, this is a SIGHASH_ALL operation. This digital signature therefore locks the inputs and outputs in place so that they cannot be changed without invalidating the signature and transaction. The complete transaction can then be sent to a blockchain node for validation, propagation and final confirmation at operation 720.

[0145] The various embodiments described above are merely examples and are not meant to limit the scope of the present application. Various innovations described herein will be apparent to those skilled in the art, as will variations within the intended scope of the present application. In particular, features from one or more of the exemplary embodiments described above may be selected to generate alternative exemplary embodiments, including combinations of features not explicitly shown above. Furthermore, features from one or more of the exemplary embodiments described above may be selected and combined to generate alternative exemplary embodiments, including combinations of features not explicitly shown above. Features suitable for such combinations and combinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described in the present specification and claims covers and encompasses all appropriate technical modifications.

Claims

1. 1. A computer-implemented method for generating a recipient-facilitated blockchain transaction, the method comprising: transmitting a receive-out point from the receive device to the sender device; receiving, at the receiving device, a partially completed transaction from the sending device, the partially completed transaction including the receiving-outpoint as a receiving-input to the partially completed transaction and including at least one sending-input; determining that the partially completed transaction includes one or more digital signatures applied by the sending device to the at least one sending input and fewer than all outputs; adding a recipient output script as an output to the partially completed transaction; adding an unlock script for the receiver outpoint using digital signatures across all inputs and outputs to generate a complete transaction; transmitting the complete transaction from the receiving device to a blockchain node of a blockchain network for propagation and inclusion in a block; The method includes:

2. 2. The method of claim 1, further comprising determining that the partially completed transaction does not include a signature across all outputs.

3. 2. The method of claim 1 , wherein determining that the partially completed transaction includes one or more digital signatures applied by the sending device to the at least one sending input and less than all outputs comprises determining that the partially completed transaction allows for the addition of the receiving output script without invalidating the one or more digital signatures applied by the sending device.

4. 2. The method of claim 1 , wherein determining that the partially completed transaction includes one or more digital signatures applied by the sending device to the at least one sending input and fewer than all outputs comprises determining that all signatures applied by the sending device are of type SIGHASH_SINGLE or SIGHASH_NONE.

5. The method of claim 1 , wherein determining comprises determining that the signature applied by the sending device is not of type SIGHASH_ALL.

6. 2. The method of claim 1, further comprising the step of the receiving device providing to the sending device maximum conditions regarding a sending input and a sending output.

7. 7. The method of claim 6, further comprising the step of the receiving device determining a number of sending inputs and sending outputs in the partially completed transaction and verifying that the number of sending inputs and sending outputs is not greater than a maximum value established by the maximum condition.

8. 7. The method of claim 6, further comprising the step of determining a byte size of a sending input and a sending output in the partially completed transaction and verifying that the byte size is not greater than a maximum size established by the maximum condition.

9. 2. The method of claim 1, wherein transmitting the receive-out point from the receiving device to the sending device comprises generating and transmitting a transaction template that includes the receive-out point as an input to the transaction template.

10. 10. The method of claim 9, wherein the transaction template further includes an output script that references a recipient output address as one output and specifies an amount to be transferred to the one output.

11. In the receiving device, determining a transaction fee; determining an excess amount from the difference between a stored amount associated with the receiving outpoint and the transaction fee; specifying the excess amount to the receiving output script; The method of claim 1 further comprising:

12. In the transmitting device, selecting the at least one sending input such that a total amount associated with the at least one sending input is greater than or equal to a transfer amount; appending to the partially completed transaction a digital signature for each sending input, signing each portion of the partially completed transaction that includes fewer than all of the outputs; transmitting the partially completed transaction to the receiving device; 2. The method of claim 1, further comprising generating the partially completed transaction by:

13. 1. A computing device comprising: one or more processors; Memory, computer-executable instructions stored in said memory, which, when executed by said one or more processors, cause said processors to perform a method according to any one of claims 1 to 12; 2. A computing device comprising:

14. The computing device of claim 13 , wherein the computing device comprises a point of sale terminal.

15. A computer readable medium storing processor executable instructions, the processor executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform a method according to any one of claims 1 to 12.

Images