JP7646570B2 - Suitability of transactions for inclusion in the blockchain - Google Patents

Description

This disclosure relates to the phenomenon of malleability in the context of blockchain, i.e. the ability to change certain unsigned parts of a transaction without invalidating the transaction.

Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction may point to the previous transaction in the sequence. Transactions can be contributed to the network and included in new blocks through a process known as "mining." "Mining" involves each of multiple mining nodes competing to perform a "proof-of-work," i.e., solving a cryptographic puzzle based on the pool of pending transactions waiting to be included in a block.

Traditionally, transactions in a blockchain are used to transfer digital assets, i.e. data that acts as a store of value. However, blockchains can also be used to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow additional user data to be stored in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing more complex data to be incorporated. For example, this could be used to store electronic documents, or audio or video data, within the blockchain.

Each node in the network can have any one, two, or all three roles: forwarding, mining, and storage. Each forwarding node propagates (valid) transactions to one or more other nodes, thus propagating transactions among themselves through the nodes of the network. Each mining node competes to mine transactions into blocks. Each storage node stores their own copy of the mined block of the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes of the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor mined into blocks. Assuming the transaction is verified and thereby accepted into the blockchain, the additional user data therefore remains stored in each node of the P2P network as an immutable public record.

Miners who successfully solve the proof-of-work puzzle to generate an updated block are typically rewarded with a transaction called a "generation transaction" that generates a new amount of the digital asset. The transaction may also optionally specify an additional mining fee for successful miners. Proof-of-work encourages miners not to cheat the system by including double-spending transactions in their blocks, because it requires a significant amount of computational resources to mine a block, and because blocks containing double-spending attempts may not be accepted by other nodes.
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, sometimes called a UTXO (for “unspent transaction output”), that specifies an amount of a digital asset. The output may further include a locking script that specifies a condition for redeeming the output. Each input includes a pointer to such an output in a prior transaction and may further include an unlocking script for unlocking the locking script of the pointed-to output. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that includes a locking script that specifies an amount of a digital asset and defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

In such a model, when a second target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the conditions for validity applied at each node is that the unlock script meets the requirements defined in the lock script of the first transaction. Another condition for the target transaction to be valid is that the output of the first transaction has not yet been redeemed by another valid transaction. Any node that finds the target transaction to be invalid according to any of these conditions will not propagate it or mine it for inclusion in a block for recording in the blockchain.

For example, a target transaction is to carry an amount of a digital asset from a first party ("Alice") to a second party ("Bob"). One of the requirements defined in the locking script of the preceding first transaction is, typically, that the unlocking script of the target transaction includes Alice's cryptographic signature. The signature must be generated by Alice signing a portion of the target transaction. Which portion this is may be flexibly defined by the unlocking script, or may be an inherent feature of the node protocol, depending on the protocol used. However, the portion to be signed typically excludes certain other portions of the target transaction, such as some or all of the unlocking script itself.

This creates the possibility of "malleability", i.e. parts of the target transaction that were not signed prior to mining can be changed ("malleated") without invalidating the transaction. Malleability is a known concept in cryptography. It is usually known as a security concern, whereby a message can be maliciously altered and still be accepted as authentic. In the context of blockchain, malleability is not necessarily a concern, but is simply known as a strange artifact, whereby certain parts of a transaction can be changed without invalidating the transaction.

Recently, a proposal has been made to judiciously exploit this flexibility in order to use transactions as carriers of media data. The data content can be included in the unlock script of a transaction, which is then sent between the parties via a side channel called the "payment channel". One of the parties then malleates the transaction to remove the data and sends the modified version towards the P2P network to be mined (while if the data had not been removed, the transaction would have bloated the blockchain and typically also required higher mining fees, since the reward required by miners to accept the transaction typically scales with the data size of the transaction).

The present disclosure recognizes further ways in which adaptability, or more generally updatability, can be utilized as a positive feature. In particular, it is known that a first transaction of a pair of transactions may include several different unlock conditions in its lock script. Conventionally, only one version of the target transaction has ever been created to redeem the output of the first transaction based on one condition or the other. However, it is now recognized that it is useful to actually have two versions: a first version of the target transaction with an unlock script that redeems the first transaction based on a first one of the conditions, and a second version that redeems the first transaction based on a second one of the conditions. The second updated version can be created by modifying the first version or by creating a fresh version from scratch. They can exist in parallel or one after the other. Although both versions cannot effectively redeem the first transaction, the existence of the first version can serve as a "backup" for Bob in case the circumstances required to satisfy the second condition are not met.

According to one aspect disclosed herein, there is provided a method for recording a target transaction between a first party and a second party on a blockchain, the method comprising:
obtaining a second updated version of the target transaction, the second updated version being updated relative to an existing first version of the target transaction;
and sending the updated version of the target transaction in place of the first version to be propagated through a network of nodes and recorded in a copy of the blockchain maintained at each of at least some of the nodes.
The target transaction includes an unlock script and a pointer to a first output of a first transaction, the first output including a lock script specifying a number of alternative conditions for unlocking the first output of the first transaction, the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script of the updated version is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition.

For each of a plurality of transactions including the target transaction, at least some nodes of the network are configured to propagate each transaction provided that the transaction is valid, and at least some nodes are configured to record each transaction in the node's copy of the blockchain provided that the transaction is valid, the validity of the target transaction being conditioned on the unlock script unlocking the output of the first transaction according to any one of the conditions, but whereby when one of the versions is validated at any given node, the other version is considered invalid at the node.

Therefore, the second party ("Bob") does not submit both versions to be propagated and recorded on the blockchain, since neither version can validly redeem the first transaction. He submits the second version to be propagated and recorded as his preference, but the fact that the first version existed gives him a fall-back to have the first version recorded if the necessary circumstances for the second version were not met.

For example, in a first exemplary use case, a first transaction ("Tx ₁ ") includes a payment from a first party ("Alice") for a service to be provided by a second party ("Bob"). The first transaction may be generated by Alice, Bob, or a third party. It may already be on-chain or may be submitted to be recorded there later. Either way, a locking script in the output of the first transaction specifies at least two alternative conditions for unlocking the payment defined in the output, a first condition and a second condition. The first condition does not require Alice's signature to be included in the unlocking script of the target transaction, but imposes some other onerous requirements on Bob, such as that the unlocking script include a large predefined piece of data (which may incur high mining fees) or a piece of Bob's confidential or secret data (which Bob does not want to expose on the blockchain). The second condition requires Alice's signature to be included in the unlocking script of the target transaction, but does not impose the onerous requirement of the first condition.

Alice also provides Bob with a first version of the target transaction ("Tx _p "), or Bob generates it himself (or it is generated by a third party). The first version is configured to unlock the output of the first transaction Tx ₁ under a first condition, while the second version ("Tx _p '") is configured to unlock it under a second condition. Bob then provides the service. If Alice is happy and honest, in response, she provides Bob with the second version of the target transaction Tx _p ', including her signature (or provides at least her signature to Bob or a third party to construct the second version). However, if Alice breaks the agreement, Bob has the option of sending the existing, less favorable first version Tx _p to redeem the output of the first transaction under the less favorable first condition.

In a second exemplary use case, the method includes, by the second party's computing device:
streaming a sequence of data portions to the first party, terminating with a final portion in the sequence;
receiving a respective instance of the first transaction from the first party in response to a respective one of the data portions, a first output of each instance specifying a payment to the second party for the respective portion;
wherein the payment increases with each data portion. In such an embodiment, obtaining the updated version of the target transaction includes receiving an updated version from a first party following a final portion in the sequence.

For example, each data portion may be a different portion of an item of media content (e.g., audio and/or video content). Alternatively, each data portion is a different key to access a unit of service (e.g., a consumer service such as gas, water, electricity, or the rental of a vehicle, property, or other physical object).

