Malleability of Transactions Contained in a Blockchain

Abstract

The present invention discloses a method for recording a target transaction in a blockchain, including: obtaining an updated version of the target transaction, where the updated version is updated relative to a pre-existing first version; sending the updated version, rather than the first version, to be propagated through a node network and recorded in the blockchain. The target transaction includes an input, and the input contains an unlocking script and a pointer to an output of a first transaction. The output of the first transaction contains a locking script, and the locking script specifies a plurality of alternative conditions for unlocking the output. The unlocking script of the first version of the target transaction is configured to unlock the first output of the first transaction on the basis of satisfying a first condition among the alternative conditions, and the unlocking script of the updated version is configured to unlock it on the basis of satisfying a second condition among the alternative conditions.

Description

Technical Field

[0001] The present disclosure relates to the malleability phenomenon in the context of blockchain, i.e., the ability to change certain unsigned parts of a transaction without invalidating the transaction. Background Art

[0002] A blockchain refers to a form of distributed data structure in which each node among multiple nodes in a peer-to-peer (P2P) network maintains a copy of the blockchain. The blockchain includes a series of data blocks, where each block includes one or more transactions. Each transaction can point to a previous transaction in the sequence. Transactions can be submitted to the network to be included in a new block.

[0003] Transactions in a blockchain are typically used to transfer digital assets, i.e., data as a means of storing value. However, the blockchain can also be utilized to implement layered additional functions on the blockchain. For example, the blockchain protocol can allow additional user data to be stored in the transaction output. The maximum data capacity that can be stored in a single transaction in modern blockchains is continuously increasing, enabling more complex data to be incorporated. For instance, this can be used to store electronic files, or even audio or video data, in the blockchain.

[0004] Each node in the network can have any one or all of the roles of forwarding and storing. Each forwarding node propagates (valid) transactions to one or more other nodes, thereby spreading the transactions among them to all the nodes in the network. To record a transaction in the blockchain, a party sends the transaction to a node of the intended propagation network. Each node is configured to comply with the same node protocol, which will include one or more conditions to ensure the validity of the transaction. Invalid transactions will not be propagated. Assuming the transaction has been verified and thus accepted on the blockchain, the additional user data will continue to be stored at each node in the P2P network as an immutable public record.

[0005] In the "output-based" model (sometimes referred to as the "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 specifying the amount of digital assets, sometimes referred to as a UTXO ("unspent transaction output"). The output can further include a locking script specifying the redemption output conditions. Each input includes a pointer to such an output in a previous transaction and can further include an unlocking script for unlocking the locking script of the pointed-to output. Thus, a pair of transactions is envisioned, called the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets, including a locking script defining one or more conditions for unlocking the output. The second target transaction includes at least one input, including a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0006] In such models, when a second target transaction is sent to the P2P network for propagation and recorded in the blockchain, one of the validity conditions applied by each node is that the unlocking script meets the requirements defined in the locking script of the first transaction. Another condition for the target transaction to be valid is that the output of the first transaction has not been redeemed by another valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction nor include it.

[0007] Suppose the target transaction is to transfer a certain amount of digital assets from a first party ("Alice") to a second party ("Bob"). One of the requirements defined in the locking script of the previous first transaction is typically that the unlocking script of the target transaction contains Alice's cryptographic signature. The signature must be generated by Alice signing a part of the target transaction. Which part it is can be flexibly defined by the unlocking script or can be an inherent feature of the node protocol, depending on the protocol used. However, the parts intended to be signed usually do not include some other parts of the target transaction, such as part or all of the unlocking script itself.

[0008] This makes "malleability" possible. That is, the unsigned parts of the target transaction can be modified ("extended") without invalidating the transaction. Malleability is generally a known concept in cryptography. Using malleability, a message can be maliciously modified but still be considered authentic, so malleability is generally regarded as a security issue. In the context of the blockchain, malleability does not necessarily pose a problem, but is just a wonderful human artifact. Using malleability, a part of a transaction can be modified without invalidating it.

[0009] Recently, it has been proposed to specifically utilize malleability so as to use transactions as carriers of media data. The data content can be included in the unlocking script of the transaction, and then the transaction is sent between parties through a side channel called a "payment channel". One party extends the transaction to delete the data and continues to send the extended version to the P2P network (however, if the data is not deleted, the transaction will bloat the blockchain). Summary of the Invention

[0010] The present disclosure recognizes another way in which malleability, or more generally updatability, can be exploited as a positive feature. In particular, it is also known that the first transaction in a pair of transactions can include multiple different unlocking conditions in its locking script. Generally speaking, only one target transaction version is created to redeem the output of the first transaction based on one condition or the other. However, it is contemplated herein that having two versions can actually be useful: a first version of the target transaction with an unlocking script that redeems the first transaction based on a first condition, and a second version that redeems the first transaction based on a second condition. The second updated version can be created by extending the first version, or a new version can be created from scratch. The two versions can exist in parallel or sequentially. Neither version can effectively redeem the first transaction, but the existence of the first version can serve as a "backup" for Bob in case the necessary conditions are not met and the second condition is not satisfied.

[0011] According to one aspect disclosed herein, a method of recording a target transaction between a first party and a second party in a blockchain is provided. The method includes, by a computer device of the first party or the second party: obtaining a second updated version of the target transaction, updated relative to a pre-existing first version of the target transaction; sending the updated version of the target transaction, rather than the first version, for propagation through a network of nodes and recording in a blockchain copy maintained by each of at least some of the nodes. The target transaction includes an input that includes an unlocking script and a pointer to a first output of a first transaction, the first output including a locking script that specifies multiple alternative conditions for unlocking the first output of the first transaction. The unlocking script of the first version of the target transaction is configured to unlock the first output of the first transaction based on satisfaction of a first one of the alternative conditions, and the unlocking script of the updated version is configured to unlock the first output of the first transaction based on satisfaction of a second one of the alternative conditions, rather than the first condition.

[0012] For each of a plurality of transactions including the target transaction, at least some network nodes are configured to propagate each transaction if the transaction is valid, and at least some nodes are configured to record each transaction in the node's blockchain copy if the transaction is valid, where the validity of the target transaction depends on an unlocking script that unlocks the output of the first transaction according to any one of the conditions, but once one of the versions is verified at any given node, the other version will be considered invalid at that node.

[0013] Thus, the second party ("Bob") does not send two versions to be propagated and recorded in the blockchain because neither version can effectively redeem the first transaction. He sends his preferred second version to be propagated and recorded, but the fact that the first version exists allows him to fall back to recording the first version if the necessary conditions for the second version are not met.

[0014] For example, in a first exemplary use case, the first transaction ("Tx1") involves a first party ("Alice") paying for services provided by a second party ("Bob"). The first transaction can be created by Alice, Bob, or a third party. It may already be on the chain or sent to be recorded later. Either way, the locking script in the output of the first transaction specifies at least two alternative conditions (i.e., a first condition and a second condition) for unlocking the payment defined in that output. 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 requiring a large amount of predefined data or a piece of sensitive or private data of Bob (which Bob does not want to publish on the blockchain) to be included in the unlocking script. The second condition requires Alice's signature to be included in the unlocking script of the target transaction, but does not impose the onerous requirements of the first condition.

[0015] Alice also provides Bob with a first version of the target transaction ("Tx p "), either created by Bob himself (or by a third party). The first version is configured to unlock the output of the first transaction Tx1 based on the first condition, while the second version ("Tx p ’") will be configured to unlock based on the second condition. Then, Bob provides the services. If Alice is satisfied and honest, then in response, she provides Bob with the second version of the target transaction Tx p ’, including her signature (or at least provides her signature to Bob or a third party to assemble into the second version). But if Alice breaches the agreement, Bob can still choose to send the existing, less preferred first version Tx p in order to redeem the output of the first transaction Tx1 according to this less preferred first condition.

[0016] In a second exemplary use case, the method may include, via the second party's computing device: streaming a sequence of data portions to the first party, ending with a final portion in the sequence; in response to each respective portion of the data portions, receiving back from the first party a respective instance of the first transaction, the first output of each instance specifying a payment to the second party for the respective portion; wherein the payment increases with each additional data portion (e.g., the increase is linearly proportional to the number of data portions sent so far). In such embodiments, obtaining an updated version of the target transaction includes receiving the updated version from the first party after the final portion in the sequence.

[0017] For example, each data portion may be a different portion of a media content item (e.g., audio and / or video content). Alternatively, each data portion is a different key for accessing a service unit (such as utilities like gas, water, electricity; or rental property, vehicle, or other physical goods).

[0018] Instances of the first transaction (Tx1, Tx2, Tx3...) will be recognized by each node of the network as instances of essentially the same transaction, e.g., because the first output has the same output identifier (e.g., UTXO identifier) in each instance. Thus, only one instance can be recorded on the blockchain. Once an instance is accepted as valid by any given node, any attempt to record it as the next version will be considered invalid and thus rejected by that node. Additionally, once an instance of the first transaction is found to be validly redeemed by one of the versions of the target transaction (Tx p or Tx p ’) on any given node, any other target transaction attempting to redeem any instance of the first transaction will be considered invalid by that node and thus will not be propagated or recorded on the blockchain by that node.

[0019] Because any version of the target transaction (Tx p or Tx p ’) will point to the same output ID of essentially the same instance of the first transaction (just defining different amounts), only one target transaction can effectively redeem that output. Once an instance of the first transaction (Tx1, Tx2, Tx3...) is found to be validly redeemed by one of the versions of the target transaction (Tx p or Tx p ’) on any given node, any other target transaction attempting to redeem any instance of the first transaction will be considered invalid and thus will not be propagated or recorded on the blockchain by that node. Nevertheless, because the payment in each instance also increases with each exchange of a portion of data, all the second party (“Bob”) has to do is send the target transaction Tx pA version of ’ to redeem the first transaction Tx intended to be propagated and recorded in the blockchain n The last or most recent instance. Then, he will receive full payment based on all the data parts sent up to that point in a single pair of transactions. On the contrary, if the first party (“Alice”) sends separate payments for each data part, this will cause the blockchain to bloat and result in more network traffic, because Bob will have to send separate transactions for each data part (e.g., each data packet or chunk of audio or video content).

[0020] If Alice stops sending instances of the first transaction (Tx1, Tx2, Tx3, …) at any point before the end of the sequence, Bob can still choose to stop sending more data parts to Alice and send the first version of the target transaction Tx p To the network to redeem the payments for the data parts sent before that point (thus only losing the latest data part sent). On the contrary, if Bob stops sending data parts at any point, Alice can choose to stop sending more instances of the first transaction Tx1, and Bob will only be able to redeem the payments for the data parts received by Alice so far.

[0021] In a particular optional 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 such that the total amount of the payments is greater than the input amount, where the first transaction received by the second party from the first party does not include other inputs to make up the difference. If the specified total payment is greater than the total input amount, the nodes of the network will reject the first transaction as invalid. In such embodiments, the method includes the second party adding a second input to the final 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.

[0022] As an exemplary embodiment of the method, the further outputs include a second output and a third output. The second output specifies a second payment equal to the input amount minus the first payment to be paid to the first party, and the third output specifies a third payment equal to the second payment to be paid to the second party.

[0023] Such embodiments can prevent the first party (“Alice”) from cheating the system by sending her own target transaction to redeem an earlier instance, thus preventing Bob from redeeming a later instance (or indeed any instance), because when doing so Alice has to add additional inputs, thus generating more digital assets. Therefore, it is not worth Alice cheating the system.

[0024] In another exemplary use case, each of at least some of the alternative conditions may correspond to a different voting option, and the method may include, prior to obtaining an updated version of the target transaction: accessing or making accessible to a third party an unlocking script in a first version as a non-binding indication of a voting intention. If the polling indication is never truly converted into a vote, the first version may remain as the polling indication to illustrate how the polling differs from the final vote result.

[0025] According to yet another aspect disclosed herein, there is provided a program for performing the method, and / or a computer device of a second party programmed to perform the method. The program or computer device may be configured to enable the second party to selectively send either a first or a second version intended to be propagated over a network and recorded in a blockchain, either by a manual option to select either version, and / or by an automatic function configured to automatically send the first version upon a first event and further configured to automatically send the second version intended to be propagated and recorded, rather than the second version, upon a second event. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0027] Figure 1 is a schematic block diagram of a system implementing a blockchain,

[0028] Figure 2 schematically shows some examples of transactions that may be recorded in a blockchain,

[0029] Figure 3 is a schematic block diagram of another system implementing a blockchain,

[0030] Figure 4 is a schematic block diagram of a client application,

[0031] Figure 5 is by Figure 4 a schematic model of an exemplary user interface that may be represented by the client application of,

[0032] Figure 6 is a schematic diagram of a set of transactions,

[0033] Figure 7 is a signaling diagram showing a method of streaming data,

[0034] Figure 8 is shown in Figure 7 a graph of the input and output values of an instance of a first transaction in an exemplary implementation of the method of,

[0035] Figure 9 is in Figure 7The exemplary transaction format of the first transaction in the method,

[0036] Figure 10 is a signaling diagram showing a voting method,

[0037] Figure 11 showing a set of exemplary transactions for implementing Figure 10 the method. Detailed implementation

[0038] Malleability is an existing concept in cryptography and is related to security issues. Using malleability, a message can be maliciously modified but still be accepted as authentic. Digital signature schemes aim to solve this problem. However, in blockchain, malleability refers to the ability to modify at least a part of a transaction without invalidating the entire transaction. There is no possibility of malleability for any information in a transaction signed with a relevant form of cryptographic signature (such as an ECDSA signature). Any security issues related to malleability are caused by improper implementation methods rather than the protocol itself.

[0039] Below, we will explore how malleability, as a useful feature, can promote fast, secure, and trustless payment channels. The specific idea is to determine which part or parts of a transaction do not or do not have to be signed (e.g., by an ECDSA signature). The disclosed scheme will utilize the fact that nothing in the unlocking script (e.g., the'scriptSig' field) of each input of a transaction has any signature. Embodiments can also utilize the SIGHASH flag, making it more flexible to modify a transaction without invalidating it.