For example, the first transaction instances ( _Tx1 , _Tx2 , _Tx3 , ...) may be recognized by each node of the network as substantially the same transaction instance, because the first output has the same output identifier (e.g., UTXO identifier) in each instance. Thus, only one instance can be recorded in the blockchain. Once one instance is accepted as valid by any given node, any attempt to record a further version is considered invalid and thus rejected by the node. Furthermore, once any given node knows that one of the first transaction instances is validly redeemed by one of the target transaction versions ( _Txp or _Txp '), any further target transaction that attempts to redeem any instance of the first transaction is considered invalid by that node and thus will not be propagated by that node and will not be recorded in the blockchain.

Since any version of the target transaction (Tx _p or Tx _p ') points to the same output ID of the same instance of the first transaction (which simply defines a different amount), only one target transaction can validly redeem the output. Once any given node knows that one of the instances of the first transaction (Tx ₁ , Tx ₂ , Tx ₃ , ...) is validly redeemed by one of the versions of the target transaction (Tx _p or Tx p '), any further target transaction that attempts to redeem any instance of the first transaction will be considered invalid and will therefore not be propagated by the node and recorded in the blockchain. However, since the payment in each instance also grows with each piece of data exchanged, all the second party ("Bob") has to do is to send a version of the target transaction Tx _p ' that redeems the last or most recent instance Tx _n of the first transaction, to be propagated and recorded in the blockchain. He then receives a full payment for every piece of data sent before that point, based on a single pair of transactions. If the first party ("Alice") instead sent a separate individual payment for each separate portion of data (e.g., each packet or chunk of audio or video content), Bob would have to send a separate transaction for each data portion, which would bloat the blockchain and result in more network traffic.

If at any point, prior to the end of the sequence, Alice stops sending instances of the first transaction ( _Tx1 , _Tx2 , _Tx3 , ...), Bob still has the option to stop sending further data portions to Alice and send the first version of the target transaction _Txp to the network in order to redeem the payment for the data portion sent before that point (thus losing only the most recent data portion sent). Conversely, if at any point, Bob stops sending data portions, Alice has the option to stop sending further instances of the first transaction _Tx1 and Bob will only have the ability to redeem the payment for the data portion received by Alice up to that point.

In a particularly optional implementation, the first transaction may include one or more first inputs specifying an input amount, the first output of the first transaction may specify a first payment, and the first transaction may further include one or more further outputs specifying one or more further payments. As a result, the sum of the payments is higher than the input amount, and the first transaction received by the second party from the first party has no other inputs that generate a difference. The nodes of the network reject the first transaction as invalid if the first transaction specifies a total payment that is greater than the total input amount. In such an embodiment, the method includes the second party adding a second input to the last or most recent instance of the first transaction to make up the difference, and sending the first transaction with the added second input to be propagated through the network and recorded in the blockchain.

In this exemplary implementation, the further outputs include a second output specifying a second payment to the first party equal to the input amount minus the first payment, and a third output specifying a third payment to the second party equal to the second payment.

Such an embodiment would prevent a first party ("Alice") from cheating the system by submitting her own target transaction to redeem one of the earlier instances, and thus prevent Bob from redeeming one of the later instances (or indeed any of the instances). By doing so, Alice would have to add an extra input that would cost her much of her digital assets. Thus, there is no value in Alice trying to cheat the system.

In another example use case, each of at least some of the alternative conditions may correspond to a different option for voting;
The method may include, prior to obtaining the updated version of the target transaction, marking the unlock script in the first version as accessible or accessible by a third party as a non-binding indication of voting intent, where if the voting indication is not actually converted into a vote, the first version remains as a public indication of how the vote differed from the final voting outcome.

According to further aspects disclosed herein, a program for performing the method and/or a second party computer device programmed to perform the method is provided. The program or computer device may be configured to allow the second party to selectively transmit either the first or second version to be propagated through the network and recorded in the blockchain by providing a manual option to select either version and/or by an automated function configured to automatically transmit the first version upon a first event and further configured to automatically transmit the second version upon a second event to be propagated and recorded instead of the second version.

To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:
FIG. 1 is a schematic block diagram of a system for implementing a blockchain. 1 shows a schematic of some examples of transactions that may be recorded on a blockchain. FIG. 1 is a schematic block diagram of another system for implementing a blockchain. FIG. 2 is a schematic block diagram of a client application. 5 is a schematic, simulated representation of an exemplary user interface presented by the client application of FIG. 4; FIG. 2 is a schematic diagram of a set of transactions. 1 is a flow chart of a method for streaming data. 8 is a graph illustrating input and output values for an instance of a first transaction in an exemplary implementation of the method of FIG. 7; FIG. 1 is a signaling diagram illustrating a voting method. FIG. 1 is a signaling diagram illustrating a voting method. 11 illustrates an exemplary set of transactions implementing the method of FIG. 10 .

Malleability is an existing concept in cryptography. It usually underpins a security concern whereby a message can be maliciously altered and still be accepted as authentic. Digital signature schemes are designed to address this concern. In blockchain, however, malleability represents the ability to modify at least parts of a transaction without invalidating the transaction as a whole. Any information in a transaction that is signed with a related form of cryptographic signature (e.g., an ECDSA signature) is not subject to the possibility of malleation. Any claimability concerns related to malleability are instead caused by improper implementations, not the protocol itself.

The following are exploited as useful features to achieve a fast and secure trustless payment channel. The idea is to identify one or more parts in a transaction that are not or do not need to be signed (e.g., with an ECDSA signature). The disclosed scheme exploits the fact that any content in the unlock script (e.g., the "scriptSig" field) of each input of a transaction is not signed with any signature. Embodiments may also exploit the SIGHASH flag to allow flexibility in modifying a transaction without invalidating it.

An example is as follows: When exchanging data on a blockchain, one common method is to use a hash puzzle to force the disclosure of the data and the acceptance of payment to occur simultaneously. To avoid this, transactions can be constructed such that payment can be demanded by one of two conditions: (i) providing "data + Bob's signature" or (ii) providing "Alice's signature + Bob's signature".

Bob constructs a transaction to claim funds by providing the data and his signature, and sends it to Alice. Alice then replaces the data with her signature and broadcasts the transaction to the network. Alternatively, Bob obtains Alice's signature, replaces the data with it, and broadcasts it to the network. Either way, since the data is not part of the message signed by Bob's signature, replacing it with Alice's signature does not invalidate the transaction. Furthermore, the transaction remains valid when the inputs satisfy condition (ii). If Alice does not broadcast the transaction to the network and does not provide her signature, Bob still has the option to broadcast the original transaction to claim funds under condition (i) (which is less preferred since he would have to upload a significant amount of and/or unique data). Alice may be incentivized to provide her signature by a requirement to be affirmed, an incentive of a discount, or by rewarding Bob for a service well performed.

<System Overview>
FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 includes 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 nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computing device with different nodes 104 belonging to different peers. Each node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application specific processors, and/or field programmable gate arrays (FPGAs). Each node also includes a memory, i.e., a computer readable storage device in the form of one or more non-transitory computer readable media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or EEPROMs, and/or optical media such as optical disk drives.

Blockchain 150 refers to a chain of blocks 151 of data, with a respective copy of blockchain 150 maintained at each of multiple nodes in a peer-to-peer (P2P) network 160. Each block 151 in the chain contains one or more transactions 152, where transaction in this context refers to 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 typically 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 an amount that represents the quantity of a digital asset belonging to the user for which that output is cryptographically locked (requiring the signature of that user 103 to be unlocked and thereby redeemed or used). Each input points back to the output of the preceding transaction 152, thereby linking the transactions.

At least some of the nodes 104 take on the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 take on the role of miners 104M, which mine blocks 151. At least some of the nodes 104 take on the role of storage nodes 104S (also called "full-copy" nodes), with each node storing a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

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, and specifies that this output is redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106, but the previous transaction 152i must exist and be verified in order for the current transaction to be concluded. Thus, "preceding" in this specification refers to something that precedes in a logical sequence linked by a pointer, 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 transmitted 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.

The input of the current transaction 152j also includes the signature of the user 103a to which the output of the previous transaction 152i is locked. The output of the current transaction 152j can also be cryptographically locked to the new user 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs and split the input amount among multiple users (one of which is the original user to make the change). In some cases, a transaction may have multiple inputs and pool amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

The above is sometimes called an "output-based" transaction protocol, and sometimes also called an "unspent transaction output (UTXO) type protocol" (where the outputs are called UTXOs). A user's total balance is not defined by a single number stored in the blockchain, instead, the user needs a special "wallet" application 105 to collate the values of all of the user's UTXOs, which are distributed across many different transactions 152 in the blockchain 151.

As part of the account-based transaction model, another type of transaction protocol is sometimes called an "account-based" protocol. With account-based, each transaction transfers by referencing absolute account balances, rather than defining the amount to be transferred by referencing back to the UTXOs of previous transactions in the past series of transactions. The current state of all accounts is stored and constantly updated by miners separate from the blockchain. This disclosure is directed to an output-based model rather than an account-based one.

In both types of transaction protocols, when a user 103 wants to execute a new transaction 152j, he sends the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently usually a server or a data center, but in principle it could be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied to each node 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 in question and together form an overall transaction model. The node protocol typically requires the 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 output-based case, this may include checking that the cryptographic signature of the user 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 consumes, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, the condition may be defined, at least in part, by a custom script included in the input and/or output. Alternatively, it may be fixed solely in the node protocol, or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards the new transaction to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol and forwarding the new transaction 152j to one or more further nodes 104, etc. In this way, the new transaction is propagated throughout the network of nodes 104.

In an output-based model, the definition of whether a given output (e.g., a UTXO) is spent is whether it has already been validly redeemed by an input of another onward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of a preceding transaction 152i that it attempts to spend or redeem has not yet been consumed/redeemed by another valid transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded on the blockchain. This prevents double-spending, where a payer attempts to spend the same transaction's output multiple times.

In addition to validating, at least some of the nodes 104M compete to be the first to create a block of transactions in a process called mining, which is backed by a "proof of work". At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. This typically involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 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. A property of a hash function is that it has an output that is unpredictable with respect to the input. This search can therefore only be performed by brute force and therefore consumes a significant amount of processing resources at each node 104M trying to solve the puzzle.

The first miner node 104M to solve the puzzle announces this to the network 106 and provides its solution as a proof. This solution can be easily checked by other nodes 104 in the network (given the solution for the hash, it is easy to verify that the hash output satisfies the conditions). The winner's pool of puzzle-solving transactions 154 is recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's published solution at each node. The new block 151n is also assigned a block pointer 155, which points to the previously created block 151n-1 in the chain. The proof-of-work helps to reduce the risk of double spending, since it takes a lot of effort to create a new block 151, and blocks containing double spending are likely to be rejected by other nodes 104, thus providing an incentive for mining nodes 104M not to include double spending in their blocks. Once created, blocks 151 cannot be altered because they are known and maintained at each storage node 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose an order on blocks 151. This provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

Note that different miners 104M, who are constantly competing to solve the puzzle, may be solving the puzzle based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started looking for a solution. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, and the current unmined transaction pool 154 is updated. Miners 104M then continue to compete to produce blocks from the newly defined unsolved pool 154. There is also a protocol to resolve possible "forks", which are cases when two miners 104M solve the puzzle within a very short time of each other and inconsistent views of the blockchain propagate. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150.

In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of nothing (a normal transaction transfers an amount of digital assets from one user to another). The winning node is therefore said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generation" transaction; it automatically forms part of a new block 151n. This reward gives miners 104M an incentive to participate in proof-of-work competitions. Often, normal (non-generation) transactions specify an additional transaction fee in one of their outputs to further reward the winning miner 104M who generated the block 151n in which the transaction was included.

Due to the computational resources involved in mining, typically at least each of the miner nodes 104M takes the form of a server including one or more physical server units, or an entire data center. Each forwarding node 104M and/or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 may include a user terminal or a group of user terminals networked together.

The memory of each node 104 stores software configured to run on the processing unit of the node 104 to perform one or more of its respective roles and to process transactions 152 in accordance with the node protocol. It will be understood that any operation attributed to a node 104 may be performed by software executing on the processing unit of the respective computing device. Additionally, the term "blockchain" as used herein is a general term referring to a general type of technology and is not limited to any particular proprietary blockchain, protocol or service.

Also connected to the network 101 are computing devices 102 of each of a number of parties 103 acting as consumer users. These play the role of payer and payee in a transaction, but do not necessarily participate in mining or propagating the transaction on behalf of the other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computing device 102a, and a second party 103b and its respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 may exist and participate in the system, 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 is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and that references herein to Alice or Bob may be substituted with "first party" and "second party", respectively.

Each party's 103 computing equipment 102 comprises a respective processing device comprising one or more processors, for example one or more CPUs, GPUs, other accelerator processors, application specific processors, and/or FPGAs. Each party's 103 computing equipment 102 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, for example, a magnetic medium such as a hard disk, an electronic medium such as an SSD, a flash memory or an EEPROM, and/or an optical medium such as an optical disk drive. The memory on each party's 103 computing equipment 102 stores software including a respective instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any operation belonging to a given node 104 may be performed by using software executed on the processing device of the respective computing equipment 102. Each party's 103 computing equipment 102 comprises at least one user terminal, for example 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 network-connected resources, such as cloud computing resources accessed via a user terminal.

The client application or software 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.

The client application 105 has at least a "wallet" functionality. It has two main functions. One of these is to allow each user party 103 to create, sign and send transactions 152 that are propagated throughout the network of 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 matching an amount defined among the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

An instance of the client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet function of the client 105 to transmit the transaction 152 to the network 106. The client 105 can also contact one, some, or all of the storage 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 transmit the transaction 152 according to a transaction protocol. Each node 104 executes software configured to validate the transaction 152 according to the node protocol and, in the case of the forwarding node 104F, forward the transaction 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol implements a given transaction model together with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although a transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 in the network 106 (although many nodes process different transaction subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

As mentioned above, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 that points back to a previously created block 151 in the chain, so as to define a sequential order to the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 includes a pointer to a previous transaction, so as to define an order to the sequence of transactions (note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the 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, but not to a preceding transaction.

When a given party 103, for example Alice, wants to send 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. Then, from the client application 105, she sends the transaction 152 to one of one or more forwarding nodes 104F to which she is connected. For example, this may be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes 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 on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "valid"), any storage node 104S that receives the transaction 152j adds the newly validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained by that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the P2P network 106.

Once in the pool 154 in the copy of the blockchain 150 maintained by one or more storage nodes 104, the miner nodes 104M start competing to solve the proof-of-work puzzle of the latest version of the pool 154 that contains the new transaction 152 (other miners 104M are still trying to solve the puzzle based on their old view of the pool 154, but whoever gets there will first define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j). Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer to the previous transaction, the order of the transactions is also immutably recorded.

Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of the 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.

In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may 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 specifies an amount of a digital asset (a store of value). It includes, among other information, the transaction ID of 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 an embodiment, the transaction ID is a hash of the transaction data (minus the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the miner 104M.

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 "Tx ₁ ". It takes the amount of the digital asset locked to Alice into the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx ₀ " in FIG. 2. Tx0 and Tx1 are merely 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 of the previous (i.e., ancestor) transactions that still have a locked unspent output 203 to Alice.

The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 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 102, 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 (such as which transaction points to which other transaction) specified in the transaction. They may equally be replaced by "predecessor" and "inheritor" or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily mean the order in which they are created, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") will not be validated unless the parent transaction is validated. A child that arrives at 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 miner behavior.

One of the one or more outputs 203 of the preceding transaction Tx0 includes 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 the unlocking script in the input 202 of the following transaction for the following transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks an 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.

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" (Script, capital S). The lock script specifies the information needed to consume the transaction output 203, e.g., the requirements of Alice's signature. The unlock script appears in the transaction's output. The 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. The unlock script appears in the transaction's inputs 202.

In the illustrated example, UTXO ₀ in output 203 of Tx ₀ includes a lock script, [ChecksigP _A ], which requires Alice's signature, SigP _A , in order for UTXO ₀ to be redeemed (or more precisely, for a subsequent transaction that attempts to redeem UTXO ₀ to be valid). [ChecksigPA] includes the public key, PA, from Alice's public/private key pair. Input 202 of Tx ₁ includes a pointer to Tx ₁ (e.g., by its transaction ID, TxID ₀ , which in an embodiment is a hash of the entire transaction, Tx ₀ ). Input 202 of Tx ₁ includes an index that identifies UTXO ₀ within Tx ₀ , in order to identify it among any other possible outputs of Tx _0. Input 202 of Tx 1 further includes an unlock script, <SigPA>, which includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a given portion of data (sometimes called a "message" in cryptography). 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.

ここで、「||」は連結を表し、「<...>」はスタックにデータを配置することを意味し、「[...]」はアンロックスクリプトに含まれる機能である（本例では、スタックベースの言語）。同等に、スクリプトは。、スクリプトを連結するのではなく共通のスタックにより１つずつ実行されてよい。いずれの方法でも、一緒に実行する場合、スクリプトは、Tx_０のアウトプット内のロックスクリプトに含まれるAliceの公開鍵P_Aを使用して、Tx_１のインプット内のロックスクリプトが、データの期待部分に署名するAliceの署名を含むことを認証する。また、データの期待部分(「メッセージ」)も、この認証を実行するためにTx０に含まれる必要がある。実施形態において、署名されたデータは、Tx０の全体を含む(従って、別個の要素は、データの署名された部分がすでに本質的に存在するので、データの署名された部分の指定にクリアに含まれる必要がある)。 When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenation of the two scripts.

where "||" denotes concatenation, "<...>" means to place data on a stack, and "[...]" is a function included in the unlock script (a stack-based language in this example). Equivalently, the scripts may be executed one by one with a common stack rather than concatenating them. Either way, when executed together, the scripts use Alice's public key P _A included in the lock script in the output of Tx ₀ to authenticate that the lock script in the input of Tx ₁ contains Alice's signature signing the expected portion of the data. The expected portion of the data (the "message") must also be included in Tx 0 to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx 0 (so a separate element needs to be included explicitly in the specification of the signed portion of the data since the signed portion of the data is already inherently present).

The details of authentication using public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then with Alice's public key and the message in the clear (unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signatures typically allow the holder of the public key to authenticate the signature by hashing the message, signing the hash, and tagging this as the signature on a clear version of the message. Thus, in embodiments, references to signing a particular piece of data or portion of a transaction, etc., may mean signing a hash of the piece of data or portion of the transaction.

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 node 104 considers Tx1 valid. If it is a storage node 104S, this means adding it to the pool 154 of transactions waiting for proof-of-work. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106, which causes it to be propagated throughout the network. 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, 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 blockchain 150 to impose a defined order on transactions 152. In practice, a given 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 blockchain 150.

Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" an amount defined in a 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 UTXO 0 in Tx0 can be split into multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO 0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

In practice, Alice usually needs to include a fee for the winning miner as well, because today the reward for the generating transaction alone is usually not enough to motivate mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and therefore, although technically valid, it will still not be propagated and included in the blockchain 150 (the miner's protocol does not force the miner 104M to accept the transaction 152 if the miner does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the winning miner 104. For example, suppose that 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 automatically goes to the winning miner 104M. However, nothing in this document necessarily precludes that a miner's fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

Note that if the total amount specified in all of a given transaction's 152 outputs 203 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 will not be propagated or mined into a block 151.

The digital assets of Alice and Bob consist of the unspent UTXOs 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. No single number is 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 aggregate the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the storage nodes 104S, for example, the storage node 104S that is closest to or best connected to each party's computer device 02.

Note that script codes are often expressed generally (i.e., not in a precise language). For example, one might write [Checksig P _A ] to mean [Checksig _{P A} ] = OP_DUPOP_HASH 160 <H(P _A )> OP_EQUALVERIFYOP_CHECKSIG. "OP_...." represents a specific opcode in the script language. OP_CHECKSIG (also called "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, all occurrences of the signature ("si"') are removed from the script, but additional requirements such as the hash puzzle remain for the transaction to be verified by the "sig" input. As another example, OP_RETURN is a script language opcode for generating an unspent output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata to the blockchain 150. For example, the metadata may include documents that are desired to be stored on the blockchain.

The signature PA is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In an embodiment, 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 4-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

The lock script is sometimes referred to as a "scriptPubKey" to denote that the respective transaction includes the public key of the party being locked. The unlock script is sometimes referred to as a "scriptSig" to denote that it provides the 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.

Figure 3 shows a system 100 for implementing a blockchain 150. The system 100 is substantially the same as described in connection with Figure 1, except that an additional communication function is included. The client applications present on each of Alice's and Bob's computing devices 102a, 102b, respectively, include the additional communication function. That is, it allows Alice 103a to establish (at the invitation of either party or a third party) a separate side channel 301 with Bob 103b. The side channel 301 allows for the exchange of data separately from the P2P network. Such communication is sometimes referred to as "off-chain". For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being published (yet) to the network P2P 106 or on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Such a side channel 301 is sometimes used, for example, as a "payment channel".

The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay 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 P2P overlay 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 described as exchanging 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.

Illustrative Definitions
Below are some example definitions that may be employed in some implementations. Note that these are not intended to limit all possible implementations, but are provided only to aid in understanding certain possible implementations that may be utilized in some possible implementations of the example use cases described below.

Definition 1: Transaction. A transaction is a message that contains inputs and outputs. It may also contain a protocol version number and/or a locktime. The protocol version indicates the version of the transaction protocol. The locktime is explained separately later.

Definition 2: The inputs of an input transaction form an ordered list. Each entry in the list contains an output (an identifier for an unspent transaction output) and a scriptSig (the unlock script). It may also contain a sequence number.

Definition 3: Outputs: The outputs of a transaction form an ordered list. Each entry in the list contains a value (the amount of the digital asset in that base unit) and a scriptPubKey (the locking script).

Definition 4: Outpoint. An outpoint is uniquely defined by a transaction ID TxID and an index number i. It represents the i-th entry in the output of a transaction output TxID and gives a unique location of an unspent transaction output (UTXO). The term "unspent" is used herein to mean that the outpoint does not appear in any valid subsequent transaction.

Definition 5: scriptSig. This is the information required to unlock or spend the UTXO corresponding to a given outpoint. In a standard transaction, this information is usually an ECDSA signature; hence the script is called the "scriptSig". However, the information required to unlock an outpoint can be any data that satisfies the locking conditions of the UTXO.

Definition 6: scriptPubKey. This is the script that locks the funds associated with a particular UTXO. A scriptSig is appended to the scriptPubKey, and the funds are unlocked and can be spent if and only if execution of the combined script yields true. Otherwise, the transaction is invalid and is rejected. This is called a "scriptPubKey" because in standard transactions it usually contains a hash of the ECDSA public key.

In the following definitions, reference is made to signing an input or output, which means signing one or more inputs excluding the scriptSig part (see definition 2).

Definition 7: SIGHASH Flags. When providing an ECDSA signature, one of the following SIGHASH flags MUST also be included:

When discussing adaptability as a feature, we look for information in a transaction that is not signed with an ECDSA signature. Apart from inputs and outputs that can be excluded from the message to be signed, the contents of the scriptSig are always excluded. This is because the scriptSig is designed to be a placeholder for the signature.

Definition 8: Blockchain Timelocks. In general, there are two types of timelocks that can be used within a transaction: absolute timelocks and relative timelocks. Absolute timelocks specify a specific point in time after which something is considered "valid", while relative timelocks specify a period of time that must pass before something is considered valid. In both cases, block height (number of blocks mined) or elapsed time (e.g. UNIX time) can be used as a proxy for time when using blockchain timelocks.

Another characteristic of blockchain timelocks is where they appear and the aspect of the transaction to which they are applied. Again, there are two classifications of timelocks in this sense: transaction level, which lock the entire transaction, and script level, which lock specific outputs. Both of these timelocks can be used to implement either absolute or relative timelocks. The table below summarizes four possible mechanisms to implement timelocks that can be generated based on these characteristics.

Definition 9: nLocktime. nLocktime is a non-negative integer that represents a block-high or a specific time in UNIX time. It is a transaction-level time lock, in the sense that a transaction can only be added to the blockchain in a specified block or after a specified time. If nLocktime is set to less than 500,000,000, it is considered a block-high. If it is set to 500,000,000 or greater, it is considered a representation of UNIX time. It is the number of seconds after 00:00:00 on January 1, 1970.

For example, if the current block height is 3,000,000 high and the lock time is set to 4,000,000, the transaction will not be considered by miners until the 4 millionth block is mined.

Definition 10: nSequence. The sequence number (nSequence) indicates the version of the transaction as a message. Any change to the transaction increments the sequence number by one. The maximum value of nSequence is 2 ³² −1, and the sequence number is usually set to this maximum value by default to indicate that the transaction is complete. An nSequence value is defined for each input of a transaction and specifies the time period after the UTXO referenced by the input is included in a block before it becomes available as a valid input. When a miner sees two transactions with the same input, the miner chooses the transaction with the higher sequence number. However, this feature is commonly disabled.

Definition 11: CheckLockTimeVerify (OP_CLTV). The opcode OP_CHECKLOCKTIMEVERIFY (OP_CLTV) is an absolute script-level timelock that can be used to lock a specific output of a transaction to some specific time or block height in the future. If the current UNIX time or block height at which the UTXO is referenced in the transaction exceeds the UNIX time or block height at which the UTXO was created plus the parameter specified before the OP_CLTV opcode, script execution for the payment transaction will fail.

Definition 12: CheckSequenceVerify (OP_CSV). The opcode OP_CHECKSEQUENCEVERIFY (OP_CSV) is a relative script-level timelock that can be used to lock a particular output of a transaction for a particular time period or number of blocks in the future. It works similarly to OP_CLTV, except that the parameter provided to OP_CSV represents a relative time. If the current UNIX time or block height at which the UTXO is referenced in the transaction exceeds the UNIX time or block height at which the UTXO was created plus the parameter specified before the OP_CSV opcode, script execution for the payment transaction will fail.

Definition 13: Malleability. In general, there are two broad definitions of malleability possible in blockchain transactions. They both allow the contents of a transaction to be changed without invalidating the signatures provided in the inputs.

To illustrate both cases, consider an initial transaction Tx with one input, one signature on that input, and one output.

Type 1: Script-level adaptability. This type of adaptability exploits the fact that the signature to be checked by the script opcode OP_CHECKSIG does not sign the script fields of any inputs in the transaction. This fact allows one to generate a signature for transaction Tx and modify the input script so that transaction Tx' is not identical to Tx, but still allows both Tx' and Tx to be considered valid transaction messages signed by the same signature under blockchain consensus rules.

Type 2: Input and output level adaptability. This type of adaptability relies on the use of SIGHASH flags other than SIGHASH ALL being used within a transaction. If a transaction Tx has an input signature that uses any of the five other SIGHASH flag combinations, then either the input(s) or the output(s) can be added to produce a non-identical transaction Tx'. As a result, both parties agree on what is considered a valid transaction message without the need to change the signature.

Adaptability as a characteristic

4 illustrates an exemplary implementation of a client application 105 for implementing an embodiment of the disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as forming a transaction 152, receiving and/or sending transactions and/or other data via a side channel 301, and/or sending a transaction to be propagated through the P2P network 106, according to the scheme described above and as discussed in detail below. According to an embodiment disclosed herein, the transaction engine 401 of at least Bob's client 105b includes an application functionality 403 in the form of a selection function, which allows for a selection as to which of two or more different versions of a target transaction ("Tx _p " and "Tx _p '") should be sent from Bob's respective computing device 102 to be propagated through the P2P network 106 for validation and thus recorded in the blockchain 150 (the propagation and recording themselves being performed by the mechanisms described above). Again, this transmission may include transmitting the target transaction directly from Bob's computing device 102b to one of the forwarding nodes 104F of the network 106, or transmitting the target transaction to a third party device to be forwarded to Alice's device 102b or to one of the nodes 104F of the network 106.

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) providing visual output, one or more speakers providing audio output, and/or one or more haptic output devices providing haptic output, etc. The user input means may include, for example, one or more touchscreen 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 speech or voice recognition algorithms to receive speech or audio input, one or more gesture-based input devices to receive input in the form of manual or physical gestures, or one or more mechanical buttons, switches, or joysticks, etc.

Note: Although various functions may be described herein as being integrated into the same client application 105, this is not necessarily limiting and instead they may be implemented in two or more different suites of applications, e.g. one plugging into the other. For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or in the functionality of a given module, 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 may be 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 that more generally the described functionality may be implemented in any form of software.

5 provides a simulated representation of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105 on Bob's device 102b. The user interface 500 includes at least two user-selectable options 501, 502. These may be rendered as two different UI elements by a user output means, such as two on-screen buttons or two different options in a menu. The user input means is configured to allow the user 103b (Bob in this case) to select one of the options by clicking or touching an on-screen UI element or by speaking the name of the desired option (note: "manual" as used herein simply means the opposite of automatic and is not limited to the use of hands). It will be understood that the particular means of rendering and selecting the options is not important.

Whatever means are used, each of the options corresponds to a different one of the first and second target transactions Tx _p and Tx _p '. The selection function 403 is configured to interface with the UI layer 402 to enable the following: if Bob 103b selects the first option 501, this causes the transaction engine 403 to send the first version of the target transaction Tx _{p to be propagated through the network 106 and recorded in the blockchain 150; however, if Bob 103b selects the second option 403, this causes the transaction engine 403 to send the first version of the target transaction Tx p '} to be propagated through the network 106 and recorded in the blockchain 150.

It will be understood that the UI 500 shown in FIG. 5 is merely a schematic mock-up and that in practice it may include one or more additional UI elements that are not shown for the sake of brevity.

As an alternative or in addition to UI options 501, 502, the selection function 403 may be configured to perform an automatic selection between the transmission of the first and second versions Tx _p or Tx _p ′ of the target transaction for recording in the blockchain 150. This may be triggered automatically depending on a predefined event or after a predefined timeout. For example, if an event Y occurs before the timeout, the function 403 automatically transmits the second version Tx _p ′ to be propagated through the network 150. However, if the timeout has elapsed before the event Y occurs, the function 403 automatically transmits the first version Tx _p instead. Alternatively, if an event X occurs, the function 403 automatically transmits the first version Tx _p to be propagated through the network 150. However, if an event Y occurs, the function 403 automatically transmits the second version Tx _p ′ instead. In principle, the circumstances for automatically sending the first and second versions to the network 150 can be configured by the system designer to be virtually anything.

6 shows a set of transactions 152 for use in accordance with the embodiments disclosed herein. The set includes a zeroth transaction Tx ₀ , a first transaction Tx ₁ , and a second transaction Tx _p /Tx _p ′. Note that these names are merely labels for convenience. They do not necessarily mean that these transactions are immediately placed one by one in block 151 or blockchain 150, or that the zeroth transaction is the first transaction in block 151 or blockchain 150. Also, these labels do not imply anything about the order in which these transactions are sent to the network 106. They simply represent a logical series in which the output of one transaction is pointed to by the input of the next transaction. Recall that in some systems, it is possible for a parent to be sent to the network 106 after its children (in this case, the “orphaned” child is buffered in one or more nodes 104 for a period of time, waiting for its parent to arrive).

Two transactions Tx _p or Tx _p ′ are said to be (effectively) versions of the same transaction if they both contain an input that references the same output (e.g., the same UTXO) of the first transaction. Different versions may provide different functionality by satisfying different unlock conditions of that output. Different versions may also both contain the same input signature (i.e., the signed message in every instance is the same). Some embodiments described below may also contain different instances Tx _i (where i=1, 2, 3, ...) of the first transaction. Two (or more) transactions are said here to be (effectively) instances of the same first transaction if they both contain an input that references the same output (e.g., UTXO) Tx ₀ of the same source transaction (or the "zeroth" transaction). They may redeem the input based on satisfying the same unlock condition. They may, however, contain different input signatures (i.e., the signed message in every instance is not the same). Different instances may specify payments for different respective data portions and incremental amounts of digital assets, but provide substantially the same functionality, as will be described in more detail below with reference to Figures 7-9 and exemplary use case 2.

The zeroth transaction _Tx0 may be referred to as a source transaction for the purposes of the present invention, and serves as a source of the amount of locked digital assets to Alice 103a. The first transaction _Tx1 may be referred to as an intermediate or conditional transaction for the purposes of the present invention, and serves as an intermediary that conditionally transfers an amount of digital assets from the source transaction _Tx0 . The second transaction _Txp / _Txp ' may be referred to as a target or payment transaction (herein subscripted "P"), and is the transaction that unlocks one of the conditions and provides a payment to Bob (or, in some cases, a beneficiary represented by Bob). As mentioned above, the target transaction has two versions, a first version _Txp and a second version _Txp '. These transactions each exist and are manifested at least at some point in time on either Alice's (first party) computer device 102a or Bob's (second party) computer device 102b, or on a third party computer device (not shown), or any combination thereof. The two versions Tx _p and Tx _p ' may exist together in parallel for a period of time, or one after the other, or partially overlapping in time.

As shown in FIG. 6, source transaction _Tx0 further includes at least one output ₂₀₃₀ (e.g., output ₀ of Tx0) that specifies an amount of digital assets, and a lock script that locks this output to Alice 103a. This means that the lock script of source transaction _Tx0 requires that at least one condition be met. This condition is that an input of any transaction that seeks to unlock the output (and thus redeem the amount of digital assets) must include Alice's cryptographic signature (i.e., using Alice's public key) in its unlock script. In this sense, the amount defined in the output of _Tx0 is said to be owned by Alice. The output may be referred to as a UTXO. It is not particularly important for the purposes of the present invention which previous transaction's outputs point to the input of _Tx0 (as long as they are sufficient to cover the total output of _Tx0 ).

In the present case, the transaction that unlocks the output of source transaction Tx ₀ is the first or intermediate transaction Tx _1. Thus, Tx ₁ has at least one input 202 1 (e.g., input 0 of Tx ₁ ) that further includes an unlock script requiring at least Alice's signature, which includes a pointer to the relevant output of Tx ₀ (output ₀ of Tx ₀ in the illustrated example) and is configured to unlock the pointed output of Tx ₀ according to the conditions defined in the lock script of that output. The signature from Alice required by the lock script of Tx ₀ is required to sign a specific portion of Tx _1. In some protocols, the portion of Tx ₁ that needs to be signed may be a setting defined in the unlock script of Tx _1. For example, this may be set by a SIGHASH flag, which is a byte that is appended to the signature. So, in data terms, the unlock script is:<Sig P _A ><sighashflag><P _A >Alternatively, the part of that needs to be signed may simply be a fixed part of _Tx1 . Either way, the part to be signed may typically exclude the unlock script itself, and some or all of the input of _Tx1 . This means that the input of _Tx1 is adaptive.

The first or intermediate transaction _Tx1 has at least one output ₂₀₃₁ (e.g., output ₀ of Tx1, where the output may again be referred to as a UTXO). The output of intermediate transaction _Tx1 is not unconditionally locked to any one party. Like _Tx0 , it has at least one output (e.g., output 0 of _Tx1 ) that specifies the amount of digital assets to be transferred. The output further includes a locking script that defines what is required to unlock the output, and thus redeem the amount. However, this locking script allows the output to be unlocked based on any one of several different possible conditions, including at least (i) a first condition ("Condition 1") and (ii) a second condition ("Condition 2").

The second, target transaction Tx _p /Tx _p ' has at least one input 202p (e.g., input 0 of Tx _p /Tx _p ') that includes a pointer to the aforementioned output of Tx ₁ (output 0 of Tx ₁ in the illustrated example) and further includes an unlock script configured to unlock the output of Tx ₁ based on satisfying one of a number of alternative conditions defined in the lock script of Tx _1. In the first version of the target transaction Tx _p , the lock script is configured to satisfy a first condition, condition 1. At some point, a second version of the target transaction Tx _p ' is also generated. In the second version, the unlock script is configured to satisfy a second condition, condition 2.

The second, target transaction Tx _p /Tx _p ' has at least one output 202p (e.g., output 0 of Tx _p /Tx _p ') that, in any version, specifies the amount of the digital asset to be transferred to Bob and a lock script that locks it to Bob (i.e., this requires that further, future transactions include Bob's signature in the unlock script in order to use it). In this sense, the output of target transaction Tx _p /Tx _p ' is said to be owned by Bob. This output may again be referred to as a UTXO.

In an embodiment, the first condition requires that the unlock script of the transaction attempting to unlock Tx ₁ , in this case the first version of the target transaction Tx _p , includes in its unlock script a cryptographic signature of Bob and/or a data payload, which may be Bob's data that Bob must provide or include. The requirement to include a data payload can be imposed by a hash challenge included in the lock script of Tx ₁ . The challenge includes a hash of the data (not the data itself) and a piece of script that (when executed on node 104 together with the unlock script) is configured to test whether the hash of the data provided in the corresponding unlock script is equal to the hash value provided in the lock script. The requirement on the signature is imposed, for example, by CheckSig as described above. In an embodiment, the first condition does not require that Alice's signature be included in the unlock script of Tx _p . The parts of Tx _p that need to be signed by Bob may be a setting in the unlock script of Tx _p (e.g., specified by a SIGHASH flag) or may be fixed. Either way, at least excluding the unlock script. Therefore, the unlock script for Tx _p is adaptive.

In an embodiment, the second condition requires that the unlock script of the transaction attempting to unlock _Tx1 , in this case the second version of the target transaction _Txp ', includes both Bob's cryptographic signature and Alice's cryptographic signature in its unlock script. Again, this is imposed, for example, by CheckSig. In an embodiment, the first condition does not require that the data payload be included in _Txp 's unlock script. The portions of _Txp ' that need to be signed by Alice and Bob may be a setting in _Txp 's unlock script (e.g., specified by a SIGHASH flag) or may be fixed.

The zeroth (or source) transaction Tx ₀ may be generated by Alice, Bob, or a third party. It typically requires a signature from the preceding party from whom Alice obtained a defined amount in the input of Tx _0. It may be sent to the network 106 by Alice, Bob, the preceding party, or another third party.

The first (i.e. intermediate, conditional) transaction _Tx1 may also be generated by Alice, Bob, or a third party. In an embodiment, it may be generated by Alice, since it requires Alice's signature. Alternatively, it may be generated by Bob or a third party as a template and then sent to Alice for signing, e.g., sent via side channel 301. Alice can then send the signed transaction to network 106 herself, or send it to Bob or a third party to forward them to network 106, or simply send her signature to Bob or a third party to compose into signed _Tx1 and forward to network 106. Again, any off-chain exchanges prior to sending _Tx1 to network 106 may be performed via side channel 301.

Either version of the second (i.e., target or payment) transaction Tx _p /Tx _p ′ may be generated by Alice, Bob, or a third party. The first version may be generated by Bob, since it requires Bob's signature and/or data. Alternatively, it may be generated as a template by Alice or a third party and then sent to Bob to sign and add data, e.g., sent to Bob via side channel 301. Bob can then send the signed transaction to the network 106 himself, or send it to Alice or a third party and forward them to the network 106, or simply send his signature to Alice or a third party to compose it into a signed Tx _p and forward it to the network. In an embodiment, the second version requires the signatures of both Bob and Alice. Therefore, it may be generated as a template by Alice or Bob and sent to the other as a template to add their signatures, e.g., again via side channel 301. Alternatively, it may be generated as a template by a third party and then sent to Alice. Here, Alice may add her signature and forward it to Bob for Bob to add his signature. Bob then forwards the signed transaction to the network 106 or sends it back to Alice or a third party for them to forward to the network 106. Alternatively, Tx _p ′ may be generated by a third party as a template and then sent to Bob. Here, Bob adds his signature and forwards it to Alice for Alice to add her signature. Alice then forwards the signed transaction to the network 106 or sends it back to Bob or a third party for them to forward to the network 106. In a further variation, Alice and/or Bob sign the received transaction template and return their signature to one of the other parties, which composes it into Tx _p ′ and forwards it to the network 106. Again, any off-chain exchanges prior to sending Tx _p and/or Tx _p ′ to the network 106 may be performed via side channel 301.

It is understood that there are various locations where different elements of a transaction may be generated and configured, and various ways in which they may be transmitted, directly or indirectly, to their ultimate destination in the P2P network 106. The scope of implementation of the disclosed technology is not limited in any of these respects.

Phrases such as "by Alice," "by Bob," and "by a third party" are sometimes used herein as shorthand for "by Alice's computing device 102a," "by Bob's computing device 102b," and "by a third party's computing device 102," respectively. Note also that the equipment of a given party may include one or more user devices used by the party, or several server resources, such as cloud resources, utilized by the party, or any combination thereof. It does not necessarily limit operations to being performed on a single user device.

Since the unlock script of the target transaction Tx _p is adaptive, in an embodiment, a second version Tx _p ' of the target transaction may be generated by adapting the first version Tx _p , i.e., by taking the existing data structure of Tx _p and modifying it to form the second version Tx _p ', in this case by adapting the lock script. This is an example of script-level adaptability. In an equivalent variant, however, Tx _p ' may be generated by generating a new version of the target transaction that has the same structure except that the unlock script is different. "Update" may be used herein as a general term to describe the possibility of adapting an existing structure or generating a new replacement version. Adaptation may be mentioned herein as an example in connection with various embodiments, but it is understood that this may be replaced by generating a new version of the target transaction from scratch. Either way, the adaptation or generation of the new version may be performed by Alice and/or Bob and/or by a third party given the signatures of Alice and/or Bob.

In some embodiments, the lock script of Tx ₁ may include a third unlock condition as an alternative to both the first and second conditions. The third condition may require that the lock time expires and that Alice's signature be included in the unlock script of the third version of the target transaction, Tx _p ″. This allows Alice to claim back her payment from the output of Tx 1 if Bob does not claim under either the first or second condition (e.g., because he does not engage in the transaction at all or fails to do so within _the time limit). The lock time may be defined as an absolute point in time, or a period of time that must elapse, measured, for example, in seconds, or a number of blocks to be mined.

Exemplary Use Case 1 - Security for Bob As described above, in an embodiment, at Tx ₁ , the first condition (i) requires that Bob's signature and data payload be included in the unlock script of Tx _p , but does not require Alice's signature. The second condition (ii) requires both Alice and Bob's signatures, but does not require the data payload to be included in the unlock script of Tx _p '.

That is, suppose Alice wants to pay Bob for providing her with some service, e.g. doing some DIY for her, providing some goods, providing some consulting services, etc. Alice generates a first (intermediate) transaction Tx1 that includes the payment for the service in an output (output 0 of _Tx1 with reference to the example above). She sends this to Bob via the side channel 301. Alternatively, the first transaction could be generated by Bob, or by a third party. It could be submitted at this stage by Alice, Bob, or _a third party to be propagated through the network 106 to be recorded in the blockchain 150. Alternatively, it could be submitted to the network 106 later by any of those three parties, either simultaneously with the second target transaction _Txp / _Txp ' or after the target transaction.

Alice also sends the first version of the target transaction, Tx _p , via side channel 301 to Bob as a template for Bob to sign and add his data payload (or the payload may be included by Alice). Alternatively, the first version of the target transaction may be generated by Bob or by a third party as a template for Bob to sign and add his data payload (or the payload may be included by a third party). Bob keeps a copy of the first version of the target transaction, Tx _p , at least until the second version, Tx _p ', is obtained. Alternatively, the first version, Tx _p , may be kept by a third party on Bob's behalf, given Bob's signature and data.

The target transaction Txp initially includes a data payload and therefore does not require Alice's signature, but is unilaterally redeemable by (or on behalf of) Bob only if the data payload is included in the unlock script. This would be more expensive to mine and/or could compromise Bob's private or proprietary data. Bob therefore wants to keep Alice happy and provide her with a second, updated version of the target transaction _Txp ' that includes her signature (or send her signature that Bob or a third party composes into the target transaction _Txp '). This allows Bob to redeem the output of _Tx1 without having to include a data payload in the target transaction Txp _' . However, if Bob provides a service but Alice breaks the agreement or there is a dispute over the satisfactory provision of the service, Bob still has the fallback to redeem the output of _Tx1 under the less favorable first condition that requires the data payload to be included in the target transaction _Txp .