[0040] Here is an example. When data is exchanged on a blockchain, a common practice is to use a hash puzzle to prompt the display of data and the agreement to pay simultaneously. To avoid this, a transaction can be constructed to require payment such that only one of the following two conditions needs to be met: i) provide "data + Bob's signature"; or ii) provide "Alice's signature + Bob's signature".

[0041] Bob will request payment by constructing a transaction with the provided data and his signature and sending the transaction to Alice. Then, Alice 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. In either case, since the data does not form part of the message signed by Bob, replacing the data with Alice's signature will not invalidate the transaction. Additionally, since the input satisfies condition ii), the transaction remains valid. If Alice does not broadcast the transaction to the network or provide her signature, then Bob can still broadcast the original transaction to request payment in accordance with condition i) (this is not preferred since Bob has to upload a significant amount of data and / or proprietary data). Alice can be encouraged to provide her signature by way of requesting confirmation, discount incentives, or by rewarding Bob for good service provided by him.

[0042] System Overview

[0043] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. System 100 includes a packet-switched network 101, typically a wide-area internet such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 that are arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each node 104 includes processing means having one or more processors, such as 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, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units that employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable read-only memory, and / or optical media such as optical disk drives.

[0044] The blockchain 150 includes a series of data blocks 151, and each of the more than 160 nodes in the P2P network 160 maintains a corresponding copy of the blockchain 150. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses a specific transaction protocol throughout. In a common 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 value of the digital assets belonging to the user 103 whose output is cryptographically locked (requiring the signature of the user to unlock and thus redeem or spend). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0045] At least some of the nodes 104 act as forwarding nodes 104F, which forward and thus propagate the transactions 152. At least some of the nodes 104 act as storage nodes 104S (sometimes also referred to as "full copy" nodes), and each storage node stores a corresponding copy of the same blockchain 150 in a corresponding memory. A given node 104 can be a forwarding node 104, a storage node 104S, or any combination of the nodes therein.

[0046] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Generally speaking, the previous transaction can be any transaction in the pool 154 or any block 151. To ensure the validity of the current transaction, the previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be valid. Therefore, "previous" in this article refers to the earlier stage in the logical sequence connected by pointers, not necessarily the time of creation or sending in the time sequence. Therefore, it does not necessarily exclude the possibility that the transactions 152i, 152j are created or sent in an unordered manner (see the description of orphan transactions below). The previous transaction 152i can also be referred to as the antecedent or earlier transaction.

[0047] The input of the current transaction 152j also includes the signature of user 103a whose output in the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be encrypted and locked to the new user 103b. Thus, the current transaction 152j can transfer the 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, transaction 152 can have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for changes). In some cases, the transaction can also have multiple inputs to aggregate the amounts of multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0048] The above can be referred to as an "output-based" transaction protocol, sometimes also called an unspent transaction output (UTXO)-type protocol (where the output is called a UTXO). The total balance of a user is not defined by any one number stored in the blockchain; instead, the user requires a special "wallet" application 105 to collate all the UTXO values of that user, which are scattered across many different transactions 152 in the blockchain 151.

[0049] As part of the account-based transaction model, another type of transaction protocol can be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the transferred amount by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored separately in the blockchain and continuously updated. This disclosure relates to an output-based model rather than an account-based model.

[0050] Regardless of the type of transaction protocol adopted, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to a node 104 of the P2P network 106 (which is now typically a server or data center, but in principle could be another user terminal). This node 104 checks whether the transaction is valid according to the node protocol applied to each node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the overall transaction model. The node protocol typically requires the node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In an output-based case, this can include checking whether the user cryptographic signature included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i that the new transaction spends, where the conditions typically include at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i pointed to by the input of the new transaction. In some transaction protocols, the conditions can be defined at least in part by custom scripts included in the input and / or output. Alternatively, this can be fixed solely by the node protocol, or can be fixed by their combination. Whichever way it is done, 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 and apply the same test according to the same node protocol, thus forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction spreads throughout the network of nodes 104.

[0051] In an output-based model, the definition of whether a given output (e.g., UTXO) is spent is that, according to the node protocol, whether it is validly redeemed by the input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to spend or redeem has not been spent / redeemed by another valid transaction. Similarly, if invalid, the transaction 152j will not be spread or recorded in the blockchain. This prevents double spending, i.e., a spender spending the output of the same transaction more than once.

[0052] Once created, the block 151 cannot be modified because it is identified and maintained at each storage node 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes an order on the block 151. Since the transactions 152 are recorded in the ordered blocks at each storage node 104S of the P2P network 106, an immutable public ledger of transactions is provided.

[0053] Each forwarding node 104M and / or storage node 104S may take the form of a server or a data center. However, in principle, any given node 104 may take the form of a user terminal or a group of networked user terminals.

[0054] The memory of each node 104 stores software configured to run on the processing device of the node 104 to perform its corresponding role and process transactions 152 according to the node protocol. It should be understood that any action of the node 104 herein can be performed by software running on the processing device of the corresponding computer device. In addition, the term "blockchain" herein refers to a general term for a general technical type and is not limited to any specific proprietary blockchain, protocol, or service.

[0055] Also connected to the network 101 are the computer devices 102 of each party 103 in the role of consumer users. They act as payers and payees in the transaction, but do not necessarily participate in the dissemination of the transaction on behalf of other parties. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: the first party 103a and its corresponding computer device 102a, and the second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for the sake of convenience, they are not shown. Each party 103 may be an individual or an organization. For illustrative purposes, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob herein, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein can be replaced by "the first party" and "the second party" respectively.

[0056] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more central processing units, central processing units, other accelerator processors, application-specific processors, and / or field-programmable gate arrays. The computer device 102 of each party 103 also includes a memory, namely a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which employ one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives, flash memory, or electrically erasable read-only memory, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores a corresponding instance that includes at least one client application 105 configured to run on the processing device. It should be understood that any action of a given party 103 herein can be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0057] The client application or software 105 can initially be provided to the computer device 102 of any given party 103 through a suitable computer-readable storage medium, such as downloaded from a server, or provided on a mobile storage device, such as a removable solid-state drive, a flash drive, a removable electrically erasable read-only memory, a removable disk drive, a floppy disk, or a magnetic tape, an optical disk (such as a CD or DVD ROM), or a removable optical drive.

[0058] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user party 103 to create, sign, and send transactions 152 intended to be propagated throughout the node network 104 and thus included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various 152 transactions belonging to the relevant party scattered in the blockchain 150.

[0059] An instance of the client application 105 on each computer device 102 is operatively coupled to at least one forwarding node 104F of the P2P network 106. This enables the wallet functionality of the client 105 to send transactions 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 for which the corresponding party 103 is the recipient (or actually check other party transactions in the blockchain 150, since in an embodiment the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. Each node 104 runs software configured to verify the transaction 152 according to a node protocol in the case where the forwarding node 104F forwards the transaction 152 for propagation across the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in the blockchain 150 employ the same transaction protocol (although the transaction protocol may allow different transaction subtypes within it). All nodes 104 in the network 106 employ the same node protocol (although it may distinguish between different transaction subtypes according to the rules of the subtype, and different nodes may also play different roles, thus implementing different corresponding aspects of the protocol).

[0060] As previously described, the blockchain 150 includes a series of blocks 151, where each block 151 includes a set of one or more transactions 152 that have been created. Each block 151 also includes a block pointer 155 that points to the previously created block 151 in the chain to define the order of the blocks 151. The blockchain 150 also includes a valid transaction pool 154 that awaits inclusion in a new block. Each transaction 152 includes a pointer to the previous transaction to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The chain of blocks 151 extends back to the genesis block (Gb) 153, which is the first block in the chain. One or more original transactions 152 in the early blockchain 150 point to the genesis block 153, rather than a previous transaction.

[0061] When a given party 103 (say, Alice) wishes to send a new transaction 152j intended to be included in the blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which it is connected. For example, this could 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 corresponding role. This includes first checking whether the newly received transaction 152j meets certain specific conditions for being "valid", specific examples of which will be described in detail later. In some transaction protocols, the verification conditions can be configured on a per-transaction basis via the script included in the transaction 152. Alternatively, the conditions can be simply a built-in function of the node protocol, or defined by a combination of the script and the node protocol.

[0062] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "verified"), any storage node 104S that receives the transaction 152j will add the newly verified transaction 152 to the pool 154 of the copy of the blockchain 150 maintained by the node 104S. Further, any forwarding node 104F that receives the transaction 152j will subsequently propagate the verified transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means the transaction will quickly be propagated through the entire P2P network 106.

[0063] Figure 2 An exemplary transaction protocol is shown. This is an example based on the UTXO protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following description refers to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments.

[0064] 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 can include an unspent transaction output (UTXO), which can be used as a source of inputs 202 for another new transaction (if the UTXO has not been redeemed). The UTXO specifies the amount of digital assets (a means of storing value). It can also contain the transaction ID of its source transaction and other information. The transaction data structure can include a header 201, which can include size indicators for the input field 202 and the output field 203. The header 201 can also include the ID of the transaction. In an embodiment, the transaction ID is the hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152.

[0065] That is, Alice 103a wishes to create a transaction 152j that transfers a digital asset amount related to the transfer to Bob 103b. In Figure 2 this, Alice's new transaction 152j is labeled "Tx1". It obtains the digital asset amount locked to Alice in the output 203 of the previous transaction 152j in the sequence and transfers at least a portion of such amount to Bob. Figure 2 The previous transaction 152j in is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels. It does not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to the next transaction in the pool 154. Tx1 can point to any previous (i.e., antecedent) transaction that still has an unspent output 203 locked to Alice.

[0066] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already have been verified and included in the blockchain 150. At this time, it may already be included in a block 151, or it may still be waiting in the pool 154, in which case it will soon be included in a new block 151. Alternatively, Tx0 and Tx1 can be created and sent to the network 102 together, or if the node protocol allows buffering "orphan" transactions, Tx0 can even be sent after Tx1. The terms "previous" and "subsequent" used in the context of the transaction order in this article refer to the transaction order in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can equally be replaced by words such as "earlier" and "later", "antecedent" and "successor", "ancestor" and "descendant", or the like. This does not necessarily refer to the order in which they are created, sent to the network 106, or reach any given node 104. However, a subsequent transaction (successor transaction or "child transaction") that points to a previous transaction (antecedent transaction or "parent transaction") will not be verified until the parent transaction is verified. A child transaction that arrives at the node 104 before the parent transaction is considered an orphan transaction. According to the node protocol, it can be discarded or buffered for a period of time to wait for the parent transaction.

[0067] One of the outputs 203 of one or more of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value representing the digital asset amount specified by the UTXO and a locking script that defines the conditions that the unlocking script in the subsequent transaction input 202 must satisfy for the subsequent transaction to be verified and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which generally include the following conditions: the unlocking script in the subsequent transaction input includes the cryptographic signature of the party to whom the previous transaction was locked.

[0068] The locking script (also known as scriptPubKey) is a piece of code written in a domain - specific language recognized by the node protocol. Specific examples of such languages are called "Script" (with a capital 'S'). The locking script specifies the information required to spend a transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of a transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain - specific language that provides the information required to meet the criteria of the locking script. For example, it may contain Bob's signature. The unlocking script appears in the input 202 of a transaction.

[0069] So in the example shown, the UTXO0 in the Tx0 output 203 includes the locking script [Checksig P A , which requires Alice's signature Sig P A to redeem UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem UTXO0 valid). [Checksig P A includes the public key P in Alice's public - private key pair A . The input 202 of Tx1 includes a pointer to Tx1 (e.g., via its transaction ID (TxID0), which in an embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes the unlocking script <Sig P A >, which includes Alice's cryptographic signature, created by Alice applying the private key in her key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") for which Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0070] When the new transaction Tx1 arrives at node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check if the unlocking script meets the conditions defined in the locking script (where the conditions can include one or more criteria). In an embodiment, this involves juxtaposing the two scripts:

[0071] <Sig P A ><P A >||[Checksig P A

[0072] where "||" represents juxtaposition, "<…>" represents pushing data onto the stack, and "[…]" represents a function composed of the unlocking script (in this example, a stack - based language). Similarly, using a normal stack, the scripts can run continuously instead of concatenating the scripts. Either way, when run together, the scripts use Alice's public key P​A (Included in the locking script output by Tx0) to verify whether the locking script in the Tx1 input contains the signature when Alice signs the expected partial data. The expected partial data itself ("message") also needs to be included in Tx0 to perform this verification. In an embodiment, the signed data includes the entire Tx0 (so a separate element is needed to specify the signed partial data in plain text as it already exists).

[0073] Those skilled in the art will be familiar with the details of verification through public-private cryptography. Basically, if Alice has signed a message by encrypting it using her private key, given Alice's public key and the message in the plain text (the unencrypted message), other entities such as node 104 can verify that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and attaching this to the plain text version of the message as a signature, so that any holder of the public key can verify the signature. Therefore, it should be noted that when a signature of a specific data fragment, part of a transaction, or the like is mentioned herein, it may mean signing the hash value of that data fragment or part of the transaction.

[0074] If the unlocking script in Tx1 meets one or more conditions specified in the locking script of Tx0 (so, in the example shown, if Alice's signature is provided and verified in Tx1), then node 104 considers Tx1 valid. If it is storage node 104S, this means it will be added to transaction pool 154. If it is forwarding node 104F, then it will forward transaction Tx1 to one or more other nodes 104 in network 106, and thus it will be propagated throughout the network. Once Tx1 is verified and included in blockchain 150, this will define UTXO0 in Tx0 as spent. Note that Tx1 is only valid when spending an unspent transaction output 203. If an attempt is made to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been spent (has formed a valid input for another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transactions 152 is important. In practice, a given node 104 can maintain a separate database to mark the UTXO 203 of spent transactions 152, but ultimately whether a UTXO has been spent depends on whether a valid input for another valid transaction has been formed in blockchain 150.

[0075] Note that in a UTXO-based transaction model, a given UTXO needs to be used as a whole. It is not possible to "leave" a portion of the amount defined as spent in a UTXO while spending another portion. However, the amount of a UTXO can be split among multiple outputs in the next transaction. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remainder to give herself change in the second output of Tx1, or pay it to another party.

[0076] Also, it should be noted that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all of its inputs 202, then the transaction is invalid in most transaction models. Thus, such a transaction will not be propagated.

[0077] The digital assets of Alice and Bob consist of unspent UTXOs locked in any of their transactions 152 in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. The total balance of a given party 103 is not defined anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate together the different UTXO values locked to the corresponding party and not yet spent in other subsequent transactions. This can be achieved by querying a copy of the blockchain 150 stored in any storage node 104S, such as the storage node 104S that is closest or best connected to the computer device 102 of the corresponding party.

[0078] Note that script code is typically represented schematically (i.e., in non-exact language). For example, writing [ChecksigP A means [Checksig P A = OP_DUP OP_HASH160<H(P A )>OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to specific opcodes of the script language. OP_CHECKSIG (also known as "Checksig") is a script opcode that takes two inputs (a signature and a public key) and uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to verify the validity of the signature. At runtime, any occurrence of the signature ('sig') in the script is removed, but additional requirements such as hash puzzles remain in the transaction verified by the'sig' input. Another example is OP_RETURN, which is a script language opcode used to create an unspendable output of a transaction, which can store metadata in the transaction, thereby recording the metadata immutably in the blockchain 150. For example, the metadata can include a file to be stored in the blockchain.

[0079] Signature PA is a digital signature. In an embodiment, this is based on the Elliptic Curve Digital Signature Algorithm using the elliptic curve secp256k1. The digital signature signs a specific data segment. In an embodiment, for a given transaction, the signature will sign part of the transaction input, all or part of the transaction output. Which specific part of the output it signs depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature that is used to select the output to be signed (and thus fixed at the time of signing).

[0080] The locking script, sometimes referred to as "scriptPubKey", means that it includes the public key of the locking party of the corresponding transaction. The unlocking script, sometimes referred to as "scriptSig", means that it provides the corresponding signature. But more generally, in all applications of the blockchain 150, the conditions for UTXO redemption do not necessarily include verifying the signature. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" can be preferably used.

[0081] Figure 3 shows a system 100 for implementing the blockchain 150. Except for additional communication functions, this system 100 is substantially the same as Figure 1 that shown. The client applications on each of Alice's and Bob's computer devices 102a, 120b respectively include additional communication functions. That is to say, this enables Alice 103a to establish a separate side channel 301 with Bob 103b (at the instigation of either party or a third party). The side channel 301 is capable of implementing data exchange independently of the P2P network. Such communications are sometimes referred to as "off-chain" communications. For example, when exchanging the transaction 152 between Alice and Bob and not wanting to publish the transaction (yet) to the P2P network 106 or have it enter the blockchain 150, such communications can be employed until one of the parties chooses to broadcast the transaction to the network 106. Such side channels 301 are sometimes used as, for example, "payment channels".

[0082] A side channel 301 can be established through the same packet-switching network 101 as the P2P overlay network 106. Additionally / or, a side channel 301 can be established through a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between the devices 102a, 102b of Alice and Bob. Generally speaking, the side channel 301 referred to herein can include any one or more links via one or more networking technologies or communication media for "off-chain" (i.e., independent of the P2P overlay network 106) data exchange. In the case where multiple links are used, the bundling or set of the entire off-chain links can be referred to as the side channel 301. Therefore, it should be noted that although Alice and Bob exchange specific information or data fragments or the like through the side channel 301, this does not necessarily mean that all these data fragments must be sent through the same link or even the same type of network.

[0083] Exemplary Definitions

[0084] The following are exemplary definitions that may be adopted in some embodiments. Note that these exemplary definitions do not completely limit all possible embodiments, but are only for helping to understand specific possible embodiments, such as the definitions that may be used in some possible embodiments of the exemplary use cases described below.

[0085] Definition 1: Transaction. A transaction refers to a message that contains inputs and outputs. It can also include a protocol version number and / or a lock time. The protocol version refers to the version of the transaction protocol. The lock time will be explained separately later.

[0086] Definition 2: Input. The inputs of a transaction form an ordered list. Each entry in this list contains an output point (the identifier of an unspent transaction output) and a scriptSig (the unlocking script). It can also include a sequence number.

[0087] Definition 3: Output. The outputs of a transaction form an ordered list. Each entry in this list contains a value (the amount of digital assets represented in basic units) and a scriptPubKey (the locking script).

[0088] Definition 4: Output Point. An output point is uniquely defined by a transaction ID TxID and an index number i. It refers to the i-th entry in the outputs of the transaction TxID, representing the unique location of an unspent transaction output (UTXO). Here, the term "unspent" means that the output point has never appeared in any valid subsequent transaction.

[0089] Definition 5: scriptSig. This is the information required to unlock or spend the UTXO corresponding to a given output point. In a standard transaction, this information typically refers to an ECDSA signature. Hence, this script is called'scriptSig'. However, the information required to unlock an output point can be any data that satisfies the UTXO locking conditions.

[0090] Definition 6: scriptPubKey. This refers to the script that locks the funds associated with a specific UTXO. The funds can be unlocked and spent if and only if the scriptSig is added to the scriptPubKey and the execution of the combined script evaluates to TRUE. If this is not the case, then the transaction is invalid and will be rejected. Since this script typically contains the hash value of the ECDSA public key for a standard transaction, it is called the "scriptPubKey".

[0091] In the next definition, if an input is referred to as being signed, it means signing the input excluding the scriptSig part (see Definition 2).

[0092] Definition 7: SIGHASH flag. When providing an ECDSA signature, one of the following SIGHASH flags also needs to be added.

[0093]

[0094] When discussing malleability as a feature, look for information in transactions that are not signed via an ECDSA signature. The content of the scriptSig is always excluded, except for inputs and outputs that can be excluded from the message to be signed. This is because the scriptSig is designed to be a placeholder for the signature.

[0095] Definition 8: Blockchain timelock. Generally speaking, two types of timelocks can be used in a transaction: absolute timelock and relative timelock. An absolute timelock specifies a specific point in time, and some information that occurs after this point in time is considered valid; while a relative timelock specifies a time period, and some information that occurs after this time period is considered valid. In both cases, when using a blockchain timelock, the block height (the number of blocks mined) or the elapsed time (e.g., UNIX time) can be used to proxy time.

[0096] Another property of blockchain timelocks lies in their location and the aspects of the transaction to which they apply. In this sense, timelocks can be further divided into two categories: transaction-level timelocks, which are used to lock the entire transaction; and script-level timelocks, which are used to unlock specific outputs. Both categories of timelocks can be used to implement absolute or relative timelocks. The following table summarizes the four mechanisms by which timelocks can be created based on the above properties.

[0097]

[0098] Definition 9: nLocktime. The locktime (nLocktime) is a non - negative integer that represents a block height or a specific Unix time. If a transaction can only be added to the blockchain after a specified block or a specified time, then in this sense, it is a transaction - level time lock. If nLocktime is set to less than 500,000,000, it is regarded as a block height. If it is set to be equal to or greater than 500,000,000, it is regarded as representing Unix time. That is, the number of seconds after 00:00:00 on January 1, 1970.

[0099] Definition 10: nSequence. The sequence number (nSequence) is a message that represents the transaction version. Modifying a transaction increases the sequence number. The maximum value of nSequence is 2 32 -1, and generally speaking, the sequence number will be default set to this maximum value to indicate that the transaction is complete. Each input of a transaction defines an nSequence value, which specifies the time period required after the UTXO referred to by the input is included in a block until the input can be used as a valid input. However, this feature is usually disabled.

[0100] Definition 11: CheckLockTimeVerify (OP_CLTV). The OP_CHECKLOCKTIMEVERIFY (OP_CLTV) opcode is a script - level absolute time lock that can be used to lock a specific output of a transaction at a specific future time or block height. If the current Unix time or block height when the UTXO is referred to in a transaction is less than the Unix time or block height when the UTXO was created and the parameter specified before the OP_CLTV opcode, then the execution of the script that spends the transaction will fail.

[0101] Definition 12: CheckSequenceVerify (OP_CSV). The OP_CHECKSEQUENCEVERIFY (OP_CSV) opcode is a script - level relative time lock that can be used to lock a specific output of a transaction for a specific future time period or number of blocks. Its operation is similar to that of OP_CLTV, except that the parameter provided to OP_CSV represents relative time. If the current Unix time or block height when the UTXO is referred to in a transaction is less than the Unix time or block height when the UTXO was created and the parameter specified before the OP_CSV opcode, then the execution of the script that spends the transaction will fail.

[0102] Definition 13: Malleability. Generally speaking, blockchain transactions can have two broad categories of malleability, both of which allow the modification of the transaction content without invalidating the signatures provided in the inputs.

[0103] To illustrate these two categories, consider the first transaction Tx, which contains one input, one signature in that input, and one output.

[0104] Category 1: Script-level malleability. This type of malleability exploits the fact that the signature to be checked using the script opcode OP_CHECKSIG does not sign the script field of any input in the transaction. This fact allows us to generate a signature on transaction Tx, modify the input script such that transaction Tx′ is not equivalent to Tx, and still consider both Tx and Tx′ as valid transaction messages signed by the same signature under the blockchain consensus rules.

[0105] Category 2: Input-output-level malleability. This type of malleability relies on the use of SIGHASH flags instead of SIGHASH ALL used in the transaction. If transaction Tx has an input signature and that signature uses any one of the other five SIGHASH flag combinations, then inputs or outputs can be added to create a non-equivalent transaction Tx′ such that both will be considered valid transaction messages under the consensus rules without modifying the signature.

[0106] Malleability characteristics

[0107] Figure 4 An exemplary implementation of the client application 105 for implementing the embodiments of the present disclosure is shown. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. According to the solutions discussed above and those to be further detailed later, the transaction engine 401 is configured to implement the basic transaction-related functions of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data through the side channel 301, and / or sending transactions to be propagated through the P2P network 106. In accordance with the embodiments disclosed herein, at least the transaction engine 401 of Bob's client 105b includes an application function 403 in the form of a selection function, which is capable of selecting which one of two or more different versions of the target transaction (“Tx p ” and “Tx p ’”) to send for verification through the P2P network 106 and thus recorded in the blockchain 150 (the propagation and recording themselves are implemented through the mechanisms discussed earlier). It should be noted again that this sending can include directly sending the target transaction from Bob's computer device 102b to one of the forwarding nodes 104F of the network 106, or sending the target transaction to Alice's device 102b or a third party's device for forwarding to one of the nodes 104F of the network 106.

[0108] The UI layer 402 is configured to present a user interface through the user input / output (I / O) means of the corresponding user's computer device 102, including outputting information to the corresponding user 103 through the user output means of device 102, and receiving input from the corresponding user 103 through the user input means of device 102. For example, the user output means may include one or more display screens (touch or non-touch screens) 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, an input array of one or more touch screens (the same or different from those for the output means); one or more cursor-based devices such as a mouse, a trackpad, or a trackball; one or more microphones and speech or voice recognition algorithms for receiving speech or voice input; one or more gesture-based input devices for receiving input in the form of manual or body gestures; or one or more mechanical buttons, switches, or joysticks, etc.

[0109] Note: Although various functions in this article can be described as integrated into the same client application 105, this does not necessarily constitute a limitation. On the contrary, they can be implemented in a set of two or more different applications, for example, one being a plugin of the other. For example, the functions of the trading engine 401 can be implemented in a separate application rather than in the UI layer 402, or the functions of a given module such as the trading engine 401 can be split among multiple applications. At the same time, it is not excluded to assume that some or all of the described functions can be implemented at, for example, the operating system layer. In any case where a single or a given application 105 or the like is referred to herein, it should be understood that this is only for example, and more generally, the described functions can be implemented in any form of software.

[0110] Figure 5 A model of an example of a user interface (UI) 500 is given, which can be presented by the UI layer 402 of the client application 105b on Bob's device 102b. The user interface 500 includes at least two user-selectable options 501, 502, which can be presented as two different UI elements through the user output means (such as buttons on two screens) or two different options in a menu. The user input means is set to enable the user 103b (Bob in this case) to select one of the options, such as by clicking or touching the UI element on the screen, or by saying the name of the desired option (note: the term "manual" used in this article is only for comparison with automation and is not limited to the use of hands). It should be understood that the specific way of presenting and selecting options is not important.

[0111] Regardless of the method used, each option corresponds to a different transaction in 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 functions. That is, if Bob 103b selects the first option 501, this will cause 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 502, this will cause 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.

[0112] It should be understood that Figure 5 the UI 500 shown in

[0113] is only an illustrative model and, in practice, it may include one or more further UI elements which are not described for the sake of brevity. p or Tx p ’), the selection function 403 may be configured to perform an automatic selection between sending the first and second versions of the target transaction (Tx p ’), for recording in the blockchain 150. This may be automatically triggered by a predetermined event or after a predetermined timeout. For example, if event Y occurs before the timeout, the function 403 automatically sends the second version Tx p ’ to be propagated through the network 150, but if the timeout occurs before event Y, the function 403 automatically sends the first version Tx p . Or if event X occurs, the function 403 automatically sends the first version Tx p ’ to be propagated through the network 150, but if event Y occurs, the function 403 automatically sends the second version Tx

[0114] Figure 6 A set of transactions 152 used according to an embodiment disclosed herein is shown. The set includes the zero transaction Tx0, the first transaction Tx1 and the second transaction Tx p / Tx pNote that these names are just convenience labels. They do not necessarily mean that these transactions will be placed in block 151 or blockchain 150 immediately one after another, nor does it mean that the zero - th transaction is the initial transaction in block 151 or blockchain 150. These labels do not necessarily imply any information about the order in which their transactions are sent to network 106. They only refer to a logical sequence where the input of the next transaction points to the output of a transaction. It should be remembered that in some systems, a parent transaction can be sent to network 106 after its child transactions (in which case, the "orphaned" child transactions will be buffered at one or more nodes 104 for some time while waiting for the parent transaction to arrive).

[0115] If two transactions both contain inputs that reference the same output (e.g., the same UTXO) of a first transaction, then it can be said that the two transactions Tx p or Tx p ’ are multiple versions of (substantially) the same transaction. Different versions can provide different functions by satisfying different unlocking conditions for that output. Different versions can also both contain the same input signature (i.e., the signed messages in either instance are the same). Some embodiments discussed later may also involve different instances of the first transaction Tx i (where i = 1, 2, 3, ……). If two transactions both contain inputs that reference the same output (e.g., UTXO) of the same source transaction (or "zero - th" transaction) Tx0, then it can be said that two (or more) transactions herein are multiple instances of (substantially) the same first transaction. They can redeem that input on the basis of satisfying the same unlocking conditions. However, they can contain different input signatures (i.e., the signed messages in either instance are not the same). Different instances can be used substantially for the same function, but as payments for different corresponding data portions and specify an increased amount of digital assets. This will be discussed in detail later with reference to Figures 7 - 9 and Exemplary Use Case 2.

[0116] The zero - th transaction Tx0 can also be referred to as the source transaction with respect to the present invention because it serves as the source of the amount of digital assets locked to Alice 103a. The first transaction Tx1 can also be referred to as the intermediate transaction or conditional transaction with respect to the present invention because it serves as the intermediary for conditionally transferring the amount of digital assets from the source transaction Tx0. The second transaction Tx p / Tx p ’ can also be referred to as the target transaction or payment transaction (hence the subscript "P") because this transaction will unlock one of the conditions and make a payment to Bob (or the potential beneficiary on behalf of Bob). As mentioned before, the target transaction has two versions, namely the first version Tx p and the second version Tx p’。 These transactions will exist at least at some point in time and be displayed on Alice's computer device 102a (first party), or Bob's (second party) computer device 102b, or a third party's computer device (not shown), or any combination thereof. Two versions Tx p and Tx p ’ can exist simultaneously for some time, or successively, or partially overlap in time.

[0117] As Figure 6 shown, the source transaction Tx0 includes at least one output 2030 (e.g., output 0 of Tx0), which specifies the amount of the digital asset, and further includes a locking script that locks that output to Alice 103a. This means that the locking script of the source transaction Tx0 requires at least one condition to be met, namely that the input of any transaction attempting to unlock the output (and thus redeem the amount of the digital asset) must include Alice's cryptographic signature (i.e., using Alice's public key) in its unlocking script. In this sense, the amount defined in the output of Tx0 can be said to be owned by Alice. This output can be referred to as a UTXO. For the purposes of the present invention, the output of the previous transaction pointed to by the input of Tx0 is not particularly important (as long as it is sufficient to cover the total output of Tx0).

[0118] In this case, the transaction that locks the output of the source transaction Tx0 is the first or intermediate transaction Tx1. Thus, Tx1 has at least one input 2021 (e.g., input 0 of Tx1), which includes a pointer to the relevant output of Tx0 (output 0 of Tx0 in the example shown), and further includes an unlocking script configured to unlock the output pointed to by Tx0 according to the conditions defined in the locking script of that output, which requires at least Alice's signature. The signature of Alice required by the locking script of Tx0 needs to sign a part of Tx1. In some protocols, the part of Tx1 that needs to be signed can be the setting defined in the unlocking script of Tx1. For example, this can be set by the SIGHASH flag, which is appended to the signature and is one byte, so in terms of data, the unlocking script appears as: <Sig P A > <sighashflag><P A >. Alternatively, the part to be signed can be just the fixed part of Tx1. In either case, the part intended to be signed typically does not include the unlocking script itself and may not include some or all of the inputs of Tx1. This means that the inputs of Tx1 are malleable.

[0119] The first or intermediate transaction Tx1 has at least one output 2031 (e.g., output 0 of Tx1, and the output can also be referred to as a UTXO). The output of the intermediate transaction Tx1 is not unconditionally locked to any party. Just like Tx0, which has at least one output (e.g., output 0 of Tx1), designating the amount of digital assets intended to be transferred subsequently, and further includes a locking script that defines what is required to unlock the output and thus redeem the amount. However, this locking script allows unlocking its output based on any one of a plurality of different possible conditions, including at least: i) a first condition ("Condition 1") and ii) a second condition ("Condition 2").

[0120] The second target transaction Tx p / Tx p ’ has at least one input 202p (e.g., output 0 of Tx p / Tx p ’), which includes a pointer to the aforementioned output of Tx1 (output 0 of Tx1, as shown in the example), and the output also includes an unlocking script that is configured to unlock the said output of Tx1 based on satisfying one of the plurality of alternative conditions defined in the locking script of Tx1. In the first version of the target transaction Tx p ’, the unlocking script is configured to satisfy the first condition, i.e., Condition 1. At some point, a second version of the target transaction Tx p ’ will also be created. In the second version, the unlocking script is configured to satisfy the second condition, i.e., Condition 2.

[0121] The second target transaction Tx p / Tx p ’ has at least one output 202p (e.g., output 0 of Tx p / Tx p ’), and in any one version, this output designates the amount of digital assets transferred to Bob and a locking script that locks this to Bob (i.e., requires a further subsequent transaction to include Bob's signature in the unlocking script for spending). In this sense, the output of the target transaction Tx p / Tx p ’ can be said to be owned by Bob. This output can also be referred to as a UTXO.

[0122] In an embodiment, the first condition requires the unlocking script of the transaction attempting to unlock Tx1 (in this case, referring to the first version of the target transaction Tx p ) includes Bob's encrypted signature and / or a data payload in its unlocking script, 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 locking script of Tx1. The challenge includes the hash value of the data (not the data itself) and a piece of script configured to (when run on node 104 together with the unlocking script) test whether the data hash value provided in the corresponding unlocking script is equal to the hash value provided in the locking script. The requirement for a signature can be imposed by, for example, CheckSig discussed previously. In an embodiment, the first condition does not require Alice's signature to be included in the unlocking script of Tx p . The part of Tx p that needs to be signed by Bob can be the setting of the unlocking script of Tx p (specified by, for example, the SIGHASH flag), or it can be fixed. Either way, it does not include the unlocking script at least. Therefore, the unlocking script of Tx p is malleable.

[0123] In an embodiment, the second condition requires that the unlocking script of the transaction attempting to unlock Tx1 (in this case, referring to the second version Tx p ') includes Bob's encrypted signature and Alice's encrypted signature in its unlocking script. Again, this can be imposed by, for example, CheckSig. In an embodiment, the first condition does not require the data payload to be included in the unlocking script of Tx p '. The part of Tx p ' that needs to be signed by Alice and Bob can be the setting of the unlocking script of Tx p ' (specified by, for example, the SIGHASH flag), or it can be fixed.

[0124] The zeroth transaction (i.e., the source transaction) Tx0 can be generated by Alice, Bob, or a third party. It usually requires a previous signature, and Alice obtains the amount defined in the input of Tx0 from that previous party. It can be sent to network 106 by Alice, Bob, the previous party, or other third parties.

[0125] The first transaction (i.e., the intermediate transaction and the conditional transaction) Tx1 can also be generated by Alice, Bob, or a third party. Since Alice's signature is required in the embodiment, it can be generated by Alice. Alternatively, it can be generated by Bob or a third party as a template and then sent to Alice for signature, e.g., sent via side channel 301. Then, Alice can send the signed transaction to network 106 herself, or send it to Bob or a third party for them to forward to network 106, or only send her signature for Bob or a third party to assemble into the signed Tx1 and forward to network 106. Similarly, any off-chain exchange before sending Tx1 to network 106 can be performed via side channel 301.

[0126] The second transaction (i.e., the target transaction or the payment transaction) Tx p / Tx p 's any version can be generated by Alice, Bob, or a third party. Since the first version requires Bob's signature and / or data, it can be generated by Bob. Alternatively, it can be generated by Alice or a third party as a template and then sent to Bob for signature and adding data, e.g., sent to Bob via side channel 301. Then, Bob can send the signed transaction to network 106 himself, or send it to Alice or a third party for them to forward to network 106, or only send his signature and data for Alice or a third party to assemble into the signed Tx p and forward to the network. In an embodiment, the second version requires the signatures of both Bob and Alice. Therefore, it can be generated by Alice or Bob as a template and sent to the other party as a template to add their signatures, e.g., also via side channel 301. Alternatively, it can be generated by a third party as a template and then sent to Alice, where Alice adds her signature and forwards it to Bob to add his signature. Then, Bob forwards the signed transaction to network 106, or sends it back to Alice or a third party for them to forward to network 106. Alternatively, Tx p ' can be generated by a third party as a template and then sent to Bob, where Bob adds his signature and then forwards it to Alice to add her signature. Then, Alice forwards the signed transaction to network 106, or sends it back to Bob or a third party for them to forward to network 106. In a further variant, Alice and / or Bob sign the received transaction template and only return their signature to one of the other parties for that party to assemble into Tx p ' and forward to network 106. Similarly, any off-chain exchange before sending Tx p and / or Tx p ' to network 106 can be performed via side channel 301.

[0127] It should be understood that there are multiple locations where different elements of a transaction can be generated and assembled, and various methods for subsequently sending them directly or indirectly to the ultimate destination of the P2P network 106. The scope of the embodiments of the disclosed technology is not limited to any one of these aspects.

[0128] It should also be understood that phrases such as "by Alice", "by Bob", and "by a third party" herein can be used as abbreviations for "by the computer device 102a of Alice 103a", "by the computer device 102b of Bob 103b", and "by the computer device of a third party", respectively. Additionally, it should be noted again that the device of a given party can include one or more user devices used by that party, or server resources such as cloud resources used by that party, or any combination thereof. This does not necessarily limit the actions performed on a single user device.

[0129] Because the unlocking script of the target transaction Tx p is malleable, in an embodiment, a second version Tx p ' of the target transaction can be generated by malleating the first version Tx p , that is, by adopting the existing data structure of Tx p and modifying it to form the second version Tx p ' (in this case, by malleating the locking script). This is an example of script-level malleability. However, in an equivalent variant, Tx p ' can be generated by creating a new version of the target transaction with the same structure, except for a different unlocking script. The term "update" can be used herein as a general term to describe the possibility of malleating an existing structure or creating a new replacement version. Malleability can be referred to in multiple embodiments herein by way of example, but it should be understood that this can be replaced by creating a new version of the target transaction from scratch. Whichever way is adopted, the malleation or creation of the new version can be performed by Alice and / or Bob and / or a third party in view of the signatures of Alice and / or Bob.

[0130] In some embodiments, the locking script of Tx1 can include a third unlocking condition as an alternative to the first and second conditions. The third condition can require that the lock time has expired and that Alice's signature is included in the unlocking script of the third version Tx p " of the target transaction. If Bob does not make a claim based on any of the first and second conditions, this enables Alice to recover her payment from the output of Tx1 (e.g., because he is not involved in the process at all or does not participate within the specified time limit). The lock time can be defined as an absolute point in time or a period of time that is intended to have passed, for example, measured in seconds.

[0131] Exemplary Use Case 1 - Security for Bob

[0132] As described above, in the embodiment, in Tx1, the first condition i) requires that Bob's signature and the data payload be included in the unlocking script of Tx, but not Alice's signature; the second condition ii) requires the signatures of both Alice and Bob, but does not require the data payload to be included in the unlocking script of Tx' p As described above, in the embodiment, in Tx1, the first condition i) requires that Bob's signature and the data payload be included in the unlocking script of Tx, but not Alice's signature; the second condition ii) requires the signatures of both Alice and Bob, but does not require the data payload to be included in the unlocking script of Tx' p '.

[0133] Suppose Alice wants to pay Bob to provide some services, such as doing some DIY for her, providing some goods, providing some consulting services, etc. Alice creates a first (intermediate) transaction Tx1, the output of which includes a service payment (output 0 of Tx1 refers to the above example). She sends this to Bob via side channel 301. Alternatively, the first transaction can be created by Bob or a third party. At this stage, it can be sent by any one of Alice, Bob, or a third party to propagate in network 106 for recording in blockchain 150; or it can be sent to network 106 by any one of these parties at a later time at the same time as the second target transaction Tx p / Tx p ' or even after the target transaction.

[0134] Alice also sends the first version of the target transaction Tx p to Bob via side channel 301 as a template for Bob to sign and add a data payload (or the payload can be included by Alice). Alternatively, the first version of the target transaction can be created by Bob or a third party as a template for Bob to sign and add his data payload (or the third party can include the payload). Bob retains a copy of the first version of the target transaction Tx p at least until the second version Tx p ' is obtained, or in view of Bob's signature and data, the first version Tx p can be retained by a third party on behalf of Bob.

[0135] The target transaction Tx p initially contains a data payload and can therefore be redeemed unilaterally by Bob (or on behalf of Bob) without Alice's signature, provided that the data payload is included in the unlocking script. This could potentially compromise Bob's private or proprietary data. Therefore, Bob preferably asks Alice to kindly provide a second updated version of the target transaction Tx p ', including her signature (or send her signature assembled by Bob or a third party into the target transaction Tx p '). This allows Bob to redeem the output of Tx1 and does not have to include it in the target transaction Tx p ’ includes a data payload. However, if Bob provides the service but Alice violates the agreement or there is a dispute over the satisfactory provision of the service, Bob can still turn to redeem the output of Tx1 based on the less preferred first condition, requiring the data payload to be included in the target transaction Tx p in it.

[0136] When Bob finishes the service for Alice, if Alice is honest and satisfied with the service, she will provide her signature. The second version of the target transaction Tx p ’ requires the signatures of both Alice and Bob. Bob can send the first version of Tx with or without the data payload to Alice via the side channel 301 p , for Alice to extend by signing her signature (deleting the data if it still exists). Alternatively, Bob can just send his signature to Alice via the side channel 301 for Alice to assemble into the second version Tx p ’. Then, Alice can send this version to be propagated through the P2P network 106 and recorded in the blockchain 150 (sometimes referred to as "broadcasting" or "publishing" the transaction to the network 106). Alternatively, Alice can return the complete second version of the target transaction Tx p ’ to Bob via the side channel 301 for Bob to broadcast to the network 106 or send it via the side channel to a third party for the third party to broadcast. Again, Alice generates her signature based on the first or second version (it should be remembered that the only difference between them lies in the extensible part), and only sends her signature to Bob via the side channel 301. Then, Bob assembles Alice's signature together with his signature into the second version of the target transaction Tx p ’ and broadcasts it to the network 106 or sends it via the side channel to a third party for the third party to broadcast. Or in another alternative, both Alice and Bob send their signatures to a third party via the side channel for the third party to assemble into the complete second version of the target transaction Tx p ’ and broadcast it to the network 106.

[0137] The first transaction Tx1 and the source transaction also need to be broadcast to the network 106 for recording in the blockchain 150. As long as they are all ultimately verified at some stage, this can be done by any party at any point.

[0138] The fact that the first condition does not require Alice's signature means that Bob can use the first version of the target transaction Tx based on the first condition p The amount defined in the output of the autonomous redemption Tx1, even if Alice does not provide her authorization through her signature. However, the requirement of including a data payload is cumbersome. Additionally / or, the relevant data may be Bob's private, sensitive, or proprietary data, making it necessary to publish the data to the blockchain 150 would represent another form of penalty for Bob. Therefore, Bob is incentivized to provide good service to try to obtain Alice's signature and use the second version Tx of the target transaction based on the preferred second condition p 'redeem Tx1. However, if Alice defaults, Bob can still use the first version Tx of the target transaction based on the less preferred first condition p redeem Tx1. Therefore, the first version Tx p as a kind of guarantee or assurance for Bob.

[0139] Note that the requirement in the first condition of the locking script of Tx1 does not require including a data payload in the locking script of Tx1, nor does it require Alice to know the data payload, even if Tx1 is made by Alice. Instead, it only requires including the hash value of the data payload in the locking script of Tx1 (along with the script of the unlocking script of the challenge Tx p to provide data that will match the hash value in the unlocking script when hashed at node 104). Therefore, even if Alice or a third party makes Tx1, Bob only needs to provide the hash value of his data, rather than the data itself. Only when he has to publish the first version Tx p of the target transaction to the chain does he have to publish the data.

[0140] Exemplary Use Case 2 - Streaming

[0141] Reference Figure 7 , suppose Alice wishes to pay for the streaming of some data from Bob. The data will be transferred from Bob "in chunks", i.e., in a sequence of parts D0, D1, D2, etc. These can be, for example, parts of a media content item streamed by Bob to Alice, such as including a video track (such as a movie) and / or an audio track (such as a piece of music). The video may include time-varying images or graphics, such as a movie, a TV show, a slide show, or other such sequences or still images, dynamic vector graphics, and / or game content. The audio may include sampled audio and / or synthesized audio, including speech, music, noise, and / or special effects or the like. In another example, for Alice to pay for services instantaneously, the following technologies can be used: for example, providing utilities such as gas, electricity, water, etc.; or renting a vehicle, a property, or other physical objects. When paying for the service, each data part D0, D1, D2, etc. includes a different corresponding key required to unlock a service unit, rather than being a data part that is itself part of the required content. For example, Alice's supply of gas, electricity, and water is managed by a smart meter connected to her computer device 102a. She provides each received key from her computer device 102a to her meter, and the meter unlocks another utility unit after verifying the corresponding key.

[0142] It is desirable to stream the data parts in such a way that Bob's payment is proportional to the number of data parts received so far. To this end, in response to each data part D0, D1, D2... received from Bob, Alice can return corresponding signed transactions Tx1, Tx2, Tx3... to Bob via side channel 301. This will mean 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 not send any more data D that Alice has not paid for.

[0143] However, it also needs to be implemented in such a way that for each individual data part D0, D1, D2, etc. streamed, it is not necessary to broadcast a separate transaction to the network 106 and record it in the blockchain 150, as this would increase network congestion and cause the blockchain 150 to bloat.

[0144] To address this issue, in response to each data part D0, D1, D2... that she receives from Bob separately, each transaction Tx1, Tx2, Tx3... that Alice sends back to Bob is a different instance of the first transaction that points to the same output (e.g., the same UTXO) of the same source transaction Tx0. Since the amount of the first transaction increases each time, Bob only needs to request the output of the last transaction at the end of a certain defined sequence (such as the end of an audio track or a video track like a movie, or a specified service period, such as every hour, day, week, or month). This will be explained in more detail later with reference to Figure 7 for a more detailed explanation.

[0145] Also, it is preferably to stream this part in such a way that, firstly, Bob cannot cheat by not sending data but still collecting payments from Alice; secondly, Alice cannot cheat by receiving data but not paying Bob.

[0146] In an embodiment, each instance of the first transaction contains multiple outputs, and the total amount of digital assets of the output is greater than the amount pointed to by its input. This means that the transaction is only valid after someone (in practice, Bob) adds another input of his own to make up the difference (an example of input-level malleability). This prevents Alice from posting an early transaction in the sequence, and in turn prevents Bob from posting a later transaction. Therefore, this makes the streaming of transactions without initial funds act as a deposit for the whole movie or something like that. This will be discussed in more detail later with reference to Figure 8 this.

[0147] To implement the streaming method, Alice and Bob can establish an off-chain side channel 301 with each other. That is, the transactions sent through this channel will not (yet) be posted to the P2P network for recording in the blockchain 150. This will be a modified form of the payment channel, which is also referred to as a "micropayment channel" in this article. Moreover, Bob provides Alice with a hash set of the data parts D0, D1, D2... in the sequence. For example, Bob can send the hash set to Alice through the payment channel 301, or he can make it public so that the set can be accessed through a server on the Internet 101 or something like that. The hash set contains a set of hash values that enable Alice to create a hash challenge for the data without having to know the data itself in advance. For example, the hash set can include a hash tree (also known as a "Merkle tree") (note: in the broadest sense, the Merkle tree used in this article refers to any hash tree, not necessarily limited to, for example, binary branches). Or, the hash set can also contain a hash chain or a hash table.

[0148] Bob has just started sending the first data portion D0 to Alice via payment channel 301. This first portion is sent for free or on the basis of mutual trust between the two parties. If Alice does not pay, then Bob's loss does not exceed the value of the first data portion. Suppose Alice wants to continue. In response to receiving D0, she sends the first instance of the first transaction Tx1 to Bob via payment channel 301. In response, Bob sends the next data portion D1 in the sequence to Alice, and then in response, Alice sends the second instance of the first transaction Tx2 to Bob, after which Bob sends D2 to Alice and Alice sends Tx2 to Bob, and so on, all through payment channel 301. Each instance Tx1, Tx2, Tx3... of the first transaction specifies an increasing payment to Bob, for example increasing linearly with the number of data portions D received so far. However, each instance Tx1, Tx2, Tx3... of the first transaction points to the same UTXO of Alice. Therefore, Bob can only construct a valid instance of the second update transaction Tx p / Tx p ’ and demand payment from one of them (any attempt to redeem the same UTXO twice will be rejected by the network 106 as invalid). Suppose everything is normal. Therefore, Bob will create the target transaction version, demanding payment from the last instance of the first transaction in the sequence.

[0149] In an embodiment, as described above (for example, referring to Figure 5 ), each instance Tx1, Tx2, Tx3... of the first transaction or at least the final instance Tx n defines multiple alternative conditions for redeeming Alice's payment in the output of this transaction. In this case, in addition to confirming the last data portion D n in the sequence, Alice also needs to provide the second version Tx p ’ of the target transaction, or at least provide her signature so that Bob can assemble Tx p ’. This enables Bob to demand payment for the entire sequence (e.g., the whole movie) according to the preferred second condition instead of the first condition that penalizes Bob. If Bob stops streaming portion D, and Alice is not satisfied, then she may not provide the signature that meets the second condition as required, so Bob can only demand payment according to the first condition (i.e., the less preferred condition). On the other hand, if Alice stops requesting further portions midway but is not dissatisfied (e.g., she just chooses to stop watching the movie), and assuming that each instance Tx1, Tx2, Tx3... of the first transaction so far contains multiple alternative conditions, then Alice may provide Tx p ’ or her signature according to the preferred second condition so that Bob can demand payment for the sequence.

[0150] The first transaction Tx i For instances i = 1, 2, 3... the general UTXO is used, but signatures are used on different messages. Thus, in this context, an instance refers to Alice's corresponding data request, that is, an instance of a transaction (discussed later). This is because modifying the numerical value and requesting data will change the signed message.

[0151] The second transaction Tx p / Tx p The version of ' / Tx' uses the general UTXO, but signatures are used on the same message. Thus, in this context, the version refers to the unextended and extended forms of the transaction, that is, the corresponding versions of the transaction. This is because script-level extension does not change the signed message.

[0152] Note: Any variations previously discussed regarding which party generates and / or broadcasts the first transaction Tx1... and the first and second versions Tx p / Tx p ' also apply here. For example, a third party can generate and / or broadcast some or all of the transactions on behalf of Alice or Bob; or Bob can also send Tx p / Tx p ' to the network or send it to Alice for broadcasting, or send his signature to Alice for Alice to assemble the target transaction Tx p / Tx p ' etc. For the sake of brevity, these different options are not repeated here one by one.

[0153] Here is an example in the film industry. When writing a script, the script size is limited to 10 kilobytes. Therefore, for each movie, it can be divided into many 8-kilobyte parts. If there are other limiting conditions, the size of a part may be smaller; or if the script size limit increases, the size of a part may be larger. Once the parts are defined, a Merkle tree can be created, and the root hash will be publicly displayed together with the movie title.

[0154] If the explicit input cannot contain the explicit output and the implicit transaction fee, it is assumed that there is another implicit input.

[0155] Alice will buy a movie from Bob. The movie is defined by n + 1 small data packets D0,..., D n and its Merkle tree Τ with the root hash H root This method will construct a series of transactions TX1, TX2,..., TX n from Alice to Bob. Each transaction TX i corresponds to the request for D i and the receipt of D i-1 Confirmation. Ideally, when the payment channel 301 is correctly closed, only two transactions (TX′ n and TX p ′) will be issued to complete Alice's payment to Bob. This scenario is described in Figure 7 , which is the sequence diagram of the payment channel 301 between Alice and Bob in Use Case 2. Note that Bob first sends a message to Alice, followed by n message pairs for each data packet and the last two messages to close the channel.

[0156] First round - Alice: Initially, Bob sends D0 and the complete Merkle tree containing the required data packets to Alice. Alice checks whether the root hash indeed belongs to the movie title she selected and verifies the Merkle path of D0. Once Alice is satisfied with the received data, she constructs TX1 to confirm that she has received D0 and wants to request D1. This transaction can take the following form.

[0157] TX1

[0158] Locktime: 0

[0159] Input 0:

[0160] · Alice's unspent output point (TxID0, vout = 0)

[0161] · Alice's signature and SIGHASH_ALL|ANYONECANPAY

[0162] Output 0:

[0163] · Locking condition:

[0164] (i) If Bob provides D1 and his signature, he can claim the output.

[0165] (ii) Otherwise, if Alice and Bob provide their signatures, Bob can claim the output.

[0166] (iii) Otherwise, after 720 blocks, Alice can claim the output.

[0167] · Amount: 500 units of digital assets

[0168] Output 1:

[0169] · Alice's change

[0170] Output 2:

[0171] · Pay the same amount as in Output 1 to Bob

[0172] Figure 9 An exemplary illustration in this regard is shown. This single transaction design has three intended functions. By assigning additional implicit meanings to certain fields in the transaction, multiple messages required in the data transaction scenario can be replaced with just a single transaction template. Sig(P A ,Tx1) is a signature that confirms that the previous data packet has been received and meets the requirements. OP_DUP OP_SHA256<H(D1)>OP_EQUAL is a request for the next data packet. 500 units is the payment for the next data packet.

[0173] The input of Tx1 includes at least input 0. This includes a pointer to the UTXO of the previous transaction Tx0 locked to Alice, whose amount (e.g., 2000 units) is greater than the output 0 of Tx1 (see below). The output 0 of Tx1 also includes Alice's signature in the unlocking script of the input, and a flag that enables other parties to add an input ("ANYONECANPAY”).

[0174] The output of Tx1 includes at least output 0. This specifies an (initial) small amount of digital assets (e.g., 500 units), which is less than the input 0 of Tx1. The output 0 of Tx1 also includes a locking script that enables it to be unlocked under any of the following conditions:

[0175] i) The unlocking script in the input of the subsequent transaction Tx p contains D1 and Bob's signature;