Once Bob has accomplished the service for Alice, she provides her signature if Alice is honest and satisfied with the service. The second version of the target transaction, Tx _p ′, requires signatures from both Alice and Bob. Bob may send the first version, Tx _p , with or without the data payload to Alice over a side channel 301 for Alice to adapt by signing it with her signature (and removing the data if still present). Alternatively, Bob may simply send his signature to Alice over a side channel 301 for Alice to compose into the second version, Tx _p ′. Alice may then send this version (sometimes referred to as “broadcasting” or “publishing” the transaction to the network 106) to be propagated through the P2P network 106 and recorded in the blockchain 150. Alternatively, Alice may return the complete second version of the target transaction, Tx _p ′, to Bob via side channel 301 for Bob to broadcast to network 106, or send it via a side channel to a third party for the third party to broadcast. As another example, Alice generates her signature based on the first or second version (the only difference between them is in the adaptive part) and simply sends her signature to Bob via side channel 301. Bob composes Alice's signature along with his signature into the complete second version of the target transaction, Tx _p ′, which he broadcasts to network 106, or sends it via a side channel to a third party for the third party to broadcast. Or in another alternative, both Alice and Bob send their signatures via a side channel to a third party, which composes into the complete second version of the target transaction, Tx _p ′, which he broadcasts to network 106.