[0176] ii) The unlocking script in the input of the subsequent transaction Tx p ’ contains Alice's signature and Bob's signature; or

[0177] iii) The timeout limit has passed, and the unlocking script in the input of the subsequent transaction contains Alice's signature.

[0178] Regarding condition i), since Bob has sent the Merkle tree (also known as a hash tree) to Alice, Alice knows the expected data part. Thus, she can determine the hash value of D1, which is sufficient for her to pass the hash challenge including this condition (the locking script of Tx1 contains the hash value of D1 and the partial code for checking whether the value that appears in the unlocking script of the input of Tx p matches the value in the locking script when hashed). This condition means that if Bob wants to request payment without obtaining Alice's signature, he has to upload D1 to the blockchain 150, but since D1 is Bob's proprietary data, he is reluctant to do so. This technique can also be used in the same way for subsequent data parts D2, D3, etc.

[0179] Condition ii) will enable Bob to claim payment without having to upload the data, provided that he obtains Alice's signature. However, assume that he does not want to do so yet.

[0180] Condition iii) is optional. If Bob does not claim payment for any reason after a specified timeout period has elapsed (e.g., Bob never participated in the process), Alice can claim the amount in output 0 of Tx1. It should be understood that the specific timeout value of 720 blocks is just an example. More generally, the timeout period can be defined in terms of the number of blocks or artificial time (such as seconds), or it can be set to any value. It can be defined to expire at an absolute point in time or after a period of time has elapsed.

[0181] Tx1 can 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 a digital asset amount equal to the input amount and locks this to Alice ("Alice's change"). For example, 2000 - 500 units = 1500 units.

[0182] Output 2 includes a script that defines a digital asset amount equal to output 1 and locks this to Bob ("pay Bob the same amount as Alice's change in output 1"). The result of this is that the total output (in this example, 500 + 1500 + 1500 units = 3500 units) is always greater than the input, unless someone else (in practice, only Bob) adds another input of his own to Tx1 to make up the difference.

[0183] Output 2 is a trick designed to prevent Alice from publishing a transaction without Bob's confirmation. As the payer, Alice is not initially incentivized to broadcast TX1. But after a few rounds, when Alice pays Bob more in other transactions, before Bob uses a later instance to claim payment, Alice can invalidate these transactions by broadcasting TX1 to network 106. By including output 2, TX1 will only become effective after Bob adds his own input (input 1) to TX1 to make up the difference between the output and the input. Bob will be able to add an additional input because Alice uses the SIGHASH flag "ALL|ANYONECANPAY". Therefore, TX1 will likely only be broadcast by Bob. Alice does not want to add the additional input required for Tx1 to be valid because it would cost her more than not cheating the system.

[0184] Alice's change is defined as Alice's input value (input 0) minus the value of Bob's payment (output 0). As Figure 8 shown, Bob's insurance (output 2) will ensure that the total output (dashed line) is always greater than the input before the last data part is sent.