The first transaction _Tx1 , and indeed also the source transaction, needs to be broadcast to the network 106 in order to be recorded in the blockchain 150. This can be done at any time by any party, as long as they are eventually verified at some stage.

The fact that the first condition does not require Alice's signature means that Bob can automatically redeem the amount defined in the output of Tx ₁ under the first condition with the first version of the target transaction Tx _p even if Alice does not provide her authorization with her signature. However, the requirement to include a data payload is onerous. Miners 104M require a mining fee to accept the transaction for mining. If the fee is not sufficient, they will not accept the transaction for mining into block 151, even if the transaction is valid (validity and acceptability are separate concepts). Alternatively or additionally, the data in question may be secret, confidential, or proprietary to Bob. As a result, publishing the data to the blockchain 150 may present another form of penalty to Bob. Bob is therefore motivated to provide good service to try to obtain Alice's signature and to redeem Tx ₁ under the preferred second condition with the second version of the target transaction Tx _p ′. However, if Alice breaches, Bob can still redeem Tx ₁ using the first version of the target transaction, Tx _p , under the less favorable first condition. Thus, the first version, Tx _p , serves as a kind of mortgage or deposit for Bob.

Note that even if Tx ₁ was created by Alice, the requirement in the first condition in Tx ₁ 's lock script does not require that the data payload itself be included in Tx ₁ 's lock script or known to Alice. Rather, it only requires that a hash of the data payload be included in Tx ₁ 's lock script (along with a script that challenges Tx _p 's unlock script to provide data that, when hashed at node 104, matches the hash value in the unlock script). Thus, even if Alice or a third party creates Tx ₁ , Bob only needs to give them a hash of his data, not the data itself. He only needs to publish the data if he publishes the first version of the target transaction, Tx _p , onto the chain.