[0185] 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, so Bob needs to add his own input to claim the output 0 of Tx1 and prevent Alice from broadcasting Tx1.

[0186] As an example of implementing the three conditions i), ii), and iii) in output 0 of the scripting language, hash puzzles and conditional opcodes can be used, for example as follows.

[0187]

[0188]

[0189] First round - Bob's turn: When Bob receives transaction TX1, he only sends D1 to Alice. Note that it is safe for Bob to do so because he can request payment in TX1 through the following operations without any assistance from Alice. First, Bob uses the output point (TxID B , vout = 0) to create TX′1 by adding his own input to cover the value of output 2 in TX1. Second, Bob creates another transaction TX p to request payment:

[0190] TX p

[0191] Locktime: 0

[0192] Input 0:

[0193] · Output point from output 0 of TX′1.

[0194] · Unlocking data

[0195] ο D1

[0196] ο Bob's signature

[0197] Output 0:

[0198] · Payment to Bob

[0199] · Amount: 500 units

[0200] Then, Bob broadcasts the two transactions to the network 106. However, this is not an ideal situation for Bob because he has to disclose D1 in the transaction. This is regarded as an early closing of the channel. However, if Alice follows the correct procedure to close the payment channel (as described below), Bob does not have to do so.

[0201] Round 2 - It's Alice's turn: When Alice receives D1 and is satisfied with the content, she constructs the following transaction for the next data packet. This transaction will also be considered as confirmation of receiving D1.

[0202] TX2

[0203] Locktime: 0

[0204] Input 0:

[0205] · Alice's unspent output point (assumed to be the same output point as in TX1)

[0206] · Alice's signature and SIGHASH_ALL|ANYONECANPAY

[0207] Output 0:

[0208] · Locking condition:

[0209] ο If Bob provides D2 and his signature, he can claim the output.

[0210] ο Otherwise, if Alice and Bob provide their signatures, Bob can claim the output.

[0211] ο Otherwise, after 720 blocks, Alice can claim the output.

[0212] · Amount: 1000 units

[0213] Output 1:

[0214] · Alice's change

[0215] Output 2:

[0216] · Pay Bob the same amount as in Output 1

[0217] Comparing TX1 and TX2, note that D1 is changed to D2, and the value of Output 0 increases from 500 units of digital assets to 1000 units. Due to these two changes, the other outputs will have different values (assuming Alice uses the same unspent output point). Also, since these changes are not made on the malleable part of the transaction, Alice must generate a new signature for TX2.

[0218] Round 2 - It's Bob's turn: When Bob receives the transaction TX2, he only sends D2 to Alice.

[0219] As before, it is safe for Bob to do so because he can claim payment as in the first round without Alice's help: Bob will also receive from (TxID B , vout = 0) adds its own input to cover Output 2 in TX2 and creates TX'2; Bob will also create another transaction TX p , to request payment:

[0220] TX p

[0221] Locktime: 0

[0222] Input 0:

[0223] · Output point from Output 0 of TX'2.

[0224] · Unlock data

[0225] ο D2

[0226] ο Bob's signature

[0227] Output 0:

[0228] · Pay Bob

[0229] · Amount: 1000 units

[0230] Then, Bob broadcasts the two transactions to the network.

[0231] If Alice and Bob cooperate to close the channel, Bob can avoid the operations mentioned in the first round.

[0232] Final round - It's Alice's turn: After several rounds, Alice constructs TX n to request the final packet D n .

[0233] TX n

[0234] Locktime: 0

[0235] Input 0:

[0236] · Alice's unspent output point (assumed to be the same output point as in TX1)

[0237] · Alice's signature and SIGHASH_ALL|ANYONECANPAY

[0238] Output 0:

[0239] · Locking condition:

[0240] ο If Bob provides D n and his signature, he can claim the output.

[0241] ο Otherwise, if Alice and Bob provide their signatures, Bob can claim the output.

[0242] Otherwise, after 720 blocks, Alice can request an output.

[0243] · Value: 500n units

[0244] Output 1:

[0245] · Alice's change

[0246] Output 2:

[0247] · Pay Bob the same amount as in Output 1

[0248] Final round - Bob's turn: Bob responds with the final packet D n for this.

[0249] Closing the channel: To close the payment channel, there is some interaction between Alice and Bob. Either Alice or Bob can signal to the other their intention to close channel 301. Without loss of generality, assume the last packet sent from Bob to Alice is D n . Bob discovers TX n , i.e., the transaction for which D n is requested, and adds its own input to cover Output 2 to create TX' n . Bob creates TX p as follows:

[0250] TX p

[0251] Locktime: 0

[0252] Input 0:

[0253] · Output point from Output 0 of TX' n

[0254] · Unlocking data

[0255] ο D n

[0256] ο Bob's signature

[0257] Output 0:

[0258] · Pay Bob

[0259] · Value: 500n units

[0260] Bob sends two transactions (TX' n and TX p ) directly to Alice via payment channel 301. Alice checks TX' n and TX p Whether the input is indeed relevant as she expects. Alice signs TX p , and replaces D n with her signature to create TX p ′.

[0261] TX p ′

[0262] Lock time: 0

[0263] Input 0:

[0264] · Output point from TX′ n Output 0.

[0265] · Unlocking data

[0266] ο Alice's signature

[0267] ο Bob's signature

[0268] Output 0:

[0269] · Payment to Bob

[0270] · Amount: 500 n units

[0271] Alice sends TX p ′ to Bob. Bob broadcasts TX′ n and TX p ′ to network 106. Alternatively, Alice will broadcast TX′ n and / or TX p ′, or one or both of them can be sent to a third party to broadcast on behalf of Alice and Bob. Note that Alice can choose to close the channel at any time.

[0272] Note Figure 7 : (A) Bob can unilaterally close the channel by broadcasting a pair of transactions; (B) Both of the two transactions forming the transaction pair are broadcast when the channel is closed, showing that the channel is "open" effectively off-chain without communicating with network 106.

[0273] To summarize this sequence, Bob sends D2 to Alice as a response to Tx1. Alice sends Tx2 to Bob for confirmation, and then Bob sends D3, etc. Tx2 is the same as Tx1, but D1 is replaced by D2 and the amount of Output 0 increases. In Tx3, D2 is replaced by D3 and the amount of Output 0 increases again. In the embodiment, the amount in Output 0 increases linearly with i, that is, with each data block and Tx sent in the confirmation. Alternatively, it is not excluded that another increasing relationship is used, such as giving a higher weight at the end of the sequence to further incentivize the completion of the sequence.

[0274] Bob can unilaterally request Tx1…Tx based on criterion ii) i To do this, Bob would extend to create Tx i '. The extension consists of adding some of Bob's digital assets as input to make up the difference, and then creating a i Another transaction Tx p , to spend Tx i .Tx p has an output that is unconditionally locked to Bob. Bob could add his input and spend one of the earlier transactions Tx1 or Tx2 etc., but it is not worth it. He would rather keep sending the movie and get the full amount at the end. Also, Bob would prefer not to rely on criterion ii), since he has to publish one of the data blocks of the movie on the blockchain.

[0275] Note that the input of each Tx1, Tx2, Tx3, ... specifies the same UTXO of Tx0. Therefore, if any of them are broadcast to the network and verified at any given node 104, any of them will no longer be considered valid at that node (validity is conditional on Tx not attempting to spend a UTXO that has already been validly spent by another transaction). Different nodes 104 may first receive different instances and therefore have conflicting views on which instance is 'valid' before mining one, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts one instance as valid, and then discovers that a second instance has been recorded in the blockchain 150, then the node 104 (must) accept this and will discard the originally accepted unmined instance (i.e., treat it as invalid).

[0276] If Bob cashes out early and stops sending movies, Alice has only overpaid by one chunk and therefore only loses 500. Alice can bail at any point, but if she does, Bob will not send Alice any of the extra chunks of movies (e.g., 500 units worth) that he has not paid for.

[0277] This mechanism works because the amount increases from small to large each time until the end of the movie; and all transactions attempt to spend the same UTXO in Tx0, so cashing out any one transaction invalidates the others. Also, in an embodiment, the output sum must be greater than the input until Bob adds his own input. This is an example of input-level malleability.

[0278] If both Bob and Alice wait until the end of the movie, Bob will send Tx n 'To Alice for Alice to sign, so that D n Replace the hash value with her signature. This enables Bob to demand full payment without releasing any data block D. This is an example of script-level malleability.

[0279] To avoid data congestion on the blockchain, the process uses a locking script that can be unlocked by using certain data packets or the signature of the data recipient. By using the malleability of the transaction, the data recipient can replace the data in the unlocking script with her or his signature. This action can not only confirm that the data has been received or confirm the closure of the payment channel, but also prune the data from the transaction to save space.

[0280] Given the increase in the transaction value increment, Bob has no incentive to release any transaction except the last one received from Alice. If Alice leaves the channel prematurely, then Bob only needs to release the last transaction he received from Alice, as well as the transaction demanding payment. If he has not received Alice's extended transaction, he must disclose the relevant data packets to demand payment. In an embodiment, if there is a high requirement for data confidentiality, Bob can encrypt the data sent to Alice and disclose the decryption key in the transaction (see below).

[0281] However, for Alice, when she receives a large enough data packet, she may have an incentive to release the first transaction. Since both the first transaction and the latest transaction are valid, it is uncertain whether she will succeed in invalidating the latest communication transaction. To completely avoid this situation, an additional output that invalidates the transaction itself is included in the embodiment, unless someone makes up the difference between the output and the input. For Alice, to make the transaction valid, she must provide additional input, but this goes against the purpose of her broadcasting the transaction.

[0282] In the case where Bob goes offline, Alice will not be able to continue watching the movie. However, she will not pay extra for the content she has watched. She can wait for Bob to come back, or she can also switch to another service provider and start from where she left off.

[0283] Note that this form of payment channel does not require a fund transaction. In addition, it is very flexible and Alice can reconnect at any point to resume the streaming service. That is, there is no overhead for establishing a payment channel.

[0284] The embodiments solve all risks within the payment channel. However, it is still possible for Alice to double-spend the UTXO outside the payment channel. The embodiments can prevent any one or more of the following three options to prevent this from happening. The first is to use technology to force Alice to disclose the key to the deposit account when attempting to double-spend the UTXO, in which case Bob will be able to claim all the deposits. The second option is to make Alice's confirmation also legally binding. That is, Alice's signature on Bob's payment request transaction can be regarded as a binding proof of identity. Any misbehavior of Alice will be subject to legal enforcement. The third option is for Bob to terminate and restart the payment channel from time to time, for example, every 5 minutes. Bob can adjust the frequency according to his own risk assessment. Note that since no fund transactions are required, restarting the payment channel incurs no overhead.

[0285] Data Encryption: When data is exchanged over a public network, there are usually requirements for data confidentiality. In the previous section, it was assumed that the data recipient knew exactly what was expected to be received. However, when the data is encrypted, it is difficult to know in advance the ciphertext or the expected hash value without any communication. This requires building a hash puzzle in the locking script. To alleviate this situation, in the embodiments, the data seller can transmit the hash value of the ciphertext to the data recipient before transmission. The data recipient uses the given hash value to construct a payment transaction. When the encrypted data is received, the data recipient can decrypt the data and verify whether the data meets the expectations. If it does, then all is well. If not, then in the worst case, the recipient loses money. However, the amount that the recipient may lose is constrained by the price of each data packet. If it is a movie, it may be about 500 units, for example, adding up to about $5 per movie. Considering the small economic value and the large reputation impact, the data seller has no incentive to deceive.

[0286] Some embodiments can implement a mechanism to establish a shared key between the data seller and each data buyer through symmetric encryption. Thus, all data in transmission can be encrypted.

[0287] Exemplary Use Case 3 - Polling and Voting

[0288] In another exemplary use case, for example Figure 5 as shown, different alternative conditions of the first transaction Tx1 can be used to represent different voting choices to use the blockchain 150 as a way to record votes. Before Tx p ’ is submitted to the network for inclusion in the block 151, Alice's choice in Tx p can be used as an indicative poll of her voting intention. In the following example, the first transaction will be referred to as Tx Slip , and the first version of the second (target) transaction will be referred to as Tx Poll , the second version of the target transaction will be called Tx Vote .

[0289] Consider the following exemplary scenario. An election is about to be held. A government agency ("Bob" 103b) wishes to provide compensation to eligible voters participating in a blockchain-based voting system to encourage people to participate in polling and voting. For the purposes of illustration, assume this is a two-party state: the "Labour Party" and the "Conservative Party". The government agency P Gov is responsible for (a) registering eligible voters, (b) issuing voting slips, and (c) counting the polls and votes. In this scenario, the government agency is the second party 103b (also known as "Bob"). The voters include N eligible voters. Each voter ("Alice" 103a) selects a private "voting token" T V at the time of registration, which is known only to the voter themselves. Bob's government agency knows the hash value H(T V ).

[0290] The following definitions can be used for the polling and voting scenario.

[0291] · Registration := A voter registers as an eligible voter through some off-chain or on-chain process. The voter privately selects T V and provides H(T V ) to Bob's government agency.

[0292] · Voting slip (Ts Slip ):= A transaction that includes a locking script for paying voters who participate in polling and / or voting.

[0293] · Polling (Tx Poll ):= A signed transaction that uses unlocking condition (I) or (II) to unlock the voting slip output, where conditions (I) and (II) represent the polling choices for two corresponding options, such as referendum responses or political parties (see the examples below).

[0294] · Voting (Tx Vote ):= A signed transaction that uses unlocking condition (III) or (IV) to unlock the voting slip output, where conditions (III) and (IV) represent the voting choices for two corresponding options (again see the exemplary conditions below).

[0295] Each voter will also have their own public key P V . To participate in polling or vote for the political party of their choice, each person must sign using the public key that represents their choice.

[0296] In the illustrative two-party example, only one of the political parties can be chosen, and the two possible public keys that a voter can use to express their choice can be as follows:

[0297] P V,L = P V + SHA256("Labour") · G,

[0298] P V,C = P V + SHA256("Conservative") · G,

[0299] Where "·" is defined as the operator of "EC point multiplied by scalar".

[0300] Regarding the unlocking conditions, the locking script will be constructed as follows: it can be unlocked when any one of the four different unlocking conditions is met. Conditions (I) and (III) are both related to "Labour Party", representing polling and voting respectively. Conditions (II) and (IV) are both related to "Conservative Party", representing polling and voting respectively. The full text of the conditions is as follows:

[0301] (I) <SigP V,L > < P V,L > < "Labour Party"

[0302] (II) <SigP V,C > < P V,C > < ”Conservative Party”

[0303] (III) <SigP Gov > < P Gov > < T V > < SigP V,L > < P V,L > < ”Labour Party”

[0304] (IV) <SigP Gov > < P Gov > < T V > < SigP V,C > < P V,C > < ”Conservative Party”

[0305] The embodiments will be switched through the concept of script-level malleability switching conditions:

[0306] · (I) → (III) converts Labour Party polling to Labour Party voting, or

[0307] · (II) → (IV) converts Conservative Party polling to Conservative Party voting.

[0308] These switches represent converting polling to voting for the same party ("→"). These conversions can be achieved through malleability because the public keys and signatures used are consistent throughout the exchange - only the rest of the input script data is malleated, so the voter's signature does not need to be changed.

[0309] However, if an eligible voter wishes to make the following switch:

[0310] · (I) → (II) [transfer the vote to be cast for the Labour Party in the poll to the Conservative Party]; or

[0311] · (III) → (IV) [transfer the vote for the Labour Party to the Conservative Party].

[0312] In the embodiment, this cannot be achieved using malleability and switching conditions. However, alternatively, this can also be achieved by separately increasing the serial numbers of the poll or the vote transaction, where the message signed by Alice (the voter) contains the serial number. This means that the signature of Alice's poll selection cannot be maliciously used by a third party to forge her subsequent vote selection.

[0313] Unlock conditions are used to unlock specific locking scripts, whereby each unlock condition satisfies a different locking condition in the locking script. The relevant locking script (which may be referred to herein as the "vote script") is shown below.

[0314]

[0315]

[0316] The poll and vote procedures are as Figure 10 shown. This is a sequence diagram showing the complete poll and vote process from the announcement of the election at t0 to the end of the voting period at t3.

[0317] This procedure is divided into the following steps.

[0318] Step 1: At time t0, Bob's government agency P Gov opens voter registration for the vote to be held at a later time t2. Voters can now freely register and provide their hash token H(T V ) as part of the registration process.

[0319] Step 2: Bob's government agency P Gov issues N ballot transaction Tx Poll . Each ballot is paid for, and the public key P V of the voter applies to a single voter (with a locking script as shown above). Each transaction is locked to a later time t2.

[0320] Step 3: Voter Alice (with public key P V ) wishes to participate in the poll phase. The poll phase is defined as all times t: t0 < t < t2. The voter participates in the poll by selecting "Labour Party" and constructing the poll transaction Tx Pool ( Figure 11 ) and using the unlock script condition (I).

[0321] This transaction can be made public by the voter, the government, or a third party, but it cannot be submitted to the network for inclusion in a new block until t2.

[0322] If the voter wishes to change the poll choice to "Conservative Party", she must generate a new poll transaction using script condition (II) and increment the sequence number.

[0323] Step 4: Voter Alice decides at some time t1 that she wishes to convert her poll choice of "Labour Party" to a vote choice. This involves extending the unlocking script of the poll transaction to generate a vote transaction. This extension changes the unlocking condition to script condition (III) [(I) → (III)].

[0324] To perform the extension, in Step 4, voter Alice sends her voting token T V to Bob's government agency. In Step 5, Bob's government agency switches the poll token to a voting token to turn the poll transaction into a vote transaction and signs the vote transaction with Sig(P Gov ,Tx Vote ) to confirm that it is a valid vote. As a variant, the voter can put the voting token in the transaction and send it to the government for signature.

[0325] Note that due to the lock time t2 imposed by the two transactions, the poll transaction and the corresponding vote transaction created subsequently are always invalid for t < t2.

[0326] Step 6: Bob's government agency broadcasts all valid vote transactions at t2. It continues to broadcast any other vote transactions finalized at times t: t2 < t < t3, where t2 defines the start time of the voting period and t3 defines the end time of the voting period.

[0327] In an embodiment, the government agency never broadcasts the poll transaction. The polled person (Alice) has the right to decide whether to broadcast this and claim a reward at her own discretion.

[0328] Note that Tx slip also needs to be submitted to the network for inclusion in a new block at some point in the process so that the UTXO spent in Tx poll / Tx vote actually exists. For simplicity, this step is not shown in Figure 10 The actual method for locking the transaction time also slightly affects the point in the signaling diagram of Figure 10 where Tx slip is sent to network 106. If each Tx slip sets 'nLocktime' (Definition 8), Tx slip Broadcasts will also be required to effect submission to the network at stage 6 in the figure (and / or the final optional stage) for inclusion in the new block. If once selected to set OP_CLTV or OP_CSV (Definitions 10 and 11) in the locking script of Tx slip then Tx slip can be submitted to the network for inclusion in the new block simultaneously as described in step 2 above.

[0329] Figure 11 Some exemplary transactions that can be used to implement the process are shown. The top transaction is the ballot transaction Tx Slip which allows all voters to apply for funds by polling and / or voting. Outputs can only be claimed after the voting period has started at t2. The middle transaction is the polling transaction Tx Poll which indicates that a voter has selected an option as part of the poll. For example, assuming the locktime is implemented using OP_CSV or OP_CLTV and Tx slip is sent to the network (step 2) at the same time as it is sent to the voter, then this transaction will be invalid until the timelock is set on the output of Tx slip referenced in the input. The bottom transaction is the voting transaction Tx Vote which indicates that a voter has selected an option as part of the vote. This transaction is the same as Tx Poll but the unlocking conditions have been switched using script-level malleability. Similarly, this transaction will be invalid until t2.

[0330] In an embodiment, the timelock is included as part of the output of the first transaction (Tx Slip ). However, in an alternative mechanism there will be a timelock Tx Poll instead of Tx Slip which achieves roughly the same effect.

[0331] Conclusion

[0332] It should be understood that the above embodiments are described by way of example only.

[0333] More generally, according to one aspect disclosed herein, a method for recording a target transaction between a first party and a second party in a blockchain is provided; the method includes, by a computer device of the first party or the second party: obtaining a second updated version of the target transaction, updated relative to a pre-existing first version of the target transaction; sending the updated version of the target transaction, rather than the first version, for propagation through a network of nodes and recording in a copy of the blockchain maintained by each of at least some of the nodes; wherein the target transaction includes an input that contains an unlocking script and a pointer to a first output of a first transaction, the first output containing a locking script that specifies a plurality of alternative conditions for unlocking the first output of the first transaction; wherein the unlocking script of the first version of the target transaction is configured to unlock the first output of the first transaction on the basis of satisfying a first one of the alternative conditions, and the unlocking script of the updated version is configured to unlock the first output of the first transaction on the basis of satisfying a second one of the alternative conditions, rather than the first condition.

[0334] In an embodiment, the method may include, by a computer device of the second party: providing a function that enables the second party to send the first version of the target transaction on the basis of satisfying the first condition for propagation through the network and recording in the blockchain.

[0335] The method may enable the second party to selectively send the first or updated version of the target transaction on the basis of satisfying the first or second condition, respectively, for propagation through the network and recording in the blockchain; the method includes the second party using the function to perform the sending of the updated version for recording in the blockchain, rather than the first version.

[0336] In an embodiment, the function may be available for the second party to optionally select to perform the sending of the first version manually, and / or the function may be configured to automatically trigger the sending of the first version of the target transaction after a predetermined time has expired or when a predetermined event occurs.

[0337] In an embodiment, the obtaining and sending of the updated version of the target transaction for propagation and recording in the blockchain may be performed by a computer device of the second party.

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

[0339] In an embodiment, the method may include, by a computer device of the second party: obtaining the first version of the target transaction, wherein the unlocking script of the first version of the target transaction may be configured to enable the second party to autonomously unlock the first output of the first transaction on the basis of satisfying the first condition.

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

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

[0342] In an embodiment, obtaining the first version may include a second party generating a first transaction.

[0343] In an embodiment, the second condition may require that the unlocking script include an encrypted signature of the first party that signs a portion of the target transaction, excluding the unlocking script. In such a case, obtaining the updated version of the target transaction includes obtaining the signature of the first party, and the updated version sent to be propagated and recorded on the blockchain includes the signature of the first party in the unlocking script.

[0344] In an embodiment, the first condition may not require an encrypted signature of the first party.

[0345] In an embodiment, at least the first condition may require that the unlocking script include an encrypted signature of the second party that signs a portion of the target transaction, excluding the unlocking script.

[0346] In an embodiment, the second condition may further require that the unlocking script include an encrypted signature of the second party that signs a portion of the target transaction, excluding the unlocking script. In such a case, the updated version sent to be propagated and recorded on the blockchain includes the encrypted signature of the second party in the unlocking script.

[0347] In an embodiment, obtaining the updated version may include: the second party sending the first version to the first party so that the first party extends it to an updated version by adding the signature of the first party. The first and second conditions may require the second party to sign the same portion of the target transaction with the same signature, such that the second party does not need to re-sign the updated version.

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

[0349] In an embodiment, the first condition requires that the unlocking script include a data payload and an encrypted signature of the second party that signs a portion of the target transaction, excluding the unlocking script, but does not require that an encrypted signature of the first party be included in the target transaction; the second condition may require that the unlocking script include the encrypted signatures of the first and second parties, but does not require that a data payload be included in the target transaction. In such embodiments, obtaining the updated version of the target transaction includes obtaining the signature of the first party; the updated version of the target transaction sent to be propagated and recorded on the blockchain does not need to include the data payload, but includes the signatures of the first and second parties in the unlocking script.

[0350] In an embodiment, the requirement including the corresponding data portion is created by a hash challenge included in a locking script, the hash challenge including a hash value of the corresponding portion of data and a hash function to check that the hash value of the corresponding data portion in the unlocking script matches the hash value included in the locking script. The method may include making available to a first party, independent of a network and prior to receiving an instance of a first transaction, a hash set (e.g., a hash tree) including hash values of each portion of partial data, such that the first party can generate a hash challenge for the corresponding data portion.

[0351] In an embodiment, a first output of a first transaction may specify an amount to be paid to a second party, the amount being redeemable by unlocking the first output according to a first or second condition, wherein a target transaction may include an output transferring at least some of the amount to the second party.

[0352] In an embodiment, the method may include, by a computer device of a second party: streaming a sequence of data portions to a first party, ending with a final portion in the sequence; in response to each corresponding portion of the data portions, receiving back from the first party a corresponding instance of the first transaction, the first output of each instance specifying an amount to be paid to the second party for the corresponding portion; wherein the amount increases with each additional data portion; wherein obtaining an updated version of the target transaction includes receiving the updated version from the first party after the final portion in the sequence.

[0353] In an embodiment, the increase may be linearly proportional to the number of data portions sent so far.

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

[0355] Alternatively, each data portion may be a different key for accessing a service unit (e.g., providing utilities such as gas, water, electricity; or renting a property, vehicle, or other physical item).

[0356] In an embodiment, the functionality enables the second party to select to manually initiate, at any point in the sequence, the sending of a first version of the target transaction to be propagated over a network and recorded on a blockchain to redeem the most recent instance of the first transaction in the sequence received from the first party so far. Additionally / or, the functionality may be configured to automatically initiate the sending of the first version to be propagated over a network and recorded on a blockchain if the first party stops sending instances of the first transaction through the sequence, to redeem the most recent instance of the first transaction.

[0357] In an embodiment, a first transaction may include one or more first inputs specifying an input amount, a first output of the first transaction may specify a first payment, the first transaction may further include one or more further outputs specifying one or more further payments such that the total amount of the payments is greater than the input amount, and the first transaction received by a second party from a first party may not include other inputs to cover the difference. If the specified total payment amount is greater than the total input amount, nodes of the network may be configured to reject a transaction such as the first transaction as invalid. In such embodiments, the method may include the second party adding a second input to the final or most recent instance of the first transaction to cover the difference and sending the first transaction with the second input added for propagation through the network and recording in the blockchain.

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

[0359] In an embodiment, the locking script includes a third condition among the alternative conditions, which requires that a lock time has expired and includes a cryptographic signature of the first party in the unlocking script, such that if the second party does not redeem within the lock time, the first party can redeem the payment in the first output of the first transaction.

[0360] In an embodiment, each condition of at least a portion of the alternative conditions may correspond to a different voting choice; the method may include: before obtaining an updated version of a target transaction, accessing or making accessible to a third party the unlocking script in a first version as a non-binding indication of a voting intention.