Illustrative Use Case 2 - Streaming With reference to FIG. 7, for example, Alice wants to pay to stream some data from Bob. The data is transferred from Bob to Alice "chunk by chunk", i.e., in a sequence of portions _D0 , _D1 , _D2 , etc. These may be, for example, portions of an item of media content that Alice is streaming from Bob, including, for example, a video track such as a movie and/or an audio track such as music. The video may include any time-changing images or graphics, such as a movie, a TV program, a slide show, or other such sequences or still images, animated vector graphics, and/or gaming content. The audio may include sampled and/or synthesized audio, and may include dialogue, music, noises, and/or effects, etc. In another example, the following techniques may be used to enable the provision of services to Alice "as long as she goes", such as the provision of essential services such as gas, electricity, or water, or the rental of a vehicle, property, or other physical object. In the case of payment for a service, instead of the data portions being parts of the desired content itself, each data portion _D0 , _D1 , _D2 etc. contains a different respective key required to unlock a unit of the service. For example, Alice's gas, electricity or water supply is governed by a smart meter connected to her computing equipment 102a. With each received key, she feeds it from her computing equipment 102a to her meter, which in response to verifying the respective key, unlocks another unit of the essential service.

It may be desirable to stream the portions of the data so that Bob's payment is proportional to the number of data portions received so far. To do this, in response to each data portion _D0 , _D1 , _D2 ... being received from Bob, Alice can return a respective signed transaction _Tx1 , _Tx2 , _Tx3 ... to Bob via side channel 301. This means that if Bob stops sending data, Alice can simply stop sending payments, and if Alice stops sending payments, Bob can simply stop sending data and will not provide more than one portion of the data D that Alice has not paid for.

However, it is also desirable to do this in a way that does not require broadcasting to the network 106 and recording in the blockchain 150 a separate transaction for each separate data portion _D0 , _D1 , _D2 , etc. being streamed, as this could increase network congestion and bloat the blockchain 150.

To solve this, each transaction _Tx1 , _Tx2 , _Tx3 ... that Alice sends back to Bob in response to each data portion _D0 , _D1 , _D2 ... that she receives from Bob, respectively, is a different instance of the first transaction pointing to the same output (e.g., the same UTXO) of the same source transaction _Tx0 . As the amount of the first transaction grows each time, Bob only claims the last one at the end of a particular defined sequence, for example the end of an audio or video track (e.g., the end of a movie), or the output of a specified period of service (e.g., once an hour, day, week, or month). This is explained in more detail further below with reference to FIG. 7.

It is also desirable to stream the parts, firstly so that Bob cannot cheat by getting payment from Alice and not sending the data, and secondly so that Alice cannot cheat by receiving the data and not paying Bob.

In an embodiment, each instance of the first transaction has multiple outputs with a total digital asset amount greater than that pointed to by its inputs. This means that the transaction is not valid until someone, in fact Bob, adds another input of his own to make up the difference (an example of input-level adaptability). This stops Alice from issuing an earlier transaction in the sequence, which prevents Bob from issuing a later transaction. This thus enables streaming without having an initial funding transaction that acts as a deposit for an entire movie, etc. This is discussed in more detail below with reference to FIG. 8.

To implement the streaming method, Alice and Bob establish an off-chain side channel 301 between them. That is, transactions sent over this channel are not (yet) published to the P2P network for recording in the blockchain 150. This is used as a modified form of a payment channel, also referred to herein as a "fine payment channel". In addition, Bob makes available to Alice a hash set of the data portions D ₀ , D ₁ , D ₂ ... in the sequence. For example, Bob may send the hash set to Alice over the payment channel 301, or may make it publicly available for access from a server such as the Internet 101. The hash set includes a set of hashes that allow Alice to generate a hash challenge for data without Alice having to have prior knowledge of the data itself. For example, the hash set may include a hash tree, also known as a Merkle tree (note that the term "Merkle tree" is used herein in its broadest sense to mean any hash tree, e.g., not necessarily limited to a binary branch). Alternatively, the hash set may include a hash chain or a hash list.

Bob begins by sending Alice a first data portion _D0 over the payment channel 301. This first portion is sent for free or reliably. If Alice does not pay, Bob loses no more than the data value of the first portion. Assuming Alice wants to continue, in response to receiving _D0 , she sends Bob a first instance of the first transaction _Tx1 over the payment channel 301. In response, Bob sends Alice the next data portion in the sequence, and in response, Alice sends Bob a second instance of the first transaction _Tx2 , and then Bob sends Alice _D2 , and Alice sends Bob _Tx2 , and so on, all over the payment channel 301. Each instance _Tx1 , _Tx2 , _Tx3 , ... of the first transaction specifies an increasing payment to Bob, e.g., linearly increasing with the number of data portions D received so far. However, each instance of the first transaction, Tx ₁ , Tx ₂ , Tx ₃ ..., points to the same UTXO of Alice. Therefore, Bob only needs to construct second, valid instances of the target transaction, Tx _p /Tx _p ', and claim payment from one of them (any attempt to redeem the same UTXO twice will be rejected by the network 106 as invalid). Assuming all goes well, Bob will therefore create a version of the target transaction that claims payment from the last instance of the first transaction in the sequence.

In an embodiment, each instance Tx ₁ , Tx ₂ , Tx ₃ ... or the last instance Tx _n of the first transaction defines in its output several alternative conditions for redeeming the payment from Alice, as described above (e.g. with reference to FIG. 5). In this case, together with Alice's acknowledgement of the last data portion D _n in the sequence, she also provides a second version Tx _p ' of the target transaction, or at least her signature, to allow Bob to construct Tx _p '. This allows Bob to claim payment for the complete sequence (e.g. the whole movie) under a preferred second condition, rather than the first condition, which penalizes Bob. If Bob stops streaming portion D and Alice is dissatisfied, she does not have to provide her signature to satisfy the second condition, if necessary. Thus, Bob can only claim payment under the first, less favorable condition. On the other hand, if Alice is not dissatisfied but stops requesting further parts midway (e.g., she simply chooses to stop watching the movie), then, given that each of the first transaction instances Tx ₁ , Tx ₂ , Tx ₃ ... contains multiple alternative conditions up to that point, Alice may provide Tx _p ' or her signature, allowing Bob to claim payment for the sequence up to that point based on her preferred second condition.

The first transaction instances Tx _i , i=1,2,3... use a common UTXO for different messages, but multiple signatures, so an instance in this context represents each "request" for data from Alice as an instance of a transaction (discussed below), since changing the value and requested data changes the signed message.

The second transaction version Tx _p /Tx _p ' uses a common UTXO but multiple signatures for the same message. Thus, in this context, versions represent the "unadapted" and "adapted" forms of the transaction as the respective versions of the transaction, since script-level adaptation does not change the signed message.

Note: the variants discussed above regarding which party generates and/or broadcasts the first transaction Tx ₁ ..., and either the first and second versions of the target transaction Tx _p /Tx _p ' may also apply here. For example, a third party may generate and/or broadcast some or all of these on behalf of Alice or Bob. Alternatively, Bob may send Tx _p /Tx _p ' to the network himself or to Alice for broadcast, send his signature to Alice so that she constructs the target transaction Tx _p /Tx _p ', etc. For the sake of brevity, these various options will not be repeated in full here again.

As an example, consider the movie industry. The script size limit is 10kB at the time of writing. Each movie can therefore be divided into a number of 8kB parts. If there are other constraints, the part sizes can be smaller, or larger if the script size limit is increased. Once the parts are defined, a Merkle tree can then be constructed and the root hashes are publicly listed along with the movie titles.

For simplicity, the discussion assumes that mining fees are implicitly applied. There may be other implicit inputs if the explicit inputs do not cover the explicit outputs and implicit transaction fees.

Alice wants to buy a movie from Bob. The movie is defined by n+1 small data packs D ₀ ,...,D _n and their Merkle tree T with root hash H _root . The method composes a sequence of transactions TX ₁ ,TX ₂ ,...,TX _n from Alice to Bob, where each transaction TX _i is for a request for D _i and an acknowledgment of receipt of D _i-1 . Ideally, when the payment channel 301 is closed correctly, only two transactions TX' _n and TX' _p are issued to achieve the payment from Alice to Bob. This scenario is illustrated in Fig. 7. Fig. 7 is a sequence diagram of the payment channel 301 between Alice and Bob in use case 2. There is one initial message from Bob to Alice, followed by n message pairs for each data packet, and two final messages to close the channel.

Round 1 – Alice's turn:
First, Bob sends Alice the complete Merkle tree, including _D0 and the expected data packs. Alice checks that the root hash indeed belongs to her selected movie title and verifies the Merkle path of _D0 . Once Alice is satisfied with the data she has received, she may wish to acknowledge that she has received TX1 and request _D1 , and may construct _TX1 . This transaction may take the following form:

An example of this instance is shown in Figure 9. This single transaction design has three intended functions. By assigning additional implications to some fields in the transaction, it is possible to replace the multiple messages required in a data trade scenario with just one transaction template. Sig(P _A ,Tx ₁ ) is a signature that acknowledges that the previous data pack was received and is satisfactory. OP_DUP OP_SHA256 <H(D ₁ )> OP_EQUAL is a request for the next data pack. 500 units are paid for the next data pack.

The input(s) of _Tx1 includes at least input 0, which contains a pointer to the UTXO of a previous transaction, _Tx0 , that was locked for Alice. The UTXO is of a larger amount (e.g., 2000 units) than output 0 of _Tx1 (see below). Input 0 of _Tx1 also contains Alice's signature in the input's unlock script, and a flag that allows other parties to add the input ("ANYONECANPAY").

The output(s) of Tx ₁ include at least output 0, which specifies a small (initial) amount of digital assets (e.g., 500 units) less than input 0 of Tx _1. Output 0 of Tx ₁ also includes a locking script that allows it to be unlocked by any of the following conditions:
(i) The unlock script in the input of a subsequent transaction Tx _p includes _D1 and Bob’s signature;
(ii) the unlock script in the input of a subsequent transaction Tx _p ′ includes Alice’s signature and Bob’s signature; or
(iii) The timeout limit elapses and the unlock script in the input of the subsequent transaction includes Alice's signature.

Regarding condition (i), since Bob has sent Alice a Merkle tree, also called a hash tree, Alice knows what data portion to expect. This allows her to determine the hash of _D1 . This is enough for her to include this condition by a hash challenge (the lock script of _Tx1 contains the hash of _D1 plus some code that checks that when hashed, the value presented in the unlock script of input _Txp , matches the value in the lock script). This condition means that if Bob wants to claim a payment without having Alice's signature, he must upload _D1 to the blockchain 150. He does not want to do this because _D1 is his own data, and furthermore the size of _D1 would result in high mining fees. This same technique can be used for subsequent data portions _D2 , _D3 , etc.