[0361] 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 in the blockchain before a predetermined point in time.

[0362] In an embodiment, the output of the first transaction may specify redemption by unlocking the first output according to any 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.

[0363] In an embodiment, the alternative conditions may include: a first condition, a second condition, a third condition, and a fourth condition. The first condition corresponds to a polling indication of a first selection, the second condition corresponds to a polling indication of a second selection, the third condition corresponds to a voting selection of the first selection, and the fourth condition corresponds to a voting selection of the second selection. The unlocking script of the first version of the target transaction may be configured to unlock the first output of the first transaction based on the satisfaction of the first or second condition. The unlocking script of the second version of the target transaction is configured to convert the polling indication to a vote by being configured to unlock the first output of the first transaction based on the satisfaction of the third condition, rather than the first condition or the fourth condition or the second condition.

[0364] In the case of voting, the first condition may require that the unlocking script of the target transaction includes an encrypted signature of the first party, and the encrypted signature signs a part of the target transaction (excluding the locking script). The first condition may require that the signature of the first party signs a private voting token. The second condition may require that the unlocking script of the target transaction includes an encrypted signature of the first party and an encrypted signature of the second party, and each signature signs a part of the target transaction (excluding the locking script).

[0365] According to another aspect disclosed herein, a computer program stored on a computer-readable memory is provided, configured to perform the method described in any of the embodiments disclosed herein when run on a computer device of the first party and / or the second party.

[0366] According to another aspect, a computer device of the first party and / or the second party is provided, including: a memory including one or more storage units, and a processing device including one or more processing units. The memory stores code configured to run on the processing device, and the code is configured to perform the method described in any of the embodiments disclosed herein when run on the processing device.

[0367] According to another aspect disclosed herein, there is provided a computer program embodied on a computer-readable memory and configured to perform the following operations when run on a computer device of a second party: obtain a first version of a target transaction; obtain a second version of the target transaction; cause the second party to selectively send any one of the first and second versions for propagation through a node network and record in a blockchain copy maintained by at least some of the nodes; wherein the target transaction includes an input that contains an unlocking script and a pointer to a first output of a first transaction, the first output specifying an amount of digital assets of a first party, including a locking script that specifies multiple alternative conditions for unlocking the first output of the first transaction; wherein the unlocking 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 one of the alternative conditions, and the unlocking script is configured to unlock the first output of the first transaction based on satisfying a second one of the alternative conditions, rather than the first condition.

[0368] According to another aspect disclosed herein, there is provided a computer program embodied on a computer-readable memory and configured to perform the following operations when run on a computer device of a second party: obtain a first version of a target transaction; obtain a second version of the target transaction; cause the second party to selectively send any one of the first and second versions for propagation through a node network and record in a blockchain copy maintained by at least some of the nodes; wherein the target transaction includes an input that contains an unlocking script and a pointer to a first output of a first transaction, the first output specifying an amount of digital assets of a first party, including a locking script that specifies multiple alternative conditions for unlocking the first output of the first transaction; wherein the unlocking 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 one of the alternative conditions, and the unlocking script is configured to unlock the first output of the first transaction based on satisfying a second one of the alternative conditions, rather than the first condition.

[0369] According to another aspect disclosed herein, a computer device of a second party is provided, including: a memory including one or more storage units, and a processing device including one or more processing units; wherein the memory stores code configured to run on the processing device, and the code is configured to perform the following operations when running on the processing device: obtain a first version of a target transaction; obtain a second version of the target transaction; enable the second party to selectively send any one of the first and second versions to be propagated through a node network and recorded in a blockchain copy maintained by at least some of the nodes; wherein the target transaction includes an input containing an unlocking script and a pointer to a first output of a first transaction, the first output specifying an amount of digital assets of a first party, including a locking script that specifies a plurality of alternative conditions for unlocking the first output of the first transaction; wherein the unlocking 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 one of the alternative conditions, and the unlocking script is configured to unlock the first output of the first transaction based on satisfying a second one of the alternative conditions, rather than the first condition.

[0370] According to another aspect of the present disclosure, a method for enabling a second party to record a target transaction in a blockchain is provided; the method includes, through a computer device of a first party: sending an updated version of the target transaction to the second party, the updated version being updated relative to a pre-existing first version of the target transaction, so that the second party sends the updated version to be propagated through a node network and recorded in a blockchain copy maintained by at least some of the nodes; wherein the target transaction includes an input containing an unlocking script and a pointer to a first output of a first transaction, the first output containing a locking script that specifies a plurality of alternative conditions for unlocking the first output of the first transaction; wherein the unlocking 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 one of the alternative conditions, and the unlocking script is configured to unlock the first output of the first transaction based on satisfying a second one of the alternative conditions, rather than the first condition.

[0371] According to another aspect disclosed herein, a set of transactions for recording in a blockchain is provided, the set including, on a computer-readable data medium or media: a first transaction having an output that includes a locking script specifying a plurality of alternative conditions for unlocking the output of the first transaction; a first version of a second transaction having an input that includes an unlocking script and a pointer to the output of the first transaction, wherein the unlocking script of the first version of the target transaction is configured to unlock the output of the first transaction on the basis of satisfying a first one of the alternative conditions; and a second version of the second transaction having an input that includes an unlocking script and a pointer to the output of the first transaction, wherein the unlocking script is configured to unlock the output of the first transaction on the basis of satisfying a second one of the alternative conditions, rather than the first condition.

[0372] Once the present disclosure is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.< / sighashflag>

Claims

1. A method for recording a target transaction between a first party and a second party in a blockchain, the method comprising, by a computer device of the first party or the second party: Obtaining a second updated version of the target transaction, updated relative to a pre-existing first version of the target transaction; Sending the updated version of the target transaction, rather than the first version, for propagation through a node network and recording in a blockchain copy maintained by each node of at least some of the nodes; Wherein the target transaction includes an input, the input containing an unlocking script and a pointer to a first output of a first transaction, the first output containing a locking script that specifies a plurality of alternative conditions for unlocking the first output of the first transaction; Wherein the unlocking script of the first version of the target transaction is configured to unlock the first output of the first transaction on the basis of satisfying a first one of the alternative conditions, and the unlocking script of the updated version is configured to unlock the first output of the first transaction on the basis of satisfying a second one of the alternative conditions, rather than the first condition.

2. The method according to claim 1, comprising, by a computer device of the second party, providing a function that enables the second party to send the first version of the target transaction on the basis of satisfying the first condition for propagation through a network and recording in a blockchain.

3. The method according to claim 2, wherein: - The function supports the second party to manually select to perform the sending of the first version, and / or - The function is configured to automatically trigger the sending of the first version of the target transaction after a predetermined time has expired or when a predetermined event occurs.

4. The method according to any one of the preceding claims, wherein the obtaining and sending of the updated version of the target transaction for propagation and recording in a blockchain is performed by a computer device of the second party.

5. The method according to claim 4, wherein the obtaining of the second version includes receiving at least a part of the second version from the first party.

6. The method according to any one of the preceding claims, comprising, by a computer device of the second party: Obtaining the first version of the target transaction, wherein the unlocking script of the first version of the target transaction is configured to enable the second party to autonomously unlock the first output of the first transaction on the basis of satisfying the first condition.

7. The method according to claim 6, wherein the second version of the target transaction is obtained after the first version.

8. The method according to claim 6 or 7, wherein the obtaining of the first version includes receiving at least a part of the first version from the first party.

9. The method according to claim 6, 7 or 8, wherein the obtaining of the first version includes the second party generating the first transaction.

10. According to the method of any one of the foregoing, wherein the second condition requires that the unlocking script includes a cryptographic signature of a part of the target transaction that does not include the first party that is not part of the unlocking script; wherein the obtaining of the updated version of the target transaction includes obtaining the signature of the first party, and the updated version sent for propagation and recording in the blockchain includes the signature of the first party in the unlocking script.

11. According to the method of claim 10, wherein the first condition does not require a cryptographic signature of the first party.

12. According to the method of claim 10 or 11, wherein at least the first condition requires that the unlocking script includes a cryptographic signature of the second party, and the cryptographic signature signs a part of the target transaction that does not include the unlocking script.

13. According to the method of claim 12, wherein the second condition further requires that the unlocking script includes a cryptographic signature of the second party that signs a part of the target transaction that does not include the unlocking script; and the updated version sent for propagation and recording in the blockchain includes the cryptographic signature of the second party in the unlocking script.

14. According to the method of claim 12 or 13, which depends on claim 6, wherein the obtaining of the updated version includes: The second party sends the first version to the first party so that the first party extends it to the updated version by adding the signature of the first party; wherein the first and second conditions require the second party to sign the same part of the target transaction with the same signature, so that the second party does not need to re-sign the updated version.

15. According to the method of any one of the foregoing, wherein the first condition requires that a data payload is included in the unlocking script, but the second condition does not require the data payload to be included in the target transaction; and the updated version sent for propagation through a network and recording in the blockchain does not include the data payload.

16. According to the method of claim 15, wherein: The first condition requires that the unlocking script includes the data payload and the cryptographic signature of the second party, and the cryptographic signature signs a part of the target transaction that does not include the unlocking script, but does not require a cryptographic signature of the first party to be included in the target transaction; The second condition requires that the unlocking script includes the cryptographic signatures of the first party and the second party, but does not require the data payload to be included in the target transaction; The obtaining of the updated version of the target transaction includes obtaining the signature of the first party; The updated version of the target transaction sent for propagation and recording in the blockchain does not include the data payload, but includes the signatures of the first party and the second party in the unlocking script.

17. According to the method of any one of the foregoing, the first output of the first transaction designates a payment to the second party, and the payment is redeemed by unlocking the first output according to the first or second condition, and wherein the target transaction includes an output that transfers at least some of the payment to the second party.

18. The method according to claim 17, comprising, by the computer device of the second party: Streaming a sequence of data portions to the first party, ending with a final portion in the sequence; In response to each corresponding portion of the data portions, receiving back from the first party a corresponding instance of the first transaction, the first output of each instance specifying a payment to the second party for the corresponding portion; Wherein the payment increases with each increasing data portion; Obtaining an updated version of the target transaction includes receiving the updated version from the first party after the final portion in the sequence.

19. The method according to claim 18, wherein the increase is linearly proportional to the number of data portions sent so far.

20. The method according to claim 18 or 19, wherein each data portion is a different portion of a media content item.

21. The method according to claim 18 or 19, wherein each data portion is a different key for accessing a service unit.

22. The method according to claim 21, wherein the service comprises one of the following: - Providing utilities including electricity, gas, water; or - Renting property, vehicles or other physical items.

23. The method according to any one of claims 18 to 22, dependent on claim 2, wherein: - The functionality enables the second party to optionally select at any point in the sequence to manually select to execute the sending of the first version of the target transaction for propagation over the network and recording in the blockchain to redeem the latest instance of the first transaction in the sequence received from the first party so far; and / or - The functionality is configured to automatically execute the sending of the first version for propagation over the network and recording in the blockchain if the first party stops sending instances of the first transaction partway through the sequence to redeem the latest instance of the first transaction.

24. The method according to any one of claims 18 to 23, wherein: The first transaction includes one or more inputs specifying an input amount, the first output of the first transaction specifies a first payment, the first transaction further includes one or more further outputs specifying one or more further payments such that the total amount of the payments is greater than the input amount, and the first transaction received by the second party from the first party does not include other inputs to make up the difference, and the nodes of the network are configured to reject the first transaction as invalid if a total payment greater than the total input amount is specified; The method includes the second party adding a second input to the final or latest instance of the first transaction to make up the difference and sending the first transaction with the second input added for propagation over the network and recording in the blockchain.

25. The method according to claim 24, wherein the further output includes a second output and a third output, the second output specifying a payment to the first party equal to the input amount minus the first payment, and the third output specifying a third payment to the second party equal to a second payment.

26. The method according to any one of claims 17 to 25, wherein the locking script includes a third condition among the alternative conditions, which requires that the locking time has expired and includes an encrypted signature of the first party in the unlocking script, so that if the second party does not redeem within the locking time, the first party can redeem the amount in the first output of the first transaction.

27. The method according to any one of claims 1 to 9, wherein: each of at least some of the alternative conditions corresponds to a different voting option; the method includes accessing or making accessible to a third party the unlocking script in the first version before obtaining an updated version of the target transaction, as a non-binding indication of the voting intention.

28. The method according to claim 27, wherein a locking time is 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 in the blockchain before a predetermined time point.

29. The method according to claim 27 or 28, the output of the first transaction designates redemption by unlocking the first output according to any one of the conditions specified in the locking script, and wherein the target transaction includes an output that transfers at least part of the amount to the first party.

30. The method according to any one of claims 27 to 29, wherein the alternative conditions include: - a first condition corresponding to a polling indication of the first option, - a second condition corresponding to a polling indication of the second option, - a third condition corresponding to a voting option of the first option, - a fourth condition corresponding to a voting option of the second option; wherein the unlocking script of the first version of the target transaction is configured to unlock the first output of the first transaction based on meeting the first or second condition, the unlocking script of the second version of the target transaction is configured to convert the polling indication into a vote by being configured to unlock the first output of the first transaction based on meeting the third condition, rather than the first condition or the fourth condition or the second condition.

31. A computer program embodied on a computer-readable memory and configured to perform the method according to any one of claims 1 to 30 when run on a computer device of the first party and / or the second party.

32. The computer device of the first party and / or the second party, comprising: a memory including one or more memory units, a processing device including one or more processing units; wherein the memory stores code configured to run on the processing device and perform the method according to any one of claims 1 to 30 when run on the processing device.

33. A set of transactions for recording in a blockchain, the set including on a computer-readable data medium or medium: a first transaction having an output including a locking script that specifies a plurality of alternative conditions for unlocking the output of the first transaction; The first version of the second transaction has an input containing an unlocking script and a pointer to the output of the first transaction, wherein the unlocking script of the 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; The second version of the second transaction has an input containing an unlocking script and a pointer to the output of the first transaction, wherein the unlocking script is configured to unlock the output of the first transaction based on satisfying a second one of the alternative conditions, rather than the first condition.

Images