Condition (ii) means that if Bob instead gets Alice to give her signature, he can request payment without needing to upload the data. However, suppose he still does not want to do that.

Condition (iii) is optional. It gives Alice the ability to claim back the amount in output 0 of Tx1 if Bob does not claim for any reason after a certain specified timeout period (e.g., Bob is not involved in the transaction). It is understood that the specific timeout value in block 720 is merely an example. More generally, the timeout period may be defined in number of blocks, or in human time such as seconds, and may be set to any value. It may end at an absolute time point, or be defined as an amount of elapsed time.

Tx ₁ may also optionally include one or more further outputs. In an embodiment, these include Output 1 and Output 2. Output 1 includes a script that defines the amount of digital assets locked for Alice (Alice's changes) equal to the input amount. For example, this is 2000-500 units=1500 units.

Output 2 is equal to Output 1, and contains a script that defines the amount of digital assets locked for Bob ("pay Bob the same as Alice's change in Output 1"). The effect of this is that the total output (e.g. 500 + 1500 + 1500 units = 3500 units) will always be greater than the input, unless someone else (which in practice would only be Bob) adds another Input 1 of his own to Tx ₁ to make up the difference.

Output 2 is a trick designed to prevent Alice from publishing a transaction without Bob's approval. As a payer, Alice has no incentive to broadcast TX ₁ initially. However, after a few rounds, when there are other transactions in which Alice pays Bob more, Alice can invalidate them by broadcasting it to the network 106 with TX ₁ before Bob can use the later instance to claim his payment. By including Output 2, TX 1 will not be valid until Bob adds his own input (input 1) to TX ₁ to cover the shortfall between the output and the input. Bob can add an additional input because Alice uses the SIGHASH flag _{"ALL|ANYONECANPAY". As a result, TX 1 can} only be broadcast by Bob. Alice does not want to add the additional input required to make TX ₁ valid because this would cost her more if she were not to cheat the system.

Alice's change is defined as the value of Alice's input (input 0) minus the value of Bob's payment (output 0). As the graph in Figure 8 shows, Bob's insurance (output 2) ensures that the total output (dashed line) is always greater than the input before the last data piece is sent.

More generally, other combinations of outputs can be used to create a situation where the total output value of _Tx1 is greater than the total input value, thus requiring Bob to add his own input to claim the 0 output of _Tx1 and disincentivizing Alice from broadcasting _Tx1 .

As an example of implementing the three conditions (i), (ii), and (iii) on output 0 in a scripting language, one can use hash puzzles and conditional opcodes, for example as follows:

Round 1 – Bob's Turn:
When Bob receives transaction _TX1 , he simply sends _D1 to Alice. Note that Bob can claim the payment in TX1, and does this safely, without assistance from Alice, by doing the following: First, Bob creates TX1' by adding his own input using an outpoint (TxID _B , vout=0) to cover the value of output ₂ in _TX1 . Then, Bob creates another transaction _TXp to claim the payment.

Bob may then broadcast both transactions to the network 106. However, this is not an ideal situation for Bob, since he would have to disclose _D1 in the transaction. This is considered a recall closure of the channel. However, if Alice follows the correct procedure to close the payment channel (described below), Bob does not need to do this.

Round 2 - Alice's turn: Once Alice receives _D1 and is satisfied with the content, she constructs the following transaction for the next data pack. This transaction can also be considered as an acknowledgment of receiving _D1 .

Comparing _TX1 and _TX2 , _D1 has been changed to _D2 , and the value of output 0 has been increased from 500 units of the digital asset to 1000 units. As a result of these two changes, the other outputs have different values (assuming Alice is using the same unused outpoint). Furthermore, because these changes are not made to the adaptive part of the transaction, Alice must generate a new signature for _TX2 .

Round 2 – Bob's Turn:
When Bob receives TX ₂ , he simply transmits D ₂ to Alice.

Bob does this safely, as before, since he can claim the payment without Alice's help in the same way as in the first round. Bob again adds his own input from (TxID _B , vout=0) to cover output 2 in TX ₂ , generating TX ₂ '. Bob also generates another transaction TX _p to claim the payment.

Bob may then broadcast both transactions to the network.

If Alice and Bob cooperate to close the channel, Bob can avoid doing this as described in the first round.

Final Round – Alice's Turn:
After a few rounds, Alice constructs TX _n to request the final data pack D _n .

Final Round – Bob's Turn:
Bob responds with the final data pack D _n .

Closing the channel: There are several interactions between Alice and Bob to close the payment channel. Either Alice or Bob can signal to the other their intention to close the channel 301. Without loss of generality, let D _n be the last data pack sent from Bob to Alice. Bob finds a transaction TX _n that requests D _n and adds his own input to cover output 2, generating TX _n '. Bob generates TX _p as follows:

Bob sends both transactions, TX _n ' and TX _p , directly to Alice over the payment channel 301. Alice checks that the inputs TX _n ' and TX _p are indeed related as she expects. Alice signs TX _p and replaces D _n with her signature, producing TX _p '.

Alice sends TX _p ' to Bob. Bob broadcasts TX _n ' and TX _p ' to the network 106. Alternatively, Alice may broadcast TX _n ' and/or TX _p ', or send one or both of them to a third party to broadcast on behalf of Alice and Bob. Note that Alice can choose to close the channel at any time.

Figure 7 shows two ways: (A) the channel is unilaterally closed by Bob by broadcasting a bare copy of the transaction; and (B) the two transactions that form the pair are both broadcast upon channel closure, indicating that the channel is effectively "opened" off-chain without communicating with the network 106.

To play back the sequence, in response to Tx ₁ , Bob sends D ₂ to Alice. Alice sends Tx ₂ to acknowledge Bob, who then sends D ₃ , etc. Tx ₂ is the same as Tx ₁ , but D ₁ is replaced by D ₂ and the amount of output 0 is increased. In Tx ₃ , D ₂ is replaced by D ₃ , again increasing the amount of output 0. In an embodiment, the amount of output 0 increases linearly with i, i.e. with the Tx sent with each chunk and acknowledgement. Alternatively, it is not excluded that another increasing relationship could be used, for example to give a higher weight towards the end of the sequence to provide an additional incentive to complete the sequence.

Bob can unilaterally claim any one of Tx ₁ ...Tx _i based on criterion (ii). To do this, Bob adapts it to generate Tx _i '. The adaptation involves adding some input of Bob's digital assets to make up the difference, and then generating another transaction Tx _p that includes D _i in its input to use Tx _i . Tx _p is conditionally locked to Bob. Bob could add his input and use one of the previous transactions Tx ₁ or Tx ₂ , etc., but there is no value in doing so. He wants to keep sending the movie and get the full amount at the end. Also, Bob wants to not rely on criterion (ii) because he has to publish one of his movie chunks to the blockchain.

Note that each input Tx ₁ , Tx ₂ , Tx ₃ ... specifies the same UTXO of Tx _0. Thus, if any one of them is broadcast to the network and validated at any given node 104, any others of them will not be considered valid at that node (a condition for validity is that Tx does not attempt to use a UTXO that has already been validly used by another transaction). Different nodes 104 may initially receive different instances and thus may have conflicting views of which instances are "valid" before one instance is mined, at which point all nodes 104 agree that the only valid instance is the one that was mined. If a 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 first instance it accepted that has not yet been mined.

If Bob cashes out early and stops sending the movie, Alice only pays for one more chunk than she received and only loses 500. Alice can bail at any time, but if she does, Bob will not send her more than one chunk (say, 500 units worth) of the movie that she did not pay for.

Starting small, the amount grows each time towards the end of the movie, and because all transactions attempt to use the same UTXO in Tx ₀ , cashing in any one invalidates any others. Also, in an embodiment, the sum of the outputs is not necessarily greater than the inputs until Bob adds his own input. This is an example of input-level adaptability.

If both Bob and Alice wait until the end of the movie, Bob sends Tx _n ' to Alice for her to sign, which replaces the hash of D _n with her signature. This allows Bob to claim the full payment without issuing any chunk of data D. This is an example of script-level adaptability.

To avoid data congestion on the blockchain, the process uses a lock script that can be unlocked using any data package or the signature of the data recipient. Using transaction adaptability, the data recipient can replace the data in the unlock script with her or his signature. This action not only acknowledges that the data was received or confirms the closure of the payment channel, but also removes the data from the transaction to save space.

Bob has no incentive to issue any transactions other than the last one he receives from Alice, given the incremental increase in transaction value. If Alice leaves the channel midway, Bob simply issues the last transaction he received from Alice along with a transaction to claim payment. If he does not receive Alice's adapted transaction, he must disclose the associated data pack to claim payment. In an embodiment, if there is a strong requirement for data authenticity, Bob can encrypt the data he sends to Alice and disclose the decryption key in the transaction (described below).

For Alice, however, there is an incentive to issue the first transaction once she receives a sufficient data pack. When the first and last transactions are both valid, it is uncertain whether she will succeed in invalidating the last communicated transaction. To avoid this scenario entirely, embodiments include an additional output that invalidates the transaction itself unless someone covers the difference between the output and the input. For Alice to make the transaction valid, she provides an additional input, which defeats her purpose of broadcasting the transaction.

If Bob goes offline, Alice cannot continue watching the movie. However, she does not pay for more than she watched. She can wait for Bob to come back, or simply move to another service provider and start where she left off.

Note that the funding transaction required for this does not form a payment channel. Furthermore, Alice has the flexibility to reconnect to resume the streaming service at any point; there is no overhead of establishing a payment channel.

The embodiment solves all the risks in the payment channel. It may still be possible for Alice to double-spend her UTXO outside of the payment channel. To prevent this, the embodiment can prevent any one or more of three options. When Alice tries to double-spend her UTXO, a technique should be employed to force Alice to reveal the secret key for the bank deposit. In this case, Bob can claim the entire deposit. The second option also makes Alice's acknowledgment legally binding. That is, Alice's signature on Bob's claim transaction is considered as binding proof of her identity. Any fraudulent behavior by Alice is subject to law enforcement. The third option is for Bob to terminate and restart the payment channel over time, for example every 5 minutes. The frequency can be assigned by Bob according to his own assessment of the risk. Note that there is no overhead in restarting the payment channel since no funding transaction is required.

Data encryption: Data authenticity is often a requirement when data is exchanged over a public network. In the previous chapter, we assumed that the data receiver knows exactly what is being received. However, when data is encrypted, it is difficult to know in advance what ciphertext or what hash value is expected without any communication. This gives rise to the requirement to construct a hash puzzle in the lock script. To mitigate this, in an embodiment, the seller of the data can communicate the hash value of the ciphertext to the receiver of the data before sending it. The receiver of the data constructs a payment transaction with the given hash value. Upon receiving the encrypted data, the receiver of the data can decrypt the data and verify if the data is as expected. If it is, all is well. If it is not, in the worst case, the receiver loses money. However, the amount the receiver loses is bounded by the price per data packet. For a movie, it is probably around 500 units, which amounts to, say, $5 for a movie. Given that the economic value is small and the reputational impact is much larger, there is no incentive for the seller of the data to cheat.

Some embodiments may implement a mechanism to establish a shared secret key from a symmetric cipher between the seller of data and the buyer of the respective data. Thus, all data in transit can be encrypted.

Exemplary Use Case 3 - Polls and Voting In another exemplary use case, different alternative terms of a first transaction Tx ₁ may be used to represent different voting options, for example as shown in FIG. 5 and using blockchain 150 as a means to record votes. Before Tx _p ' is mined into blocks 151, the options represented by Alice in Tx _p are considered as votes indicating voting intention. In the following example, the first transaction is denoted as Tx _Slip , the first version of the second (target) transaction is denoted as Tx _Poll , and the second version of the target transaction is denoted as Tx _Vote .

Consider the following example scenario: An election is imminent. A governmental entity ("Bob" 103b) wants to encourage participation in polling and voting itself, using a blockchain-based voting system that can reward voters for participating. For simplicity, assume this is a two-party system with "Labour" and "Conservative" parties. The governmental entity P _Gov is responsible for (a) registering voters, (b) issuing ballots, and (c) polling and counting votes. The governmental entity is the second party 103b, also referred to as "Bob" in this scenario. The electorate includes N voters. When each voter ("Alice" 103a) registers, she chooses a secret "Vote Token" T _V , known only to the voter. Bob's governmental entity knows the hash value H(T _V ) of each registered voter.

The following definitions may be used for polling and voting systems.
Registration:= A voter uses some off- or on-block process to register as a voter. The voter privately selects T _V and gives H(T _V ) to Bob's government.
Vote slip (Tx _Slip ):= A transaction containing a locking script that pays a voter if they take part in a poll and/or vote.
Poll (Tx _Poll ):= a signed transaction that uses unlock condition (i) or (ii) to unlock a voting output, where (i) and (ii) represent voting choices for two respective options, e.g. a general vote or a political party (see example below).
Vote (Tx _Vote ):= a signed transaction that uses unlock condition (iii) or (iv) to unlock a voting output, where (iii) and (iv) represent voting choices for two respective options (again, see example conditions below).

Every voter also has their own public key _PV , and in order to poll or vote for the party of their choice, each must sign with the public key reflecting their choice.

ここで、"．．．"は、「スカラーによるEC点乗算」のための演算子として定義される。 In the illustrative two-party system example, one of only two parties may be chosen, and there are two possible public keys for voters to express their choice, which may be:

where "..." is defined as the operator for "EC point multiplication by a scalar".

実施形態は、以下から切り換えるために、スクリプトレベルの適応性により切り換え条件の概念を使用する。

これらの切り換えは、同じ政党について、世論調査を（”→”）投票へ変換することを表す。これらの変換は、適応性を用いて達成できる。何故なら、使用された公開鍵、従って署名は、切り換えに跨がり一貫しているからである。インプットスクリプトデータの残りの部分のみが、適応され（malleated）、従って、投票者の署名は変更される必要がない。 With regard to the unlock conditions, the lock script is configured to be unlockable by satisfying any one of four different unlock conditions: Conditions (i) and (iii) are both related to the "Labour Party" and represent a poll and a vote respectively; Conditions (ii) and (iv) are both related to the "Conservative Party" and represent a poll and a vote respectively. The conditions are fully written as follows:

The embodiment uses the concept of switch conditions with script level adaptability to switch from:

These switches represent the transformation of polls into ("→") votes for the same party. These transformations can be achieved with malleability because the public keys used, and therefore the signatures, are consistent across switches. Only the remaining parts of the Input Script data are malleated, and therefore the voter's signature does not need to be changed.

実施形態では、これは、適応性及び切り換え条件を用いて行うことができない。代替として、しかしながら、これは、代わりに、それぞれ世論調査又は投票トランザクションのシーケンス番号を増加させることにより、達成できる。ここで、Alice（投票者）により署名されたメッセージがシーケンス番号を含む。これは、Aliceの世論調査選択についてのAliceの署名が、彼女の後の投票選択を偽造する目的でAliceの署名を再生するために悪意ある第三者により使用できないことを意味する。 However, if a voter wants to switch the condition from:

In an embodiment, this cannot be done using the adaptivity and switching conditions. Alternatively, however, this can be achieved by instead incrementing the sequence number of the poll or vote transaction, respectively, where the message signed by Alice (the voter) includes the sequence number. This means that Alice's signature on her poll choice cannot be used by a malicious third party to regenerate Alice's signature in order to forge her later vote choices.

The unlock conditions are used to unlock a particular lock script, whereby each unlock condition satisfies a separate lock condition within the lock script. The lock script in question is referred to herein as the "Vote script" and is shown below.

The polling and voting procedure is shown in Figure 10. This is a sequence diagram showing the complete polling and voting process from the announcement of the election at _t0 to the end of the voting period at _t3 .

This procedure can be divided into the following steps:

Step 1: Bob's government, P _Government , begins voter registration at time _t for a vote to take place at a later time t. Voters are free to register and provide their hashed token H(T _V ) as part of _the voting process.

Step 2: Bob's government P _Gov issues N voting transactions Tx _Poll . Each vote payment, an individual voter's, is coordinated with the voter's public key P _V , as described above, by a lock script [vote script]. Each transaction is time-locked to a later time _t2 .

Step 3: Voter Alice has a public key P _V and wishes to participate in the poll phase. The poll phase is defined as all time t: t ₀ < t < t _2. The voter participates in the poll by making her selection “Labor” and constructing a poll transaction Tx _Poll (FIG. 11) with the unlock script condition (i).

This transaction can be published by a voter, the government, or a third party, but cannot be mined until _t2 .

If a voter wants to change her poll choice to "Conservative", she must instead use script condition (ii) to generate a new poll transaction and increment the sequence number.

Step 4: Voter Alice, at some time _t1 , decides that she wants to convert her "Labour" poll option into a vote option. This involves adapting the unlock script of the poll transaction to generate a vote transaction. The adaptation changes the unlock condition to script condition (iii) [(i) → (iii)].

To perform the adaptation, in step 4, voter Alice sends her voting token T _V to Bob's government. In step 5, Bob's government turns the poll token into a voting token, turning the poll transaction into a voting transaction, and signs the voting transaction with Sig(P _Gov , Tx _Vote ) to ensure that it is a valid vote. As a variant, the voter could put the voting token into a transaction and send it to the government to be signed.

Both the poll transaction and the corresponding vote transaction generated later are invalid for all times t< _t2 due to the lock time _t2 placed on both transactions.

Step 6: Bob's government broadcasts all valid voting transactions at _t2 . Bob's government continues to broadcast any other voting transactions that are finalized at time t: _t2 < t < _t3 , where _t2 defines the start of the voting period and _t3 defines the end of the voting period.

In an embodiment, the government entity does not broadcast the poll transaction. It is up to the person being polled (Alice) to broadcast it and claim the reward.

Note that the Tx _slip also needs to be mined at some point in the process so that there are actually UTXOs to be used in the Tx _poll /Tx _vote . For simplicity, this step is not shown in FIG. 10. The actual method used to lock-time the transaction slightly impacts at what point in the signaling diagram of FIG. 10 the Tx _slip is sent to the network 106. If you put "nLocktime" (definition 8) in each Tx _slip , the Tx _slip also needs to be broadcast to be mined in step 6 (and/or the final optional step) of the diagram. If you instead choose to put OP_CLTV or OP_CSV (definitions 10 and 11) in the lock script of the Tx _slip , the Tx _slip can be mined at the same time as step 2 above.

FIG. 11 shows some example transactions that can be used to implement the process. The transaction at the top, Tx _slip , is a ballot transaction that allows members of an electorate to claim funds by polling and/or casting a vote. Outputs can only be claimed after the voting period begins at _t2 . The transaction in the middle is a poll transaction, Tx _Poll , which means that the voter has selected an option as part of the poll. Assuming an example where lock times are implemented using OP_CSV or OP_CLTV and the Tx _slip is sent to the network at the same time as it is sent to the voter (step 2), this transaction is invalid until _t2 due to the time lock placed on the output of the Tx _slip that it references in its input. The transaction at the bottom is a vote transaction, Tx _vote, which means that the voter has selected an option as part of the vote. This transaction is the same as Tx _Poll , but with the unlock condition switched using script-level adaptability. This transaction is also invalid until _t2 .

In an embodiment, the timelock is included as part of the output of the first transaction (Tx _Slip ). An alternative mechanism, however, is to timelock the Tx _Poll rather than the Tx _Slip to achieve roughly the same effect.

Conclusion
It will be understood that the above-described embodiments have been described by way of example only.

More generally, according to one aspect disclosed herein, there is provided a method for recording a target transaction between a first party and a second party on a blockchain, the method comprising:
obtaining a second updated version of the target transaction, the second updated version being updated relative to an existing first version of the target transaction;
sending the updated version of the target transaction in place of the first version to be propagated through a network of nodes and recorded in a copy of a blockchain maintained at each of at least some of the nodes;
Including,
the target transaction includes an input including an unlock script and a pointer to a first output of a first transaction, the first output including a lock script specifying a plurality of alternative conditions for unlocking the first output of the first transaction;
A method is provided in which the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script of the updated version is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition.

In an embodiment, the method may include providing functionality by a computing device of the second party to enable the second party to transmit the first version of the target transaction to be propagated through the network and recorded on the blockchain based on satisfaction of the first condition.

The functionality may enable the second party to selectively transmit the first or updated version of the target transaction to be propagated through the network and recorded on the blockchain based on satisfaction of the first or second condition, respectively, and the method includes the second party using the functionality to perform the transmission such that the updated version is recorded on the blockchain instead of the first version.

In embodiments, the functionality may provide the second party with an option to manually select to perform the transmission of the first version; and/or
The facility may be configured to automatically trigger transmission of the first version of the target transaction after the expiration of a predefined time or upon a predefined event.

In an embodiment, obtaining the updated version of the target transaction and transmitting the updated version to be propagated and recorded on the blockchain may be performed by a computing device of the second party.

In an embodiment, obtaining the second version may include the second party receiving at least a portion of the second version from the first party.

In an embodiment, the method further comprises, by the second party computing device:
The step of obtaining the first version of the target transaction, wherein the unlock script of the first version of the target transaction may be configured to enable the second party to automatically unlock the first output of the first transaction based on satisfaction of the first condition.

In an embodiment, the second version of the target transaction may be obtained after the first version.

In an embodiment, obtaining the first version may include the second party receiving at least a portion of the first version from the first party.

In an embodiment, obtaining the first version may include the second party generating the first transaction.

In an embodiment, the second condition may require that the unlock script include a cryptographic signature of the first party that signs portions of the target transaction other than the unlock script. In this case, obtaining the updated version of the target transaction includes obtaining a signature of the first party, and the updated version that is propagated and sent to be recorded on the blockchain includes the signature of the first party in the unlock script.

In an embodiment, the first condition may not require a cryptographic signature of the first party.

In an embodiment, at least the first condition may require that the unlock script include a cryptographic signature of the second party that signs portions of the target transaction other than the unlock script.

In an embodiment, the second condition may require that the unlock script include a cryptographic signature of the second party that signs portions of the target transaction other than the unlock script. In this case, the updated version that is propagated and sent to be recorded on the blockchain includes the cryptographic signature of the second party in the unlock script.

In an embodiment, obtaining the updated version may include the second party sending the first version to the first party, which adapts the updated version by adding a signature of the first party. The first and second conditions may require that the same signature of the second party signs the same portion of the target transaction, so that the second party does not need to sign the updated version again.

In an embodiment, the first condition may require that a data payload be included in the unlock script, but the second condition may not require that the data payload be included in the target transaction. In this case, the updated version that is propagated through the network and sent to be recorded on the blockchain does not need to include the data payload.

In embodiments, the first condition may require that the unlock script include a cryptographic signature of the second party that signs portions of the target transaction other than the data payload and the unlock script, but does not require that the cryptographic signature of the first party be included in the target transaction, and the second condition may require that the unlock script include cryptographic signatures of both the first and second parties, but does not require that the data payload be included in the target transaction. In such embodiments, obtaining the updated version of the target transaction includes obtaining a signature of the first party, and the updated version of the target transaction that is propagated and sent to be recorded on a blockchain does not need to include the data payload, but does include the signatures of the first and second parties in the unlock script.

In an embodiment, the requirement includes that the respective data portions are generated by a hash challenge included in the lock script, the hash challenge including a hash of the respective data portion and a hash function for checking that the hash of the respective data portion in the unlock script matches the hash included in the lock script. The method may include making available to the first party, separate from the network, a hash set (e.g., a hash tree) prior to receiving the first transaction instance, the hash set including hash values of each of the data portions to enable a second first party to generate the hash challenge for the respective data portion.

In embodiments, the first output of the first transaction may specify a payment to the second party to be redeemed by unlocking the first output according to the first terms or the second terms;
The target transaction may include an output that transfers at least a portion of the payment to the second party.

In an embodiment, the method includes, by the computing device of the second party:
streaming a sequence of data portions to the first party, terminating with a final portion in the sequence;
receiving a respective instance of the first transaction from the first party in response to a respective one of the data portions, a first output of each instance specifying a payment to the second party for the respective portion;
said payment increasing with each data portion;
Obtaining the updated version of the target transaction follows the final portion in the sequence and includes receiving the updated version from the first party.

In an embodiment, the increase may be linearly proportional to the number of data portions transmitted so far.

In an embodiment, each data portion may be a different portion of an item of media content (e.g., audio and/or video content).

Alternatively, each data portion may be a different key for accessing a unit of service (e.g., the supply of essential services including gas, water, and electricity, or the rental of a vehicle, property, or other physical item).

In an embodiment, the function may provide the second party with an option to manually select, at any point in the sequence, to perform a transmission of the first version of the target transaction to be propagated through the network and recorded in the blockchain to redeem the latest instance of the first transaction in the sequence received so far from the first party. Alternatively or additionally, the function may be configured to automatically perform a transmission of the first version to be propagated through the network and recorded in the blockchain to redeem the latest instance of the first transaction if the first party stops transmitting instances of the first transaction midway through the sequence.

In an embodiment, the first transaction may include one or more first inputs specifying an input amount, the first output of the first transaction may specify a first payment, and the first transaction may further include one or more further outputs specifying one or more further payments. As a result, a total payment is higher than the input amount, and the first transaction received by the second party from the first party has no other inputs that generate a difference. Nodes of a network may be configured to reject the first transaction as invalid if the first transaction specifies a total payment that is greater than the total input amount. In such an embodiment, the method may include the second party adding a second input to a last or most recent instance of the first transaction to make up the difference, and sending the first transaction with the added second input to be propagated through a network and recorded in a blockchain.

In an embodiment, further outputs may include a second output specifying a second payment to the first party equal to the input amount minus the first payment, and a third output specifying a third payment to the second party equal to the second payment.

In an embodiment, the lock script includes a third one of the alternative conditions, which requires that a lock time expires and that a cryptographic signature of the first party be included in the unlock script, thus allowing the first party to redeem a payment in the first output of the first transaction if not redeemed within the lock time by the second party.

In embodiments, each of at least some of the alternative conditions may correspond to a different option for voting;
The method may include, prior to obtaining the updated version of the target transaction, marking the unlock script in the first version as accessible or accessible by a third party as a non-binding indication of voting intent.

In an embodiment, a lock time may be included in at least one of the first transaction and the first version of the target transaction to prevent the network from recording the first version to the blockchain until after a predetermined point in time.

In an embodiment, the output of the first transaction may specify a payment to be redeemed by unlocking the first output according to any one of the conditions specified in the locking script, and the target transaction may include an output that transfers at least a portion of the payment to the first party.

In an embodiment, the alternative conditions may include a first condition corresponding to a poll instruction for the first option, a second condition corresponding to a poll instruction for the second option, a third condition corresponding to a vote selection for the first option, and a fourth condition corresponding to a vote selection for the second option, the unlock script of the first version of the target transaction may be configured to unlock the first output of the first transaction based on satisfying the first or second condition, and the unlock script of the second version of the target transaction may be configured to convert the poll instruction into a vote by being configured to unlock the first output of the first transaction based on satisfying the third condition instead of the first condition or the fourth condition instead of the second condition.

In the case of voting, the first condition may require that the unlock script of the target transaction includes a cryptographic signature of the second party that signs a portion of the target transaction other than the lock script. The first condition may require that the signature of the first party signs an individual voting token. The second condition may require that the unlock script of the target transaction includes the signature of the first party and a cryptographic signature of the second party, each signing a portion of the target transaction other than the lock script.

According to another aspect disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to execute the method of any of the embodiments disclosed herein when executed on a first party and/or second party computing device.

According to another aspect, a first party and/or second party computing device includes:
a memory including one or more memory units;
a processing device including one or more processing units;
Including,
A computing device is provided, wherein the memory stores code configured to run on the processing device, the code configured to perform a method according to any embodiment disclosed herein.

According to another aspect disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to perform operations when executed on a second party computer, the operations including:
obtaining a first version of the target transaction;
obtaining a second version of the target transaction;
causing the second party to selectively transmit either the first or second version to be propagated through a network of nodes and recorded in a copy of a blockchain maintained at each of at least some of the nodes;
Including,
the target transaction includes an input including an unlock script and a pointer to a first output of a first transaction, the first output including a lock script that specifies an amount of the first party's digital asset and specifies a number of alternative conditions for unlocking the first output of the first transaction;
A computer program product is provided, wherein the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition.

According to another aspect disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to perform operations when executed on a second party computing device, the operations including:
obtaining a first version of the target transaction;
obtaining a second version of the target transaction;
causing the second party to selectively transmit either the first or second version to be propagated through a network of nodes and recorded in a copy of a blockchain maintained at at least some of the nodes;
Including,
the target transaction includes an input including an unlock script and a pointer to a first output of a first transaction, the first output including a lock script that specifies an amount of a first party's digital asset and specifies a number of alternative conditions for unlocking the first output of the first transaction;
A computer program product is provided, wherein the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition.

According to another aspect disclosed herein, a second party computing device includes a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute operations on the processing device, the operations including:
obtaining a first version of the target transaction;
obtaining a second version of the target transaction;
causing the second party to selectively transmit either the first or second version to be propagated through a network of nodes and recorded in a copy of a blockchain maintained at at least some of the nodes;
Including,
the target transaction includes an input including an unlock script and a pointer to a first output of a first transaction, the first output including a lock script that specifies an amount of a first party's digital asset and that specifies a number of alternative conditions for unlocking the first output of the first transaction;
A computing device is provided, wherein the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition.

According to another aspect disclosed herein, there is provided a method for causing a second party to record a target transaction on a blockchain, the method comprising:
sending an updated version of the target transaction, the updated version being updated relative to an existing first version of the target transaction;
sending the updated version of the target transaction in place of the first version, thereby causing the second party to send the updated version to be propagated through a network of nodes and recorded in copies of a blockchain maintained at at least some of the nodes;
Including,
the target transaction includes an input including an unlock script and a pointer to a first output of a first transaction, the first output including a lock script specifying a plurality of alternative conditions for unlocking the first output of the first transaction;
A method is provided in which the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition.

According to another aspect disclosed herein, a set of transactions for recording in a blockchain, the set embodied on a computer-readable data medium, comprising:
a first transaction having an output including a lock script that specifies a number of alternative conditions for unlocking the output of the first transaction;
a first version of a second transaction having an input including an unlock script and a pointer to an output of the first transaction;
wherein the unlock script of the zth year first version of the target transaction is configured to unlock the output of the first transaction based on satisfying a first one of the alternative conditions;
A set of transactions is provided, wherein a second version of the second transaction includes an input that includes an unlock script and a pointer to the output of the first transaction, the unlock script being configured to unlock the output of the first transaction based on satisfying a second one of the alternative conditions instead of the first condition.

Other variations or uses of the disclosed technology may become apparent to those of ordinary skill in the art upon review of this disclosure. The scope of the disclosure is not limited by the described embodiments, but only by the scope of the appended claims.

Claims (35)

1. A method for transmitting a target transaction between a first party and a second party to a blockchain, the method comprising:
obtaining a second updated version of the target transaction, the second updated version being updated relative to an existing first version of the target transaction;
sending the updated version of the target transaction in place of the first version to be propagated through a network of nodes, thereby causing the target transaction to be recorded in copies of a blockchain maintained at each of at least some of the nodes;
Including,
the target transaction includes an input including an unlock script and a pointer to a first output of a first transaction, the first output including a lock script specifying a plurality of alternative conditions for unlocking the first output of the first transaction;
the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying a first condition of the alternative conditions, and the unlock script of the updated version is configured to unlock the first output of the first transaction based on satisfying a second condition of the alternative conditions instead of the first condition. The method of claim 1, further comprising: providing functionality by a computing device of the second party that enables the second party to transmit the first version of the target transaction to be propagated through the network and recorded on the blockchain based on the first condition being satisfied. the functionality providing the second party with an option to manually select to perform the transmission of the first version; and/or
the facility is configured to automatically trigger transmission of the first version of the target transaction after the expiration of a predefined time or upon a predefined event;
The method of claim 2. A method according to any one of claims 1 to 3, wherein obtaining the updated version of the target transaction and sending the updated version to be propagated and recorded in the blockchain are performed by a computing device of the second party. The method of claim 4, wherein obtaining the second update version includes receiving at least a portion of the second update version from a first party. by said second party's computing device;
6. The method of claim 1, further comprising: obtaining the first version of the target transaction, wherein the unlock script of the first version of the target transaction is configured to enable the second party to automatically unlock the first output of the first transaction based on satisfaction of the first condition. The method of claim 6, wherein the second updated version of the target transaction is obtained after the first version. The method of claim 6 or 7, wherein obtaining the first version includes receiving at least a portion of the first version from the first party. The method of claim 6, 7 or 8, wherein the step of obtaining the first version includes the step of the second party generating the first transaction. The method of any one of claims 1 to 9, wherein the second condition requires that the unlock script includes a cryptographic signature of the first party that signs portions of the target transaction other than the unlock script, that obtaining the updated version of the target transaction includes obtaining the signature of the first party, and that the updated version that is propagated and sent to be recorded on the blockchain includes the signature of the first party in the unlock script. The method of claim 10, wherein the first condition does not require a cryptographic signature of the first party. The method of claim 10 or 11, wherein at least the first condition requires that the unlock script include a cryptographic signature of the second party that signs parts of the target transaction other than the unlock script. the second condition further requires that the unlock script include a cryptographic signature of the second party that signs portions of the target transaction other than the unlock script;
13. The method of claim 12, wherein the updated version that is propagated and sent to be recorded in the blockchain includes the cryptographic signature of the second party in the unlock script. The step of obtaining the updated version includes:
the second party transmitting the first version to the first party, such that the first party can incorporate it into the updated version by adding a signature of the first party;
14. The method of claim 12 or 13 dependent on claim 6, wherein the first condition and the second condition require the same signature of the second party to sign the same part of the target transaction, and wherein the second party does not need to sign the updated version again. the first condition requires that a data payload be included in an unlock script, but the second condition does not require that the data payload be included in the target transaction;
The method according to any one of claims 1 to 13, wherein the updated version transmitted to be propagated through the network and recorded in the blockchain does not include the data payload. the first condition requires that the unlock script include the data payload and a cryptographic signature of the second party that signs portions of the target transaction other than the unlock script, but does not require that the cryptographic signature of the first party be included in the target transaction;
the second condition requires that the unlock script include a cryptographic signature of both the first party and the second party, but does not require that the data payload be included in the target transaction;
obtaining the updated version of the target transaction includes obtaining the signature of the first party;
16. The method of claim 15, wherein the updated version of the target transaction that is propagated and sent to be recorded in the blockchain does not include the data payload but includes the signatures of the first party and the second party in the unlock script. the first output of the first transaction specifies a payment to the second party to be redeemed by unlocking the first output according to the first terms or the second terms;
The method of any preceding claim, wherein the target transaction comprises an output that transfers at least a portion of the payment to the second party. by said computing device of said second party;
streaming a sequence of data portions to the first party, terminating with a final portion in the sequence;
receiving a respective instance of the first transaction from the first party in response to a respective one of the data portions, a first output of each instance specifying a payment to the second party for the respective portion;
said payment increasing with each data portion;
20. The method of claim 17, wherein obtaining the updated version of the target transaction comprises following the final portion in the sequence and receiving the updated version from the first party. The method of claim 18, wherein the increase is linearly proportional to the number of data portions transmitted so far. 20. The method of claim 18 or 19, wherein each data portion is a different portion of an item of media content. 20. The method of claim 18 or 19, wherein each data portion is a different key for accessing a unit of the service. The service is
Providing essential services, including electricity, gas, or water; or
Renting real estate, vehicles, or other physical items;
22. The method of claim 21, comprising one of: the functionality provides the second party with the option to manually select, at any point in the sequence, to effect a transmission of the first version of the target transaction to be propagated through the network and recorded on a blockchain in order to redeem the most recent instance of the first transaction in the sequence received from the first party to date; and/or
23. The method of any one of claims 18 to 22 when dependent on claim 2, wherein the facility is configured to automatically perform transmission of the first version to be propagated through the network and recorded in a blockchain in order to redeem a latest instance of the first transaction if the first party stops transmitting instances of the first transaction partway through the sequence. the first transaction includes one or more first inputs specifying an input amount, the first output of the first transaction specifies a first payment, the first transaction includes one or more further outputs specifying one or more further payments, a sum of the payments is greater than the input amount, the first transaction received by the second party from the first party does not include other inputs making up a difference, and nodes of the network are configured to reject the first transaction as invalid if it specifies a total payment greater than the total input amount,
24. The method of any of claims 18 to 23, comprising the step of the second party adding a second input to a final or latest instance of the first transaction to account for the difference and transmitting the first transaction with the added second input to be propagated through the network and recorded in a blockchain. 25. The method of claim 24, wherein the further outputs further include a second output specifying a second payment to the first party equal to the input amount minus the first payment, and a third output specifying a third payment to the second party equal to the second payment. A method according to any of claims 17 to 25, wherein the lock script includes a third one of the alternative conditions, which requires that a lock time expires and that a cryptographic signature of the first party is included in the unlock script, thereby allowing the first party to redeem a payment in the first output of the first transaction if not redeemed within the lock time by the second party. each of at least some of the alternative conditions corresponds to a different option for voting;
10. The method of claim 1, further comprising, prior to obtaining the updated version of the target transaction, marking the unlock script in the first version as accessible or accessible by a third party as a non-binding indication of voting intent. 28. The method of claim 27, wherein at least one of the first transaction and the first version of the target transaction includes a lock time to prevent the network from recording the first version to the blockchain until after a predetermined point in time. 29. The method of claim 27 or 28, wherein the first output of the first transaction specifies a payment to be redeemed by unlocking the first output according to any one of the alternative conditions specified in the locking script, and the target transaction includes an output that transfers at least a portion of the payment to the first party. The alternative condition is:
a first condition corresponding to the poll instruction of the first option;
a second condition corresponding to the polling instruction for the second option;
a third condition corresponding to the voting selection of the first alternative; and
A fourth condition corresponds to the voting choice of the second option.
Including,
the unlock script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfying the first or second condition;
30. The method of any of claims 27 to 29, wherein the unlock script of the second updated version of the target transaction is configured to convert the poll instructions into votes by unlocking the first output of the first transaction based on satisfying the third condition instead of the first condition or the fourth condition instead of the second condition. A computer program product which, when executed on a computer system including a first party computing device, causes said computer system to carry out the method of claim 1 . A computer program which when executed on a computer system including a second party computing device causes said computer system to carry out the method of any one of claims 1 to 30. A computer system including a first party computing device, the computer system being implemented on the first party computing device, the computer system comprising:
a memory including one or more memory units;
a processing device including one or more processing units;
Including,
13. A computer system , wherein the memory stores code that, when executed by the processing device, causes the processing device to perform the method of claim 1 . A computer system including a second party computing device, the computer system being implemented on the second party computing device, the computer system comprising:
a memory including one or more memory units;
a processing device including one or more processing units;
Including,
A computer system, wherein the memory stores code that, when executed by the processing device, causes the processing device to perform a method according to one of claims 1 to 30. 1. A computer system including first party computing equipment and second party computing equipment, the computer system being distributed among a combination of the first party computing equipment and the second party computing equipment, the computer system comprising:
a memory including one or more memory units;
a processing device including one or more processing units;
Including,
A computer system, wherein the memory stores code that, when executed by the processing device, causes the processing device to perform a method according to one of claims 1 to 30.

Images