Method of using side channel

Abstract

To provide a system and method for negotiating over a side channel according to a transaction protocol of a network, in a blockchain.SOLUTION: A method comprises: sending a proposed instance to a second party over a side channel, the proposed instance being formulated according to a transaction protocol recognized by nodes for validating transactions, and specifying a set of values of parameters of the transaction including the amount of digital asset; upon the second party not accepting the proposed instance of the first transaction, receiving, over the side channel, a counter-proposed instance of the first transaction, the counter-proposed instance being formulated according to the transaction protocol, but specifying a modified set of values of the transaction parameters; and a first party selecting whether to accept the received counter-proposed instance.SELECTED DRAWING: Figure 3A

Description

[Technical field]

[0001] This disclosure relates to methods for using "off-chain" side-channels in the context of blockchain-based systems. [Background technology]

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

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

[0004] Each node in the network can have one, two, or all three roles: forwarding, mining, and storing. Each forwarding node propagates a (valid) transaction to one or more other nodes, thus propagating the transaction among themselves throughout the nodes of the network. Each mining node competes to execute said mining of a transaction into a block. Each storing node stores its own copy of the mined block of the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes of the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol. This protocol includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or mined into a block. Assuming the transaction is validated and therefore accepted into the blockchain, said additional user data remains stored in each of said nodes in the P2P network as an immutable public record.

[0005] Miners who successfully solve the proof-of-work puzzle to create an updated block are typically rewarded with a transaction called a "generation transaction" that generates a new amount of the digital asset. The transaction may also optionally specify an additional mining fee for successful miners. Proof-of-work provides an incentive for miners not to try to cheat the system by including double-spend transactions in their blocks, because mining a block requires a large amount of computational resources and blocks that contain double-spend attempts are unlikely to be accepted by other nodes.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any usable output includes an element that specifies an amount of digital assets. This element is sometimes called a UTXO (unspent transaction output). The output may further include a locking script that specifies a condition for redeeming the output. Each input includes a pointer to such an output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Now consider a pair of transactions, call them a first and a second transaction. The first transaction includes at least one output that specifies an amount of digital assets and includes a locking script that defines one or more conditions for unlocking the output. The second transaction includes at least one input that includes a pointer to an output of the first transaction and an unlocking script to unlock the output of the first transaction.

[0007] In such a model, when a second transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the requirements for validity applied at each node would be that the unlocking script meets the requirements defined in the locking script of the first transaction. Another condition for the validity of the second transaction would be that the output of the first transaction has not already been redeemed by another valid transaction. A node that finds the second transaction to be invalid based on any of these conditions will not propagate it or include it for mining into a block to be recorded in the blockchain.

[0008] Suppose the second transaction is to transfer an amount of digital assets from a first party ("Alice") to a second party ("Bob"). One of the criteria defined in the preceding locking script of the first transaction is typically that the unlocking script of the second transaction contains a cryptographic signature of Alice. The signature must be generated by Alice signing a portion of the target transaction. Which portion this is may be flexibly defined by the unlocking script or, depending on the protocol used, may be an inherent feature of the node protocol. Nevertheless, the portion that is signed typically excludes some other portion of the target transaction, e.g., some or all of the unlocking script itself.

[0009] This creates the possibility of "malleability" - that parts of the target transaction that are not signed can be modified ("forged") before mining and still not invalidate the transaction. Malleability is a known concept in cryptography in general, where the concept is usually seen as a security concern where messages can be maliciously modified and still be accepted as being of interest. In the context of blockchain, malleability is not necessarily a concern, but simply known as a strange artifact where some parts of a transaction can be modified without invalidating the transaction.

[0010] Recently, proposals have been made to intentionally exploit malleability in order to use transactions as carriers of media data. Data content can be included in the unlocking script of a transaction, which is then sent between the parties through a side channel called the "payment channel." One of the parties then forges the transaction to remove said data and sends the forged version to the P2P network to be mined (whereas if the data had not been removed, the transaction would bloat the blockchain, typically requiring higher mining fees as well, since the reward required by miners to accept a transaction typically scales with the size of the transaction in bytes or kilobytes).

[0011] It is also known to establish side channels (sometimes called "payment channels") to send complete, valid transactions between parties "off-chain" before the transactions are broadcast to the P2P network to be recorded on the blockchain. Side channels are separate from the P2P overlay network, and thus any transaction sent through a side channel is not (yet) propagated to the entire network for recording on the blockchain until one of the parties chooses to publish it to the network. Summary of the Invention [Problem to be solved by the invention]

[0012] There are problems with the existing configuration in that it can lead to network congestion. For example, consider a scenario where Alice wants her transaction to be mined into a block and thus stored on the blockchain, but does not know at this time how much mining fee is likely to be accepted. This can be especially (but not only) problematic if the transaction in question contains a data payload. Mining fees typically scale with the amount of data contained in the transaction, and as mentioned above, transactions can now contain data payloads to store content on-chain. For example, Alice wants a document or a movie clip to be stored on-chain. If the mining fees are not sufficient, miners will not accept the transaction, even if it is technically valid (the protocol does not force miners to accept valid transactions, so miners must be incentivized to do so).

[0013] Normally, Alice would have to start by publishing her transaction to the P2P network offering a relatively low mining fee, then wait to see if it gets mined into a block, and if not, publish another instance of that transaction offering a slightly higher fee, until finally the transaction is accepted for mining and included in a block. This leads to network congestion due to the publication of many transactions that will not be accepted for mining. [Means for solving the problem]

[0014] According to embodiments disclosed herein, this can be mitigated by Alice pre-negotiating the mining fee with Bob through a side channel. Once the amount is agreed upon, Alice or Bob will publish only the agreed instance of said transaction to the network specifying the agreed amount (in embodiments, lock time may be another negotiated condition). A side channel used in this way is referred to herein as a negotiation channel (although it is not excluded that the same channel may also be used for additional purposes).

[0015] However, there is a technical problem in implementing negotiation channels, namely, interoperability. There are many different types of client applications in circulation to access a given P2P network and blockchain. For example, those types may be clients made by different developers, or different releases of a client made by a given developer. It may be undesirable, or even infeasible, to coordinate Alice and Bob (or any two parties that may wish to negotiate) to run client applications that understand the same communication protocol for formatting messages sent over the side channel. However, the only protocol that Alice and Bob's clients must always have in common is the same transaction protocol. Thus, the present disclosure provides a method for negotiating over a side channel using a scheme of template transactions formatted according to the network's transaction protocol.

[0016] A similar mechanism can be used for other negotiations between Alice and Bob, not just in scenarios where Bob is a minor.

[0017] According to an aspect disclosed herein, a computer-implemented method is provided for recording in a blockchain at least a first transaction transferring an amount of a digital asset from a first party to a second party. A copy of the blockchain is maintained among at least a portion of a network of nodes. The method includes, at a first party's computer equipment: establishing a side channel separate from the network, the side channel being established between a first application on the first party's computer equipment and a second application on the second party's computer equipment; and performing a negotiation procedure. The procedure includes: a) formulating a proposed instance of a first transaction and sending the proposed instance through the side channel to a second party, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network to validate transactions and specifying a set of one or more values ​​for one or more parameters of the transaction including at least the amount of the digital asset; b) when the proposed instance of the first transaction is not accepted by the second party, receiving a counter-proposed instance of the first transaction through the side channel, the counter-proposed instance also formulated according to the transaction protocol but specifying a modified set of one or more values ​​for the one or more transaction parameters; and c) selecting whether to accept the counter-proposed instance received at the first party in b).

[0018] The modified set of values ​​may have one, some or all of the values ​​modified compared to the initial set. The parameters whose values ​​are modified may include the quantity of the digital asset and / or one or more other parameters, such as a lock time.

[0019] In embodiments, c) may include: upon choosing not to accept the counterproposed instance received in b): formulating a further counterproposed instance of the first transaction and sending the further counterproposed instance to the second party via the side channel for acceptance by the second party, the further counterproposed instance also formulated in accordance with the transaction protocol but specifying a further set of one or more values ​​for the one or more transaction parameters.

[0020] In embodiments, at least in the first occurrence of b), the second party may not accept the further counterproposed transaction. In this case, following c), the procedure instead returns to b) and continues from b) until one of the parties accepts either the counterproposed transaction or a further counterproposed transaction. In some cases, continuing the procedure may include at least one repeated occurrence of both b) and c).

[0021] The further modified set of values ​​may modify one, some or all of the values ​​compared to the previously modified set. Again, the parameters whose values ​​are modified may include the amount of the digital asset and / or one or more other parameters, such as a lock time.

[0022] In embodiments, the acceptance includes: an accepted instance of the first transaction being propagated on the network and thereby sent for recording on the blockchain.

[0023] Two (or more) transactions may be said herein to be (substantially) instances of the same transaction if they both contain an input that references the same output (e.g., a UTXO) of the same source transaction (or "zeroth" transaction). They may redeem that input based on meeting the same unlocking conditions. However, in embodiments, they may contain different input signatures (i.e., the signed messages in each instance are not identical).

[0024] For each of the multiple transactions, including the first transaction, at least some nodes of the network are configured to propagate each transaction on condition that the transaction is valid, and at least some nodes are configured to record each transaction in the node's copy of the blockchain on condition that the transaction is valid. In an output-based model, the validity of the second or target transaction is conditional on the unlocking script unlocking the output of the first transaction. Typically, a transaction is considered valid only if the total value of the digital assets pointed to by the sum of its one or more inputs is at least equal to the total value of the digital assets specified in the sum of its one or more outputs. Furthermore, each node in the network is also configured such that once one of the instances is validated at any given node, other instances are considered invalid by that node and thus are not propagated or recorded in the blockchain by that node.

[0025] Once the output of a source transaction is found to be validly redeemed by a subsequent transaction at a given node, other instances of that subsequent transaction are considered invalid at that node. 1、 Tx 1 ', Tx1 "..." will be recognized by each node in the network as an instance of effectively the same transaction, because each instance is derived from the same preceding source transaction (Tx 0 This is because one instance of the first transaction (e.g., Tx 1 , Tx 1 As soon as a source transaction (for example, Tx 0 ) is consumed and therefore cannot be consumed by other instances. Thus, only one instance can be recorded in the blockchain. Furthermore, once one of the instances of the first transaction has been consumed, it is possible for any version of the second or target transaction (e.g., Tx in the later examples) to be recorded in the blockchain at any given node. p ), any further versions of that second transaction that attempt to redeem that instance of the first transaction are considered invalid by that node and therefore will not be propagated by that node or recorded on the blockchain.

[0026] In some embodiments, the proposed instance of the first transaction in a) may take the form of a template transaction having complete and incomplete parts and thus not yet valid according to the node protocol. In this case, the proposed transaction is said to be formulated according to the transaction protocol in that at least said complete parts are formulated according to the transaction protocol. In such embodiments, the accepted instance has incomplete parts that are completed by the first party and / or the second party.

[0027] In some embodiments, the second party may be a miner, and the amount of the digital asset provides a payment for the second party to perform a proof-of-work operation to cause a version of a second transaction that includes a data payload to be included in a block of the blockchain, where a locking script requires at least an unlocking script in an input of the second transaction to include the data payload in order to redeem the payment.

[0028] For example, the data payload may include a document including text, and / or media content including audio and / or video. In a particularly advantageous (but not required) embodiment, the data payload may be communicated from the first party in a portion of one of the instances of the first transaction. Preferably, it is communicated in a portion that is not required to be signed, so that the data payload can be removed from the first transaction before being sent for propagation through the network.

[0029] According to a further aspect disclosed herein, there is provided a program for carrying out the method and / or a second party computer equipment programmed to carry out the method. [Brief description of the drawings]

[0030] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system implementing a blockchain. [Diagram 2] 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 2 is another schematic block diagram of a system for implementing a blockchain. [Figure 3A]FIG. 2 is another schematic block diagram of a system for implementing a blockchain. [Figure 4] FIG. 2 is a schematic block diagram of a client application. [Diagram 5] 5 is a schematic mock-up of an exemplary user interface that may be presented by the client application of FIG. 4. [Figure 6] FIG. 2 is a schematic diagram of a set of transactions. [Figure 7] FIG. 13 is a schematic diagram of a collection of template transaction instances for negotiation through a side channel. [Figure 8] FIG. 13 is a schematic diagram of another set of template transaction instances for negotiation through a side channel. [Figure 9] 1 is a signaling chart illustrating how data may be communicated from a first party to a second party. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] FIG. 1 illustrates an exemplary system 100 for generally implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer's computing equipment, with different nodes 104 belonging to different peers. Each node 104 includes one or more processors, e.g., processing units including one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (ASICs). Each node also has memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disk drives.

[0032] The blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing a quantity of digital assets belonging to a user 103, and the output is cryptographically locked to that user (requiring the signature of that user in order to be unlocked and thereby redeemed or spent). Each input references back to the output of a preceding transaction 152, thereby linking the transactions.

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

[0034] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the current transaction 152j. In general, the preceding transaction can be any transaction in the pool 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, in this specification, "predecessor" refers to a predecessor in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in a temporal sequence, and thus does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below on orphan transactions). The preceding transaction 152i can be equivalently referred to as a prior transaction or a predecessor transaction.

[0035] The input of the current transaction 152j also includes the signature of the user 103a to which the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically 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, a transaction 152 may have multiple outputs to split the input amount among multiple users (one of which may be the original user 103a to provide change). In some cases, a transaction may have multiple inputs and may pool together amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0036] The above is sometimes called an "output-based" transaction protocol, or sometimes called an unspent transaction output (UTXO) type protocol. A user's total balance is not defined in any one number stored in the blockchain, instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are spread across many different transactions 152 in the blockchain 151. An alternative type of transaction protocol is sometimes called an "account-based" protocol, as part of an account-based transaction model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by referencing the UTXOs of previous transactions in a sequence of past transactions. The current state of every account is stored and constantly updated by miners separately from the blockchain. This disclosure is concerned with an output-based model, rather than an account-based one.

[0037] In either type of transaction protocol, when a user 103 wants to enact a new transaction 152j, he sends the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P network 106 (today this is typically a server or a data center, but in principle it could be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied at each node 104. The details of the node protocols correspond to the type of transaction protocol used in the blockchain 150 in question, and together they form an overall transaction model. The node protocol typically requires the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the preceding transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking that the cryptographic signature of the user included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction spends, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, the condition may be defined, at least in part, by custom script included in the input and / or output. Alternatively, the condition may be fixed solely by the node protocol, or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes of the nodes 104 in the P2P network 106.At least some of these nodes 104 also act as forwarding nodes 104F and forward the new transaction 152j according to the same node protocol and applying the same tests to one or more further nodes 104. In this manner, the new transaction is propagated throughout the network of nodes 104.

[0038] In the output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has already been validly redeemed by an input of another, onward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it is trying to spend or redeem has not already been spent / redeemed by another valid transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This protects against double-spending, where a user tries to spend the same transaction output multiple times.

[0039] In addition to validity checking, at least some of the nodes 104M compete to be the first to generate a block of transactions, in a process known as mining, which is backed by a "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has some predefined number of leading zeros. A property of a hash function is that it has an output that is unpredictable with respect to the input. Thus, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each node 104M trying to solve the puzzle.

[0040] The first miner node 104M that solves the puzzle announces this to the network 106 and provides its solution as a proof. The proof can be easily checked by other nodes 104 in the network (once the solution to the hash is given, it is easy to check that the hash output matches the conditions). The pool 154 of transactions for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's published solution at each such node. A block pointer 155 that points back to the previously generated block 151n-1 in the chain is also assigned to the new block 151n. Proof of work helps to reduce the risk of double-spends. Since it takes a lot of effort to create a new block 151, and a block containing double-spends is likely to be rejected by other nodes 104, there is no incentive for a mining node 104M to allow its block to contain double-spends. Once created, blocks 151 cannot be modified because they are recognized and maintained according to the same protocol at each of the storage nodes 104S in the P2P network 106. Block pointers 155 also impose a sequential order on the blocks 151. This provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

[0041] Note that different miners 104M competing to solve the puzzle at any given time may do so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started looking for a solution. Whoever solves the respective puzzle first defines which transactions 152 will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. Miners 104M then continue to compete to generate blocks from the newly defined pending pool 154. There are also protocols to resolve possible "forks," where two miners 104M solve a puzzle within a very short time of each other, and inconsistent views of the blockchain propagate. In essence, whichever branch of the fork grows the longest will be the deterministic blockchain 150.

[0042] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of nothing (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generating" transaction. It automatically forms part of a new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. Regular (non-generating) transactions 152 often also specify an additional transaction fee in one of their outputs, further rewarding the winning miner 104M who generated the block 151n in which the transaction was included.

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

[0044] The memory of each node 104 stores software configured to run on the processing unit of the node 104 to perform its respective role(s) and process transactions 152 according to the node protocol. It will be understood that any operations attributed to the nodes 104 herein may be performed by software executing on the processing unit of the respective computing device. Additionally, the term "blockchain" as used herein is a general term referring to this type of technology in general and is not limited to any particular specific blockchain, protocol or service.

[0045] Also connected to the network 101 are computer equipment 102 of a number of parties 103 in the role of consuming users. These act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions for the other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and its respective computer equipment 102a, and a second party 103b and its respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but this is not intended to be limiting, and it will be understood that any reference herein to Alice or Bob may be substituted with "first party" and "second party," respectively.

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

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

[0048] The client application 105 has at least a "wallet" functionality, which has two main functions. One of these is to allow each user party 103 to create, sign and send transactions 152 that are propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of the various 152 transactions belonging to that party scattered throughout the blockchain 150.

[0049] An instance of a client application 105 on each computer facility 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 may also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, indeed, to inspect the transactions of other parties in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides credit for transactions, in part, through its public visibility). The wallet functionality on each computer facility 102 is configured to formulate and transmit transactions 152 according to a transaction protocol. Each node 104 executes software configured to validate the transactions 152 according to the node protocol and, in the case of the forwarding node 104F, to forward the transactions 152 for propagation throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol together with a given node protocol implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow different subtypes of transactions within it). The same node protocol is used by all nodes 104 in the network 106 (although different subtypes of transactions may be handled differently according to rules defined for the subtypes, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

[0050] As described above, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 that points back to a previously created block 151 in the chain to define a sequential order to the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 includes a pointer that points back to a previous transaction to define an order for sequences of transactions (sequences of transactions 152 are allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to a genesis block 153, not a predecessor transaction.

[0051] When a given party 103, say Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in Alice's client application 105) according to the relevant transaction protocol. Alice then transmits the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which she is connected. For example, this may be the forwarding node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to be "valid". Examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol, or may be defined by a combination of scripts and the node protocol.

[0052] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any storage node 104S that receives the transaction 152j adds the newly validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j further propagates the validated 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 that the transaction will soon be propagated throughout the P2P network 106.

[0053] Once accepted into the pool 154 in the copy of the blockchain 150 maintained by one or more storage nodes 104, the miner nodes 104M start competing to solve the proof-of-work puzzle for the latest version of the pool 154 that contains the new transaction 152 (other miners 104M may still be trying to solve the puzzle based on their old view of the pool 154, but whoever gets there first will define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j). Once the proof-of-work is done for the pool 154 that contains the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150 in an immutable way. Since each transaction 152 contains a pointer to the previous transaction, the order of the transactions is also immutably recorded. Different nodes 104 may initially receive different instances of a given transaction and thus have conflicting views of which instance is "valid" until one instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts an instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept this and discard (treat as invalid) the unmined instance it originally accepted.

[0054] FIG. 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of the blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation for all possible embodiments.

[0055] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). The UTXO may also include, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also include a header 201, which may include indicators of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include the ID of the transaction. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0056] Suppose Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice’s new transaction 152j begins with “Tx 1 This takes some amount of the digital assets locked in Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled “Tx 0 " Tx 0 and Tx 1 are simply arbitrary labels. They do not necessarily refer to Tx 0 is the first transaction on the blockchain, or Tx 1 This does not mean that Tx is the next transaction in the pool 154. 1can point back to any preceding (i.e., prior) transaction that still has unspent outputs 203 locked to Alice.

[0057] Preceding transaction Tx 0 Alice creates the new transaction Tx 1 At the time of creating Tx, or at least by the time Alice sends it to the network 106, it may already be verified and included in the blockchain 150. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 154, in which case it will soon be included in a new block 151. Alternatively, Tx 0 and Tx 1 can be generated together and sent to the network 102, or even Tx if the node protocol allows for buffering of "orphan" transactions. 0 Tx 1 A transaction may also be sent after a parent transaction. The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers (i.e., which transactions point to which other transactions) specified in the transaction. The terms may be equivalently replaced with "predecessor" and "successor" or "predecessor" and "descendant," "parent" and "child," etc. This does not necessarily mean the order in which they are created, sent to the network 106, or arrive at any given node 104. Nevertheless, a successor transaction (descendant transaction or "child") that points to a predecessor transaction (predecessor transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. An orphan may be discarded or buffered for some time to await its parent, depending on the node protocol and / or miner behavior.

[0058] Preceding transaction Tx 0 One of the one or more outputs 203 of the 0 Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO, and a locking script. The locking script defines the conditions that must be met by the unlocking script in the input 202 of a subsequent transaction for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks said amount to a specific party (the beneficiary of the transaction in which it is included). That is, the locking script defines the unlocking conditions, and typically includes a condition that the unlocking script in the input of a subsequent transaction includes a cryptographic signature of the party to which the preceding transaction is locked.

[0059] A locking script (aka scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). The locking script specifies what information is needed to use the transaction output 203, e.g., requiring Alice's signature. The unlocking script appears in the transaction output. An unlocking script (aka scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. The unlocking script appears in the transaction input 202.

[0060] In the illustrated example, Tx 0 UTXO in output 203 0 The lock script [Checksig P A ], which is a UTXO 0 In order for the UTXO to be redeemed (strictly speaking, 0(For any subsequent transaction attempting to redeem ) to be valid, Alice’s signature Sig P A [Checksig P A ] is the public key P from Alice’s public-private key pair. A Includes Tx 1 The input 202 of the Tx 1 (e.g., in embodiments, transaction Tx 0 The transaction ID, TxID, which is a hash of the entire transaction 0 Contains a pointer to Tx 1 The input 202 of the Tx 0 To distinguish it among any other possible outputs of Tx 0 UTXOs in 0 Contains an index that identifies the Tx 1 input 202 further includes an unlock script containing Alice's cryptographic signature, created by applying Alice's private key from the key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination of these.

[0061] New transaction Tx 1 When the message arrives at node 104, the node applies the node protocol, which runs the lock script and the unlock script together to check if the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In some embodiments, this involves concatenating the two scripts: <Sig P A > <P A >||[Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions to be included in the unlock script (a stack-based language in this example). When executed together, the scripts are called Tx 0 The lock script in the output of A Using Tx 1 verifies that the lock script at Tx's input contains Alice's signature, which signs the expected portion of data. To perform this authentication, the expected portion of data itself (the "message") must also be present in Tx 0 In embodiments, the signed data must be included in Tx 0 (Thus, there is no need to include a separate element that specifies the signed portion of the data in plaintext, since the signed portion of the data is already implicitly present).

[0062] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the message in plaintext (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the plaintext version of the message with it as the signature, thereby allowing any holder of the public key to authenticate the signature. Thus, any reference herein to signing a particular piece of data or transaction, etc., can, in embodiments, mean signing a hash of that piece of data or transaction.

[0063] Tx 1 The unlock script for Tx 0 If one or more conditions specified in the lock script of 1, if provided and authenticated in Tx 1 is valid. If it is a storage node 104S, this means that it adds it to the pool 154 of transactions awaiting proof-of-work. If it is a forwarding node 104F, it considers transaction Tx 1 to one or more other nodes 104 in the network 106. 1 Once validated and included in the blockchain 150, this is called Tx 0 UTXO from 0 Define Tx as used. 1 Note that Tx may only be valid if it uses an unused transaction output 203. If it attempts to use an output that has already been used by another transaction 152, Tx 1 Therefore, the node 104 does not recognize the preceding transaction Tx 0 It is also necessary to check whether a referenced UTXO in has already been spent (whether it already forms a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO has been spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0064] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction will not be propagated or mined into a block 151.

[0065] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave" some of the amount defined in the spent UTXO while another amount is spent. However, the amount from the UTXO can be split among multiple outputs of the following transaction. For example, Tx 0 UTXO in 0 The quantity defined in is Tx 1 Therefore, Alice can send UTXO to Bob. 0 If you do not want to give the entire amount defined by Tx 1 At the second output of the transaction, the user can give himself or herself change or pay another party.

[0066] In practice, Alice would typically also need to include a fee for winning miners, because today, the reward for generating transactions alone is typically not enough to incentivize mining. If Alice does not include a fee for miners, Tx 0 will likely be rejected by the miner nodes 104M, and thus, although technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force the miner 104M to accept the transaction 152 if he does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically awarded to the winning miner 104. For example, a UTXO 0 A pointer to Tx 1 is the only input to the Tx 1 One output UTXO 1 And let's say it doesn't work. UTXO 0 The amount of digital assets specified in1 If the miner's fee is greater than the amount specified in the UTXO 203 of transaction 152, then the difference automatically goes to the winning miner 104M. However, nothing necessarily precludes that the miner's fee may alternatively or additionally be explicitly specified in its own one of the UTXOs 203 of transaction 152.

[0067] Alice and Bob's digital assets consist of unspent UTXOs locked by both of them anywhere in the blockchain 150 in any transaction 152. Thus, typically, the assets of a given party 103 are distributed across UTXOs of various transactions 152 throughout the blockchain 150. No one number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked by each party and not yet used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in one of the storage nodes 104S, for example the storage node 104S that is closest to or best connected to the computer equipment 102 of each party.

[0068] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ] and write [Checksig P A ]=OP_DUP OP_HASH160 <H(P A)>OP_EQUALVERIFY can mean OP_CHECKSIG. "OP_..." refers to a specific opcode in the Script language. OP_CHECKSIG (also called "Checksig") is a Script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, all occurrences of the signature ('sig') are removed from the script, but additional requirements such as hash puzzles remain for transactions to be verified by the 'sig' input. As another example, OP_RETURN is a Script language opcode to store metadata within the transaction, thereby generating an unspendable output of the transaction that can record the metadata in an immutable manner in the blockchain 150. For example, the metadata can include a document that is desired to be stored in the blockchain.

[0069] signature P A is a digital signature. In embodiments, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs specific data. In embodiments, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific parts of the outputs that are signed depend on the SIGHASH flag, which is a 4-byte code included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0070] A lock script is sometimes called a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script is sometimes called a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, one or more conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" are sometimes preferred.

[0071] FIG. 3 illustrates a system 100 for implementing a blockchain 150. The system 100 is substantially the same as described in connection with FIG. 1, except that an additional communication function is included. The client applications of each of Alice's and Bob's computer facilities 102a, 120b each have an additional communication function, i.e., whereby Alice 103a can establish (at the instigation of either party or a third party) a separate side channel 301 with Bob 103b. The side channel 301 allows for the exchange of data separately from the P2P network. Such communication may be referred to as "off-chain." For example, this may be used to exchange transactions 152 between Alice and Bob without the transactions being published (yet) on the network P2P 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transactions to the network 106.

[0072] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or over a direct wired or wireless link between the Alice and Bob devices 1021, 102b. In general, the side channel 301 referred to anywhere herein may include any link or links over one or more network technologies or communication media for exchanging data “off-chain”, i.e., separately from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, it should be noted that when it is said that Alice and Bob exchange certain information or data, etc., over the side channel 301, this does not necessarily mean that all such data must be transmitted over exactly the same links or the same type of network.

[0073] FIG. 3A shows a variation of the configuration shown in FIG. 3. In this variation, Bob 103b is also a miner. Bob's computing equipment, here labeled 104Mb, may be configured to operate as described in connection with both user device 102b and miner node 104M. It is configured to run client application 105b, including a wallet application, and also run miner software. The wallet and miner software may be integrated into the same application, or may be implemented across two or more applications. Bob's equipment may take any of the forms previously described in connection with user device 102b or miner equipment 104M. Such a configuration may have applications where Alice would like to specify a particular fee for Bob to mine transactions 152 into blocks 151 on her behalf. This will be discussed in more detail shortly by way of example. In practice, it should be noted that typically most or all of the mining nodes 104M are in fact associated with wallet applications 105 run by their operators to enable those operators to receive and spend mining fees. For simplicity, these miners are not shown in the diagram because they are not involved as specific identified parties to the transactions in the example use cases below (other than as possibly being the miner who mines one of the transactions in block 151 in some cases).

[0074] Illustrative Definitions Below are some example definitions that may be employed in some implementations. Note that these are not limiting for all possible implementations, but are provided only to aid in understanding certain possible implementations, as may be used in some possible implementations of the example use cases described below.

[0075] Definition 1: Transaction. A transaction is a message that contains inputs and outputs. It may also contain a protocol version number and / or a lock time. The version indicates the version of the transaction protocol. The lock time is explained separately below.

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

[0077] Definition 3: Outputs. The outputs of a transaction form an ordered list. Each entry in the list contains a value (an amount of digital assets, in base units) and a scriptPubKey (a locking script).

[0078] Definition 4: Outpoint. An outpoint is uniquely defined by a transaction ID TxID and an index number i. It points to the i-th entry in the output of transaction TxID and gives a unique location of an unspent transaction output (UTXO). The term "unspent" here means that the outpoint has never appeared in any valid subsequent transaction.

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

[0080] Definition 6: scriptPubKey. This is the script that locks the funds associated with a particular UTXO. The funds can be unlocked and spent if and only if the scriptPubKey is appended with a scriptSig and the execution of the combined script gives TRUE. Otherwise the transaction is invalid and is rejected. It is called a "scriptPubKey" because it generally contains the hash value of the ECDSA public key for a standard transaction. In the following definitions of signing an input(s), this means signing the input(s) (see Definition 2) excluding the scriptSig part.

[0081] Definition 7: SIGHASH flags. When providing an ECDSA signature, one of the following SIGHASH flags must also be appended: [Table 1]

[0082] When talking about malleability as a function, we look for information in the transaction that is not signed with an ECDSA signature. Besides inputs and outputs that can be excluded from the message being signed, the contents of the scriptSig are always excluded. This is because the scriptSig is designed to be a placeholder for the signature.

[0083] Definition 8: Blockchain timelocks. In general, there are two types of timelocks that can be used in transactions: absolute and relative. Absolute timelocks specify a specific point in time after which something can be considered "valid", while relative timelocks specify a period of time that must pass before something can be considered valid. In either case, when using blockchain timelocks, one can use either the block height (the number of blocks mined) or elapsed time (such as UNIX time) as a proxy for time.

[0084] Another characteristic of blockchain timelocks is where they appear and to which aspect or aspects of a transaction they apply. In this sense, there are again two classifications: transaction level, which locks entire transactions, and script level, which locks specific outputs. Both of these timelock levels can be used to implement absolute or relative timelocks. The table below summarizes four possible mechanisms for implementing timelocks that can be created based on these characteristics. [Table 2]

[0085] Definition 9: nLocktime. The locktime (nLocktime) is a non-negative integer representing a block height or a specific time in Unix time. It is a transaction-level time lock in the sense that a transaction can only be added to the blockchain in the specified block or after the specified time. If nLocktime is set to less than 500,000,000, it is considered a block height. If it is set to 500,000,000 or greater, it is considered a representation of Unix time. It is the number of seconds since 00:00:00 on January 1, 1970. For example, if the current highest block is 3,000,000 high and the lock time is set to 4,000,000, then the transaction will not be considered by miners until the 4,000,000th block has been mined.

[0086] Definition 10: nSequence. The sequence number (nSequence) indicates the version of a transaction as a message. Any modification to a transaction increments the sequence number to a larger number. The maximum value of nSequence is 2. 32-1, and typically the sequence number defaults to this maximum value to indicate that the transaction is finalized. A nSequence value is defined for each input of a transaction, and is set when the UTXO referenced by that input is included in a block. rear specifies the time period before which a transaction can be used as a valid input. If a miner sees two transactions with the same input, the miner will choose the transaction with the higher sequence number. However, this feature is usually disabled.

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

[0088] Definition 12: CheckSequenceVerify (OP_CSV). The opcode OP_CHECKSEQUENCEVERIFY (OP_CSV) is a relative script-level timelock that can be used to lock a particular output of a transaction for a specific time period or number of blocks in the future. It works similarly to OP_CLTV, except that the parameters provided to OP_CSV represent a relative time. If the parameters specified prior to the OP_CSV operation exceed the current Unix time or block height at which the UTXO is referenced in the transaction, then the script execution for the spending transaction will fail.

[0089] Definition 13: Malleability. In general, there are two broad types of malleability possible in blockchain transactions, both of which allow the contents of a transaction to be modified without invalidating the signatures provided in the inputs.

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

[0091] Type 1: Script-level malleability. This type of malleability exploits the fact that the signature checked with the script opcode OP_CHECKSIG does not sign the script fields of any inputs in the transaction. Because of this fact, it is possible to generate a signature for transaction Tx, modify the input script such that transaction Tx' is not identical to transaction Tx, and still have both Tx and Tx' be considered valid transaction messages signed by the same signature under the blockchain consensus rules.

[0092] Type 2: Input and Output Level Malleability. This type of malleability relies on the use of SIGHASH flags other than SIGHASH ALL in a transaction. If a transaction Tx has an input signature that uses any of the other five SIGHASH flag combinations, then either the input(s) or the output(s) can be added to produce a non-identical transaction Tx' such that both are considered valid transaction messages according to consensus without the need to change the signature.

[0093] Negotiation Channel FIG. 4 illustrates an exemplary implementation of a client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to perform the underlying transaction-related functions of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data over a side channel 301, and / or sending transactions for propagation through the P2P network 106, in accordance with the schemes described above and discussed in more detail shortly. According to embodiments disclosed herein, the transaction engine 401 of each client 105 includes application functionality 403 in the form of a selection function that selects two or more different instances of a first transaction (Tx 1-template , Tx 1 , Tx 1 ', etc.) will be offered or accepted. The selection function 403 may be configured to broadcast the instance of the transaction to the network 106, i.e., to be transmitted from the respective computer facility 102 to be propagated through the P2P network 106 for validation and recorded in the blockchain 150 (the propagation and recording itself being by the mechanisms described above). Note that again, this transmission may involve transmitting the target transaction directly from the respective computer facility 102 to one of the forwarding nodes 104F of the network 106, or transmitting the target transaction to the other party's facility 102 or to a third party facility to be forwarded from there to one of the nodes 104F of the network 106.

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

[0095] NOTE: Although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting and may instead be implemented in a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Wherever reference is made herein to a single or given application 105, etc., it will be understood that this is merely an example and that more generally, the described functionality may be implemented in any form of software.

[0096] 5 provides a mock-up of one example of a user interface (UI) 500 that may be rendered by the UI layer 402 of client application 105a on Alice's equipment 102a. It will be appreciated that a similar UI may be rendered by client 105b at Bob's equipment 102b, or at any other party's equipment.

[0097] As an example, FIG. 5 shows the UI 500 from Alice's perspective at three different stages a), b), c) of the negotiation procedure. During the course of this procedure, the user interface 500 may render multiple user-selectable options, e.g., 501, 502, 503, 504, which may be rendered as separate UI elements via user output means, e.g., different on-screen buttons, or different options in a menu. The user input means is configured to allow the user 103 (in this case, Alice 103a) to select one of the options, such as by clicking or touching an on-screen UI element, or by speaking the name of the desired option (Note: the term "manual" as used herein is only intended to contrast with automatic, and is not necessarily limited to the use of hand(s)). These options allow the user (Alice) to select to propose and accept a transaction via the side channel 301, which will be described in more detail shortly. The user interface 500 may also include one or more data entry fields, e.g. 505, 507, presented at one or more stages, through which the user may enter details identifying the other party (Bob) with whom to initiate negotiations, and / or enter one or more parameters of the proposed transaction (e.g. amount or lock time). These data entry fields may be rendered via user output means, e.g. on a screen, and data may be entered into these fields via user input means, e.g. a keyboard or touch screen. Alternatively, data may be received verbally, e.g. based on speech recognition. The UI 500 may also render one or more notifications 506, presented through the user output means, at one or more stages of the procedure. For example, this(s) may be rendered on a screen or audibly.

[0098] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not important. The functionality of these UI elements will be described in more detail shortly. It will also be understood that the UI 500 shown in FIG. 5 is merely a schematic mockup and may in fact include one or more additional UI elements that are not shown for simplicity.

[0099] 6 illustrates a set of transactions 152 for use in accordance with the embodiments disclosed herein. The set includes a zeroth transaction Tx 0 , the first transaction Tx 1 , and a second transaction Tx p Note that these names are merely convenient labels. They do not necessarily mean that these transactions are placed one after the other in block 151 or blockchain 150, or that the zeroth transaction is the initial transaction in block 151 or blockchain 150. Also, these labels do not necessarily imply anything about the order in which the transactions are sent to the network 106. They only relate to the logical sequence in which the output of one transaction is pointed to by the input of the next transaction. Recall that in some systems it may be possible for a parent to be sent to the network 106 after its children (in which case an "orphan" child is buffered for a period of time in one or more nodes 104 while waiting for its parent to arrive).

[0100] The embodiment optionally includes a second transaction Tx pA negotiation procedure may allow different alternative versions of a first transaction, Tx, to be used. These are said to be versions of the (effectively) same transaction if they both contain inputs that refer to the same output of the first transaction (e.g., the same UTXO). The different versions may provide different functionality by satisfying different unlock conditions for that output. A negotiation procedure, which will be discussed shortly, allows two or more different instances of a first transaction, Tx 1-template , Tx 1 , Tx 1 ', T x 1", where two (or more) transactions are related to the same source transaction (or "zeroth" transaction) Tx 0 Different instances of a first transaction may be said to be (substantially) instances of the same first transaction if they contain inputs that reference the same output (e.g., UTXO) of the first transaction. They may redeem their inputs based on meeting the same unlocking conditions. The different instances may perform substantially the same function but may specify different proposed and counterproposed values ​​for one or more transaction parameters (e.g., amount of digital assets and / or lock time). This is discussed in more detail below with reference to Figures 7 and 8.

[0101] Zeroth transaction Tx 0 The first transaction Tx may also be referred to as a source transaction for the present purposes, in that it acts as the source of the amount of digital assets to be locked in Alice 103a. 1 Source transaction Tx 0 The second transaction Tx may also be referred to as an intermediate transaction or a conditional transaction for the present purposes in that it acts as an intermediary for the conditional transfer of said amount of digital assets from the pis sometimes called a target transaction or payment transaction (hence the subscript "P") because it is the transaction that unlocks one of the conditions and delivers a payment to Bob (or potentially a beneficiary on whose behalf Bob is acting). In some embodiments, the second or target transaction Tx p Two alternative versions of the are possible: p If Bob receives a Tx 1 The other is the transfer of a certain amount from the output of Tx 1 If Bob still hasn't claimed it after the period defined by the time lock on the output of Tx 1 This allows the user to recover a certain amount from the output of the

[0102] As shown in Figure 6, the zeroth or source transaction Tx 0 at least one output 203 specifying an amount of the digital asset 0 (For example, Tx 0 0), which further includes a lock script that locks this output to Alice 103a. 0 This means that the locking script of Alice requires that at least one condition be met: that any transaction input that seeks to unlock the output (and thus redeem said amount of digital assets) must contain Alice’s cryptographic signature (i.e., using Alice’s public key) in the unlocking script. In this sense, Tx 0 The amount defined by the output of is said to be owned by Alice. The output may be called UTXO. 0 For present purposes it is not particularly important to know which output of which previous transaction the input of Tx 0 (as long as it is sufficient to cover the total output(s) of

[0103] In this case, the source transaction Tx 0 The transaction that unlocks the output of is the first, or intermediate, transaction Tx 1 Therefore, Tx 1 A finalized instance of 1 (For example, Tx 1 0) of this input 202 1 Tx 0 The associated output (in the example shown, Tx 0 0) and, in addition, locks that output according to the conditions defined in the lock script, which requires at least Alice's signature. 0 Includes an unlock script configured to unlock the pointed output of Tx 0 The signature required by Alice for the lock script is Tx 1 In some protocols, the Tx that needs to be signed is 1 The part is Tx 1 For example, this may be set by a SIGHASH flag, which is a byte appended to the signature, so that for data, the unlock script<Sig PA> <sighashflag> <pa>Alternatively, the part that needs to be signed can simply be Tx 1 In any case, the part that is signed typically excludes the unlock script itself and is a fixed part of Tx 1 This may exclude some or all of the inputs of Tx 1 This means that the input is malleable.

[0104] First or intermediate transaction Tx 1 has at least one output 203 1 (For example, Tx 1 0; here again, outputs may be referred to as UTXOs). Optionally, in embodiments, intermediate transactions Tx 1 The output of Tx is not unconditionally locked to any one party. 0 Similarly, Tx 1 has at least one output (e.g., Tx 1 The cryptocurrency has an output ("Condition 0") that specifies the amount of digital assets to be transferred forward and further includes a locking script that defines what is required to unlock the output and thus redeem the amount. However, in some embodiments, the locking script allows the output to be unlocked based on any one of a number of different possible conditions, including at least: i) a first condition ("Condition 1") and ii) a second condition ("Condition 2").

[0105] Second target transaction Tx p At least one input 202p (for example, Tx p 0) which is Tx 1 The above output (in the example shown, Tx 1 It also contains a pointer to the Tx 1 based on satisfying one of said one or more conditions defined in the lock script of Tx 1 and an unlock script configured to unlock the output of the target transaction Tx. p In a first version of the target transaction, the unlock script may be configured to satisfy a first condition, condition 1. Alternatively, in a second version of the target transaction, the unlock script may be configured to satisfy a second condition, condition 2.

[0106] Second target transaction Tx p must have at least one output 203p (for example, Tx p 0), which specifies the amount of digital assets to transfer to Bob in the first version, or the amount to transfer to Alice in the second version. Output 203p also includes a lock script that locks it to Bob or Alice, respectively (i.e., it requires a further forward-looking transaction, including Bob's or Alice's signature in the unlock script, respectively, to be used). In this sense, the target transaction Tx p The output of can be said to be owned by either Bob or Alice, depending on whether the first or second version is used. This output is also sometimes called a UTXO.

[0107] In embodiments, the first condition is that the unlock script for any transaction Tx 1 The transaction that is trying to unlock the target transaction Tx p The first version of the TxPackage requires that the unlock script include, in its unlock script, Bob's cryptographic signature and / or a data payload, which may be Bob's data that Bob may provide or need to include. The requirement to include a data payload is 1 The requirement for a signature may be imposed by a hash challenge included in the locking script of the Tx. The challenge includes a hash of the data (rather than the data itself) and a piece of script configured to test (when executed at node 104 together with the unlocking script) whether a hash of the data provided in the corresponding unlocking script equals the hash value provided in the locking script. The requirement for a signature may be imposed, for example, by CheckSig, discussed previously. In some embodiments, the first condition is that Tx p We do not require that the unlock script for Tx contain Alice's signature. p The part is Tx p This may be the setting of the unlock script (e.g., specified by the SIGHASH flag) or it can be fixed. In any case, at least the unlock script is excluded.

[0108] In some embodiments, the second condition, ii) condition 2, is that the unlock script of any transaction Tx 1 The transaction that is trying to unlock the target transaction Tx p (the second version of Tx 1 This can be done, for example, because Bob does not engage in the process at all, or because Bob does not receive any Tx p This may occur due to failure to mine the first version of a block 151 within a period of time specified by a lock time, which may be defined as an absolute point in time or a period of time that has passed, which may be specified and measured in human time (e.g., seconds, minutes, hours, or days) or by the number of blocks that are mined.

[0109] Zeroth (i.e., source) transaction Tx 0 may be generated by Alice, Bob, or a third party. This is typically done when Alice 0 The source transaction Tx requires a signature from the leading party that has acquired a defined amount of input. It may be sent to the network 106 to be mined by Alice, Bob, the leading party, or other third parties. In another alternative, if Bob is the miner 104, then the source transaction Tx 0 does not need to be broadcast to the network 106; instead, Bob can mine it himself.

[0110] The first (i.e. intermediate, conditional) transaction Tx 1 An instance of may be generated by Alice, Bob, or a third party. In embodiments, it may be generated by Alice, since it requires Alice's signature. Alternatively, it may be generated by Bob or a third party as a template and then sent to Alice to be signed, for example through a side channel 301. Alice then sends the signed transaction to the network 106 herself, or to Bob or a third party to be forwarded to the network 106, or simply sends her signature and sends it to Bob or a third party as Tx 1 The signed and finalized instance of Tx can then be sent to the network 106. 1 Any off-chain exchanges prior to sending the finalized instance of Tx1 to the network 106 may also be performed through side channel 301. In another alternative, if Bob is a miner 104Mb, the first transaction Tx1 does not need to be broadcast to the network 106; instead, Bob can mine it himself.

[0111] The second transaction (i.e. the target transaction or payment transaction) Tx p Either version of Tx can be generated by Alice, Bob or a third party. The first version may be generated by Bob since it requires Bob's signature and / or data. Alternatively, it may be generated by Alice or a third party as a template and sent to Bob to be signed and have data added, e.g., sent through side channel 301. In embodiments, Bob creates a second transaction Tx p The miner is paid by Alice for mining 104Mb (containing Alice’s data payload) into block 151. In this case, the second transaction Tx p does not need to be broadcast to the network 106; instead, Bob can mine it himself. However, alternatively, Tx p If Tx is a payment to Bob for some other service, it can either be mined by Bob himself (if Bob is a miner) or it can be broadcast to the network 106 for mining by some other party (whether Bob is a miner or not). In the latter case, Bob can send the signed transaction to the network 106 himself, or send it to Alice or a third party to be forwarded to the network 106, or simply send his signature and data to be sent to Alice or a third party to be signed by Tx p The second version can be packaged in a single file and forwarded to network 106. In embodiments, the second version requires Alice's signature. Thus, it may be generated by Alice, or generated by Bob as a template and sent as a template to Alice to add portions of, e.g., again, sent through side channel 301. Alternatively, it may be generated as a template by a third party and then sent to Alice, where Alice adds her signature and forwarded to Bob or a third party for forwarding to network 106. Again, the second version requires Alice's signature. Thus, it may be packaged in a single file and forwarded to network 106. In embodiments, the second version requires Alice's signature. Thus, it may be packaged in a single file and forwarded to network 106. p Any off-chain exchange prior to sending may be performed through a side channel 301.

[0112] It will be understood that there are a variety of locations where the various elements of a transaction can be generated and compiled, and a variety of ways for the transaction to be sent directly or proxied to its ultimate destination in the P2P network 106. The scope of implementation of the disclosed techniques is not limited in any of these respects.

[0113] It will also be understood that phrases such as "by Alice," "by Bob," and "by a third party" may be used herein as shorthand for "by Alice's 103a's computer equipment 102a," "by Bob's 103b's computer equipment 102b," and "by a third party's computer equipment," respectively. It should also be noted that the equipment of a given party may include one or more user devices used by that party, or server resources, such as cloud resources, used by that party, or a combination of these. This does not necessarily limit actions to being performed at a single user device or a single physical location.

[0114] According to the embodiments disclosed herein, Alice sends a transaction (Tx p ) beforehand. For example, this data can include documents containing text, or still images, or audio or video clips. Negotiating the fee beforehand saves on network congestion. Otherwise, to get the best possible transaction, Alice may offer a small mining fee to submit the first transaction Tx 1 This is because Alice 106 would need to start by publishing an instance of Tx to the public over the network 106 to see if any miners 104M “take the bait” and, if not, increase the fee a bit, try again, etc. (or else Alice might end up offering too high from the start). This could lead to a large number of ineffective transactions being published by Alice 106 on the P2P network. On the other hand, if the transaction parameters (e.g., data, amount, and lock time) are agreed upon in advance with a particular miner, Bob 103b, then the first transaction Tx 1 Only the agreed upon instance of Tx 0 and Tx p too).

[0115] The present disclosure provides a method for generating a set of templates or proposed instances of a first transaction, Tx, using the same transaction protocol recognized by the P2P network 106. 1-template , Tx 1 , Tx 1 ', Tx 1 The present invention provides a method in which this savings on network congestion is achieved by exchanging proposals, counterproposals, etc., over a side channel 301. Because proposals and counterproposals are exchanged over the side channel 301 in the form of actual transactions that include the proposed parameters of the transaction, this allows Alice and Bob to perform the exchange regardless of whether their clients 105a, 105b are of the same type, i.e., without Alice and Bob having to share a common custom messaging protocol for making proposals and counterproposals over the side channel 301. This allows savings on network congestion and avoids potential interoperability problems that might otherwise arise. Alice and Bob may or may not happen to be running the same type of client 105, but in any case they do not have to coordinate or guarantee in advance that they will do so. In embodiments, a first transaction Tx 1 The proposed instance of may be the only message exchanged between Alice and Bob over side channel 301 as part of the negotiation. Alternatively, it is not excluded that there is some non-essential signaling layered on top of this via side channel 301, or that there is some supporting communication, for example via some other standardized mechanism.

[0116] An example of this procedure will now be described in more detail with respect to Figure 5. Some corresponding example transaction formats are shown in Figure 7. This procedure may be implemented through a selection function 403 and presented to Alice and Bob through a user interface 500 of their respective client applications 105.

[0117] In a first step a) of the procedure, Alice enters a first transaction Tx in one or more data entry fields 505 of the client application 105a. 1 1. Enter proposed values ​​for one or more parameters for the first transaction Tx. This would include, at a minimum, the amount of digital assets that Alice initially wants to offer to Bob to mine into block 151 in order to record the data item (data payload) in the blockchain 150. Optionally, Alice may also enter other parameters for the first transaction Tx, such as the lock time. 1 The user may also enter one or more other values ​​for one or more other parameters proposed for inclusion in the Tx. The term "lock time" may have a specific definition in some example transaction protocols or scripting languages, but nevertheless, as referred to herein, the term lock time may more generally refer to the time period during which the Tx 1 Note that the locking script may refer to any parameter for specifying a period of time that must elapse before a particular condition of the unlocking script is unlocked. It may be measured in human time (such as seconds, minutes, hours, and / or days), or in some other condition, such as the number of transactions or blocks that are mined after a certain defined point in time (e.g., following the point at which the finalized instance of Tx1 is mined in block 151). Even more generally, one or more other, alternative, or additional parameters may be imposed by the locking script as criteria for a given unlocking condition. The scripting language may allow almost limitless possibilities for user-defined criteria to be specified as part of the unlocking condition. The condition may be parameterized by one or more parameters, and the value of any one or more such parameters may form part of the proposal to Bob.

[0118] Alice also enters an indication of the data item she wishes to record in one of the data entry fields 505, for example by selecting a file such as a text file, a word processing document file, a database file, a spreadsheet file, an audio file or a video file. Additionally, Alice also enters an indication of the user she wishes to make a suggestion to, in this case Bob, in one of the data entry fields 105. For example, this could include Bob's address within the transaction protocol being used, or Bob's username which Alice's client 105a translates into an address. More generally, Bob's indication may include any means for uniquely identifying Bob or for contacting Bob through the side channel 301. The side channel 301 may already be established at this point, or this may be a means for establishing the channel 301.

[0119] Alice's client 105a automatically synthesizes the information provided by Alice into a template transaction, which is then used to create a first instance of the first transaction, Tx 1-template An example is shown in Figure 7.

[0120] After entering the data, Alice activates the "Propose Transaction" option 501 in the UI 500 of her client 105a. In response, the client 105a creates a template transaction Tx 1-template to Bob's client 105b over side channel 301 (also referred to herein as the "negotiation channel"). In embodiments, client 105a, in response to Alice activating the "Propose Transaction" option 501, transmits a template transaction Tx 1-template and then sends it to Bob. Alternatively, client 105a could formulate it in anticipation of Alice activating "Propose Transaction" option 501 after she enters the proposed parameter values, or even formulate it piece-by-piece along with Alice as she enters each parameter.

[0121] As shown in FIG. 7, in this step a), a template transaction Tx formulated by Alice’s client 105a is 1-template may not contain any inputs. However, it does produce an output 203 containing the proposed parameters. 1-template This output 203 1-template contains a locking script that defines an offered amount x and at least one condition for redeeming this amount.

[0122] If Alice provides an input that contains a valid signature from the beginning, then this initial template Tx 1-template is a valid transaction and can be mined. It may be desirable for Alice to not include any input at this stage, since this means that Bob can mine it without any negotiation at all. If she does include an input, Alice can ensure that the transaction is still invalid as a whole, to avoid the effects described above. For example, she could do so by including an input whose value is too small to cover the output (e.g., by including half the output value as a "pay it up front" commitment to pay), but this is simply more complicated than not including an input, and does not necessarily provide any real benefit. Alternatively, if Alice is OK with Bob having the option to mine the initial proposal, she could include the input and just write Tx 1-template can be enabled from the start.

[0123] In some embodiments, Tx 1 The unlock script for each instance of defines two alternative conditions for redeeming the output: i) Bob receives Tx p The first condition requires that the input unlock script contains your signature and data payload (this is Tx p ii) Requires that lock time t has expired and Alice has Tx p The second alternative condition requires that the input unlock script include your signature (this is Tx p As mentioned before, the first condition can be imposed by including a hash challenge containing a hash of the data payload in the lock script. The second condition is that Bob must be able to complete a second transaction Tx by the time the lock time t expires. p This allows Alice to get x back if she does not mine the first version of x during block 151. The lock time t can be one or all parameters of the transaction that are negotiated.

[0124] At this stage, the first transaction template instance Tx 1-template Note that Tx is not a complete transaction because the sum of its outputs specifies a larger amount of digital assets than the sum of its inputs. 0 This is because this instance of the first transaction, Tx 1-template would be considered invalid if broadcast to the network 106 in this form. Nevertheless, the template instance Tx 1-template is sometimes said herein to be formulated in accordance with a transaction protocol applied by node 104 in that, to the extent that it is complete, the complete part complies with the protocol.

[0125] The advantage of Alice's opening move being an invalid template transaction is that, since Alice's transaction is an invalid template at the time it is given to Bob, Bob cannot simply unilaterally accept Alice's opening move without further negotiation (on the other hand, if Alice had sent a complete transaction, Bob could accept it without needing confirmation from Alice). This can be beneficial because it allows Alice and Bob to make trade-offs between multiple parameters in the transaction, and thus Bob can give Alice a favorable counteroffer. For example, if Alice's opening move is "I'm willing to pay 10 BSV if you mine it in 6 days," Bob may not have enough hashpower to confidently say he can meet the 6-day demand and may respond "I'm willing to mine it in 10 days at a heavily discounted price of 3 BSV." Thus, Alice may be inclined to accept Bob's counteroffer because it is favorable for a different reason. That is, upon receiving the counteroffer, Alice can weigh the two parameters, time and price, and conclude that she is willing to wait another 3 days for that price. Having multiple parameters means that Alice and Bob may always prefer a counteroffer that is not the same as their initial preferences.

[0126] However, in alternative embodiments, Alice simply sends her signature and Tx 0 The first instance of the first transaction, Tx 1-template This allows Bob to include the complete input in Tx if Alice's condition is acceptable. 1-template to be propagated through the network 106 and thereby recorded in the blockchain 150, and to transmit his signature and data as Tx p and allowing it to propagate through the network 106 and be recorded in the chain 150, simply accepting it as is.

[0127] In any event, in some embodiments, T x1-template The input of the template transaction Tx 1-template In the body of the Tx, the input may be used as a medium or carrier to transmit the data payload to Bob through a side channel. This technique is based on the principle of malleability. This input is not shown in Figure 7, but will be discussed in more detail later. It is 0 The output of the ssl-ssl-database can be the same input containing Alice's signature, or another input, such as a null or redundant input. However, this feature is not required. Alternatively, the data payload can simply be data that Bob already has on his side, or data that Alice communicates separately via some other mutually recognized medium, such as email, FTP (File Transfer Protocol), MMS (Multimedia Messaging Service), etc.

[0128] The process can then proceed to a second phase b), where Bob chooses whether or not to accept Alice's template, and if not, Alice receives a counterproposal from Bob.

[0129] Alice, Tx 1-template is in fact a valid transaction, Bob can simply write Tx 1-template and Tx p She can do so by sending Tx 1-template is not a complete and valid transaction. If that is the case and / or Bob is unwilling to accept it, then Bob can send another updated instance of the first transaction, Tx 1 , back to Alice over the side channel 301. Bob then converts this to the template Tx 1-template This is based on the following.

[0130] In some embodiments, Bob performs a first transaction Tx 1 Sign an instance of and add your signature to Tx 1 Input 202 a-Bob This can be a "zero value" input (in practice, this is a negligibly small value in practice). Bob's "0 unit" input is required to be included in Alice's input 202 a-Alice (which we will discuss shortly) points to some source UTXO owned by Bob, just as it points to a source UTXO owned by Alice.

[0131] Bob’s intention to add such a zero-valued input is expressed as a negotiation transaction (Tx 1 The paradigm here is to give Bob a template transaction Tx 1-template The implication is that the output of the preferences acts as a customer's offer for Bob's services, and Bob's signing of these preferences can be interpreted as Bob agreeing to provide the service under those conditions. However, it is not mandatory that Bob needs to add such small value inputs. Instead, for example, Bob could create a template transaction (Tx 1-template ) as a message and send it to Alice. Alice can then sign the message and send it to Tx 1 ' (see below), or as another alternative, Bob may simply not be required to sign at all.

[0132] (As shown in Figure 7) Bob actually sends the Tx 1 The optional benefit of including his input in is that Bob’s signature is valid and must be checked by miners. This is, in some sense, a stronger expression of Bob’s agreement with Alice’s preferences. This is a bit like an on-chain contract that is “secured” by the network.

[0133] If Bob wants to accept Alice's offer, he simply sends Tx 1-template By signing Tx 1 The part that Bob signs is shown in black in step b) of Figure 7. If Alice did not include her input originally, Bob would return it to Alice via side channel 301, and Alice would then sign Tx 1 Sign and Tx 1 ', which Alice then publishes to the network 106 (directly or via a third party) or sends back to Bob to be mined or published.

[0134] If Bob wishes to make a counterproposal on its behalf, Bob also modifies at least one of the transaction parameters before signing. This could include, for example, modifying the amount of the specified digital asset x, or modifying the lock time t (effectively the amount of time given to Bob to mine the data during block 151), or both. Either way, Bob will then sign this modified instance of the first transaction, Tx 1 (modified relative to the template) back to Alice through side channel 301. If Bob modifies one or more of the parameters, this acts as a counterproposal to Alice.

[0135] Bob's counteroffer may be rendered to Alice in a notification 506 of Alice's client application 105a. If Alice wishes to accept the counteroffer, then in step c), Alice simply submits her signature and the Tx 0 Input 202 contains a pointer to the output of 1-Alice Tx 1 , resulting in a further updated instance of the first transaction Tx 1 The part that is signed by Alice is shown in black in step c) of FIG. 7. In one embodiment, Alice can then create Tx 1 ' to Bob, who then sends Tx 1 " and Tx p , which are propagated through the network 106 and recorded in the blockchain 150. In an alternative embodiment, Bob p Tx 1 ', and then Alice can send it to Tx 1 " and Tx p to be propagated through the network 106 and recorded in the chain 150. In another alternative, Alice transmits Tx 1 ', and Bob signals acceptance via some other mechanism, and Bob sends Tx p Regardless of which embodiment is used, client 105a may be configured to trigger an associated action in response to Alice activating an “Accept Counterproposal” control 502 in the UI of client 105a.

[0136] Bob Tx 1 Input 202 a-Bob In an embodiment in which Alice does not include her signature in Tx 1 'Enter your payment in 202 1-Alice Can be included in: <Sig(P A ,Tx 1 ')> SIGHASH_ALL <P A > <Sig(P B ,Tx 1-template )> <--This means that Bob is now Tx 1 Instead of Tx 1-template Because I signed OP_DROP <--included in Alice's input script, but prevents it from being validated by the miner

[0137] On the other hand, if Alice does not want to accept Bob's counteroffer but does want to continue the negotiation, she instead activates "Make Further Counteroffers" option 503 in the UI 500 of client application 105a.

[0138] Now, the UI 500 in Alice's client 105a prompts Alice with an opportunity to enter further modified values ​​of at least one of said one or more transaction parameters through data entry fields 507 rendered through the UI 500 in client 105a. This may again include, for example, modified values ​​of the amount x and / or the lock time t. Once this is done, Alice actuates another instance of the "Propose Transaction" control 504. In response, Alice's client 105a updates said modified parameter value(s) according to what Alice entered in data entry fields 507, includes Alice's signature, and submits a source transaction Tx 0 Input 202 points to the output of 1-Alice Create a further modified instance of the first transaction by adding 1 and Tx 1 ' are both signed by Bob, so Alice's act of making a counteroffer is, in effect, the act of 1-template Note that this is the same as proposing a new instance of Tx 1-template The client then transmits this further modified instance Tx ' over the side channel 301. 1-template ' to Bob. Alternatively, client 105a may have already sent Tx 1 ', which is then triggered by actuation of this control 507 and sent to Bob. The process then repeats from step a). The process may be repeated one or more times, each time starting at step a) with the most recently proposed instance of the template transaction.

[0139] Once a complete, valid and acceptable instance of the first transaction Tx1′ has been agreed upon, Bob or Alice submits it to be propagated and recorded in the blockchain 150. Alternatively, Bob can submit Tx1′ himself. 1 ' during block 151. In any case, Bob also mines a second transaction, Tx p The first version of the token is mined during block 151, and the resulting data payload is recorded on the blockchain 150.

[0140] Optionally, Bob may signal his acceptance to Alice. For example, this may be done by sending a Tx 1 '. Since this is identical to the version proposed by Alice, Alice's client 105a interprets this as an acceptance and notifies Alice of this through the UI 500 of client 105a. Alternatively, it is not excluded that Bob could send a separate acceptance signal to Alice through the side channel 301, which is not formulated as a transaction. This would break the transaction-specific signaling, but since this signal is not required, this would be considered acceptance. In another variation, Bob could send Tx 1 ' via the side channel back to Alice, who sends it to be propagated through the network 106 and recorded in the blockchain 150.

[0141] If there is no mechanism for Bob to acknowledge receipt, Alice can consider the absence of any further counterproposal from Bob as implicit acceptance, or simply accept the first transaction Tx 1 Transaction Tx that points to the latest instance of p , and can wait to observe her data being included in the blockchain 150. Yet another possibility would be that Alice could query a given miner 104M to see if they have "accepted" the transaction into their local copy of the mempool 154 before it is mined. An API to query miners has not yet been implemented, but it is possible. Thus, it is conceivable that Alice could get confirmation of receipt before seeing it on-chain.

[0142] In some embodiments, Alice executes a) and thus the proposed transaction Tx 1-template In this case, in a preliminary phase A), prior to the first phase a), Bob may be the one to initiate the negotiation by sending the advertisement transaction to Alice via a side channel 301 or make the advertisement transaction available in a public service registry where Alice may look up the advertisement transaction.

[0143] An example is shown in Figure 8A. The advertisement transaction includes a proposed script along with some proposed parameters for the first transaction. The proposed script returns a disabled output 203, as specified by the opcode OP_Return in the example shown. 2-unspendable 8B. This acts as an invitation to Alice to either accept the advertised terms or to make a proposal to Bob. If Alice wishes, she can simply accept the advertised terms by formulating a first transaction instance with the proposed script and parameter values. An example of this is shown in FIG. 8B. However, if Alice does not accept and wishes to enter into negotiations with Bob, she continues the process from the first step a), as discussed in relation to FIGS. 5 and 7. One or more of the parameters entered by Alice in step a) may be different from those originally proposed by Bob in the advertisement transaction in preliminary step A).

[0144] Thus, a mechanism is disclosed that uses template transactions to allow Alice (a user) and Bob (a miner and service provider) to negotiate the terms of a paid upload operation using the mining service offered by Bob.

[0145] Bob, Tx 1-template Sign and Tx 1 Alice then accepts Alice's offer by forming Tx 1 Sign and Tx 1 ' to finalize the transaction (and negotiations).

[0146] If initiated by Alice, the transaction can be considered to represent: a)Tx 1-template = Alice puts her offer on the table, b) Tx 1 = Bob signs and agrees to the offer, c) Tx 1 '=Alice signs, completing the (two-way) agreement. When initiated by Alice, the transaction essentially represents the following: a)Tx 1-template = Alice puts her offer on the table, b) Tx 1 = Bob signs and agrees to the offer, c) Tx 1 '=Alice signs, completing the (two-way) agreement. When Bob initiates, it looks like this: A) Tx 1-ad = Bob advertises his service. At this point he has already signed these terms. Then, B) Tx 1-ad ' = Alice agrees and completes the offer stated and signed by Bob; or Resume at step a) of "Alice starts" and proceed as above a)-c).

[0147] Normally, a payment channel is only used to send complete and valid transactions between parties off-chain. In this case, however, when Alice initiates (case 1), Tx 1-template and Tx 1 is incomplete and invalid, but is still exchanged off-chain. If Bob initiates (case 2), then either only Bob's advertisement is sent off-chain or the situation in case 1 occurs. In the currently disclosed system, Alice and Bob negotiate the state of the incomplete transaction to be signed at the end. In a regular payment channel, the state of the complete transaction is negotiated. In fact, in a negotiation channel, in some scenarios, it may never be necessary for a complete and valid transaction to be sent off-chain (as would be done in a regular payment channel).

[0148] As already mentioned, there are two general cases to consider: Case 1: Alice initiates the negotiation, Case 2: Bob initiates the negotiation (i.e., advertises his services). These examples are reproduced below with reference to Figures 7 and 8.

[0149] Case 1: Alice initiates the negotiation Step 1: Alice creates an incomplete template transaction and sends it to Bob. Figure 7a) shows the template transaction Tx sent by Alice to Bob. 1-template Here is an example:

[0150] Step 2: Bob completes the template, thereby creating a Negotiation transaction by adding inputs and signing it. This is still invalid because output values ​​> input values. Note that Bob may also choose to update Alice's parameters x and t, which are considered part of this negotiation phase. Figure 7b) shows the signed negotiation transaction Tx sent from Bob to Alice. 1 Here is an example of a message signed by Bob's signature. The data that makes up the message signed by Bob's signature is highlighted in black.

[0151] Steps 1 and 2 are repeated as many times as necessary as negotiation rounds: Alice can make as many offers to Bob as she deems necessary.

[0152] Step 3: When Alice receives the counteroffer / accepted offer from Bob, she adds her own input and signs the whole transaction. This is called the offer transaction, Tx 1 A forged version of Tx 1 'Generate Forged Form Tx 1 ' is valid and Bob mines. Bob then issues Tx 1 A subsequent transaction Tx that claims the output of p Upload Alice’s data D by mining Figure 7c) shows the signed forged negotiation transaction Tx sent from Alice to Bob. 1 The data containing the message signed by Alice's signature is highlighted in black.

[0153] Case 2: Bob initiates the negotiation Step 1: Bob publicly advertises his "paid uploads" service. He does this by posting the following invalid transaction somewhere visible: This transaction encodes enough information for customers to interpret and respond to it without contacting Bob directly. This is done by Alice filling in the relevant fields in OP_RETURN. Figure 8A) shows the signed advertisement transaction Tx sent by Bob to Alice. 1-ad Here is an example of a message sent by Bob with his signature, with the data highlighted in black.

[0154] Step 2: Alice can either (I) negotiate a different price and upload time by sending an alternative transaction template to Bob for him to sign, or (II) negotiate a different price and upload time for this transaction Tx 1-ad Alice can then sign and complete the purchase of Bob's upload service. If Alice chooses (I), the process reverts to the negotiation in case 1. Alternatively, if Alice is satisfied with Bob's advertised parameters, she can sign and complete the forged transaction Tx 1-ad '. Note that this transaction forges a transaction using a different SIGHASH flush. The flags Bob selected allow Alice to add both inputs and outputs without invalidating Bob's original signature. Figure 8B) shows an example of a signed, forged negotiation transaction sent by Alice to Bob. The data, including the message signed by Alice's signature, is highlighted in black.

[0155] Using Malleability to Communicate Data Below is a proposed transaction Tx for the template as a vehicle for conveying the data payload to Bob through a side channel 301 within the body of the template transaction. 1-template (or Tx 1 ', etc. Bob (or Alice or a third party) then performs a Tx 1-template (And the data payload is instead used to create a second transaction Tx p included in the input.

[0156] Malleability is an existing concept in cryptography that underpins the security concern that a message can be maliciously modified and still be accepted as authentic. Digital signature schemes are designed to address this concern. However, in the context of blockchain, malleability refers to the ability to modify parts of a transaction without invalidating the entire transaction. Any information in a transaction that is signed by a cryptographic signature (e.g., an ECDSA signature) is not susceptible to forging. Security concerns related to malleability are caused by improper implementations, not the protocol itself. In embodiments, malleability may actually be exploited as a useful feature to facilitate communication of data in the body of a template transaction.

[0157] Consider the scenario already discussed, where Alice is willing to pay a second actor to put a large amount of plain or encrypted data onto the blockchain. However, Alice is concerned that there are no miners willing to accept her transaction at a fair price. To ease her concerns, Alice contacts her miner friend Bob and promises to pay him a mutually agreed upon number of Bitcoins. To ensure that Alice's data is published on the blockchain and that Bob receives payment, embodiments may use the following techniques.

[0158] As mentioned above, Alice creates a transaction Tx that stores some large data item of Alice on the blockchain 150. p 1. Pre-negotiate with Bob the fee for mining x1, x2, x3, x4, x1, x2 ...1, x2, x1, x1, x1, x1, x1, x1, x1, x2, x1, x1, x1, x1, x1, x1, x1, x1, x2, x1, x1, x1, x1, x1, x1, x1, x1, x2, x1, x1, x1, x1

[0159] To facilitate interoperability, the negotiation is carried out through a side channel 301 in a first transaction Tx 1 This is done by replacing the proposed instances of

[0160] To exploit the idea of ​​malleability, the data payload D that Alice wants to upload is Tx 1-template Note that this is not shown in Figure 7. In principle, this can be done by transmitting the first transaction instance (Tx 1-template , Tx 1 ', Tx 1 For simplicity, in the following, we will use the symbol Tx 1 The data payload D is sent to the source transaction Tx 0 , or may be included in another input, such as a null or redundant input. Optionally, this may be included with an associated scripting language opcode that instructs any node 104 that receives this instance of this first transaction to ignore the data D (e.g., by discarding it from its stack). By way of example, in Script, this opcode is the OP_DROP opcode, but it will be appreciated that similar functionality may be achieved in other scripting languages. Tx 1 Delete D before any instance of is published to the network 106 (and instead, delete it once a price has been agreed with Bob and p While the intention is for the OP_DROP opcode to be included in the first transaction, the OP_DROP opcode (etc.) means that the presence of a data payload D would not invalidate the first transaction if it were actually published.

[0161] Because the transaction inputs do not need to be signed as part of Alice's or Bob's cryptographic signatures, this means that the data D (and the opcode, if present) can be removed before publishing the first transaction to the network 106 without invalidating the first transaction.

[0162] Alice is Tx 1 Send an instance of to Bob. Tx 1 in the unlock script for that input: <data>Includes OP_DROP. Tx 1 The output of will only specify an amount of digital assets that is slightly larger than the input, say about 500 units. But <data>The combination of these two facts is that Tx 1 This means that it is not worth mining for anyone (yet) (even if Alice's input were included at this stage to make it valid). However, the unlock script in the transaction input is not signed and is therefore malleable. This <data>OP_DROP is unsigned, meaning the transaction can be deleted without being invalidated. This provides a convenient way to package up data and send it to Bob.

[0163] Tx 1 The output of contains a lock script that allows the output to be used in either of the following cases: p The unlock script is tested by Bob's signature and data (hash challenge -- Tx 1 The lock script contains the data and a hash of the script, which is stored in the Tx p hashing the raw version of Tx provided in the unlock script to check if the values ​​match; or p The unlock script at input contains Alice's signature, and the timeout limit has expired.

[0164] Tx p For this to be valid, Tx 1 (or Tx 1 (subsequent instances of Tx 1 If sent at <data>Remove the OP_DROP. Bob then executes Tx 1 or Tx 1 to the network 106 to be mined. The smaller size of this transaction means that it is now worth mining for other miners. Alternatively, Bob can mine it himself.

[0165] As an example implementation, Tx 1 The script included in the input can be: [Table 3]

[0166] A few comments about this transaction: First, scriptSig - this is the unlock script for Alice's unspent outputs. Three additional script elements have been added: OP_PUSHDATA, DATA, and OP_DROP. Note that Alice's signature is signed over the entire transaction except for the scriptSig. Therefore, adding the extra elements in scriptSig does not invalidate Alice's digital signature. In this case, it does not invalidate the transaction because OP_DROP resets the stack to its original state. Including the data in this section allows Bob to receive it and prune it before publishing the transaction. Bob will instead publish the data in his unlock script.

[0167] Second, scriptPubKey - this is the lock script that locks Bob's payment. Translated in plain language, Bob needs to provide the data and his digital signature to claim the payment. Otherwise, after 1000 blocks, Alice can get the payment back with her signature. So, to get the payment, Bob is forced to include Alice's data in the unlock script, thus putting the data on the blockchain 150. Instead of broadcasting the transaction to the network 106, Alice sends the transaction to Bob through a side channel 301. Upon receiving the transaction, Bob parses the transaction to get the data and verifies its hash value. If the hash value is equal to the hash value given in the scriptPubKey, Bob is sure that he can claim the payment. So, Bob can get the " from the scriptSig in Alice's transaction. <data>OP_DROP" and then broadcasts the modified transaction to the network (or sends it back to Alice over a side channel 301 to continue the negotiation). Bob constructs another transaction, shown below, to claim the payment and includes it in the next block 151 that he mines.

[0168] For example, Tx p The unlock script could look like this: [Table 4]

[0169] Once Alice sees Bob's transaction confirmed on the blockchain 150, she can check that her data was indeed included in the transaction and therefore in the blockchain 150.

[0170] The instance of the first transaction Tx1 shown in FIG. 9 can represent any instance of the first transaction sent from Alice to Bob through the side channel. 1-mal can represent a forged version of any of the first transaction instances. Pre-negotiation can occur before, after, and / or including the first transaction instance including data D being sent from Alice to Bob in FIG.

[0171] Optionally, we can use a simple transaction fee constraint to calculate the <data>It is possible to force the pruning of F. This means that if Bob does not delete the data before sending it to the network, Alice has minimal risk of data being accidentally uploaded in her transaction. The minimum fee in units of digital assets per byte for relaying a transaction on the network is F. min The byte size of Alice’s transaction is S Tx =S data +S other And S data The data packet <data>The size in bytes.

[0172] The total fee for Alice’s transaction is the difference between the input and output values ​​of Alice’s transaction, V in -V out The total size is S Tx Then, for Alice's transaction to be successfully broadcast and validated, we have:

number

[0173] Therefore, Alice knows that the difference between her input and output values ​​is:

number

[0174] conclusion It will be understood that the above-described embodiments have been described by way of example only. For example, the scope of the disclosed scheme is not limited to the scenario described in the detailed description in which Bob is a miner and Alice is negotiating to have Bob upload a large data item, such as a document or movie clip, onto the chain. More generally, the disclosed mechanism for exchanging templates or proposed transactions through side channel 301 can be used to provide an interoperable mechanism for Alice to negotiate any service from Bob, e.g., IT support, the provision of information services, or the provision of physical goods.

[0175] According to an aspect disclosed herein, a computer-implemented method is provided for recording in a blockchain at least a first transaction transferring an amount of a digital asset from a first party to a second party. A copy of the blockchain is maintained among at least a portion of a network of nodes. The method includes, at a first party's computer equipment: establishing a side channel separate from the network, the side channel being established between a first application on the first party's computer equipment and a second application on the second party's computer equipment; and performing a negotiation procedure over the side channel. The procedure includes: a) formulating a proposed instance of a first transaction and sending the proposed instance over the side channel to a second party, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network to validate transactions and specifying a set of one or more values ​​for one or more parameters of the transaction including at least the amount of the digital asset; b) when the proposed instance of the first transaction is not accepted by the second party, receiving a counter-proposed instance of the first transaction over the side channel, the counter-proposed instance also formulated according to the transaction protocol but specifying a modified set of one or more values ​​for the one or more transaction parameters; and c) the first party choosing whether to accept the counter-proposed instance received in b).

[0176] The modified set of values ​​may have one, some or all of the values ​​modified compared to the initial set. The parameters whose values ​​are modified may include the quantity of the digital asset and / or one or more other parameters, such as a lock time.

[0177] In embodiments, c) may include: reading a modified set of one or more values ​​from the counterproposed instance of the first transaction received in b), and making the selection as to whether to accept the counterproposed instance based on the modified set of values ​​read therefrom.

[0178] In embodiments, c) may include: upon choosing not to accept the counterproposed instance received in b): formulating a further counterproposed instance of the first transaction and sending the further counterproposed instance to the second party via the side channel for acceptance by the second party, the further counterproposed instance also formulated in accordance with the transaction protocol but specifying a further set of one or more values ​​for the one or more transaction parameters.

[0179] In embodiments, c) may include: determining the further set of one or more values ​​in dependence on the revised set of values ​​read from the counter-proposed instance of the first transaction received in b).

[0180] In embodiments, at least on the first occurrence of b), the second party may not accept the further counterproposed transaction; instead, following c), the procedure returns to b) and continues from b) until one of the parties accepts either the counterproposed transaction or a further counterproposed transaction.

[0181] In embodiments, continuation of the procedure may include at least one repeated occurrence of both b) and c).

[0182] The further modified set of values ​​may modify one, some or all of the values ​​compared to the previously modified set. Again, the parameters whose values ​​are modified may include the amount of the digital asset and / or one or more other parameters, such as a lock time.

[0183] In embodiments, the accepting includes: an accepted instance of the first transaction being transmitted to be propagated on the network and thereby recorded on the blockchain.

[0184] In embodiments, a first party accepts one of the counterproposals from a second party by the first party sending an accepted instance of the first transaction to be propagated through the network.

[0185] Alternatively, one of the further counter-proposed instances from the first party is accepted by the second party, and the accepted instance is transmitted by the second party for propagation through the network.

[0186] Note: Acceptance and transmission may include the initiating party sending an accepted instance of the first transaction back to the other party for the other party to forward to the network, or sending the accepted instance to a third party for the third party to forward to the network, or even sending the first transaction back to the other party for the other party to forward to the third party for further forwarding to the network. Similarly, acceptance and transmission by the other party may include the other party sending an accepted instance of the first transaction back to the initiating party for the other party to forward to the network, or sending the accepted instance to a third party for the third party to forward to the network, or even sending the first transaction back to the initiating party for the third party to forward to the third party for further forwarding to the network. Here, "sending to be propagated" does not necessarily require the party performing this step to directly send the transaction to the network itself (although that is certainly an option).

[0187] In embodiments, the proposed instance of the first transaction in a) may take the form of a template transaction having complete and incomplete parts and thus not yet valid according to the node protocol. In this case, the proposed transaction is said to be formulated according to the transaction protocol in that at least said complete parts are formulated according to the transaction protocol. The accepted instance may have incomplete parts that are completed by the first party and / or the second party.

[0188] In embodiments, each instance of a first transaction may include at least a first output specifying the amount and including an unlocking script, the unlocking script specifying at least one condition to be satisfied by an unlocking script in an input of a second transaction to unlock the first output and thereby redeem the amount of the digital asset.

[0189] In embodiments, the complete portion may include a total of zero or more inputs and a total of one or more outputs including at least the first output, and the template transaction may be invalid in that at least the one or more outputs specify a total output value of the digital asset that is greater than a total input value of the zero or more inputs, in which case completing the incomplete portion includes adding at least one input to bring the total input value greater than or equal to the total output value.

[0190] In embodiments, the complete portion may include zero or more inputs and one or more outputs including at least the first output, and the template transaction is invalid in that it lacks at least a cryptographic signature of the first and / or second party, in which case completing the incomplete portion includes adding a signature of the first and / or second party to one or more existing inputs.

[0191] The template transaction may include one or more existing incomplete inputs that are missing a signature of the first and / or second party, or the template transaction may include one or more missing inputs. Adding the signature(s) may include adding at least one new input that includes a signature of the first and / or second party, or adding a signature of the first and / or second party to one or more existing inputs. If signatures of both the first and second parties are required, these may be included in the same input or in different respective first and second inputs.

[0192] In embodiments, the proposed instance of the first transaction in a) may include no input and may include the first output; a counter-proposed instance from the second party, at least in the last occurrence of b), may include a signature of the second party; and an accepted instance may include an input added by the first party that brings the total input value greater than or equal to the total output value and includes the signature of the first party.

[0193] For example, the signature of the second party may be included in an input added by the second party to a counter-proposed instance of the first transaction.

[0194] In embodiments, a first party may initiate the procedure by performing a). Alternatively, in embodiments, the procedure may be initiated by: obtaining, at a first party's computing facility, an advertising transaction from a second party, the advertising transaction including a non-usable output specifying an advertised set of one or more values ​​for the one or more parameters, and the first set of one or more values ​​of the one or more transaction parameters proposed by the first party being modified relative to the advertised set.

[0195] The advertising transactions may be received, for example, via a side channel, retrieved from a public data source by a first party, or received via a third party.

[0196] In embodiments, the advertising transaction further includes an input including the cryptographic signature of the second party, thereby providing the first party with the option to accept the first transaction by adding an input including the signature of the first party in place of an instance of the first transaction.

[0197] In some embodiments, the second party may be a miner, and the amount of the digital asset may provide a payment for the second party to perform a proof-of-work operation to cause a version of a second transaction including a data payload to be included in a block of the blockchain, and the locking script may require at least that an unlocking script in an input of the second transaction include the data payload in order to redeem the payment.

[0198] In embodiments, the requirement to include the data payload may be enforced by a hash challenge included in the locking script, the hash challenge including a hash of the data payload and a hash function to check that the hash of the data payload from the unlocking script matches the hash included in the locking script.

[0199] In embodiments, the data payload may include, for example, a document including text, and / or media content including audio and / or video.

[0200] In embodiments, the data payload is communicated from the first party in a portion of one of the instances of the first transaction that is not required to be signed, thereby allowing the data payload to be removed from the first transaction before being sent for propagation on the network.

[0201] For example, the data payload may be conveyed at the input of one of the instances of the first transaction sent from the first party to the second party, and may be included in a script with an opcode, e.g., OP_DROP, that causes any node 104 executing the script to ignore the data.

[0202] In other embodiments, the second party need not be a minor, and the amount of the digital assets may be used to provide payment for the second party to perform some other service, such as the provision of goods, home improvement work, consultancy services, etc., for the first party.

[0203] In embodiments, the set of transaction parameters in each instance of the first transaction may further include a lock time, after which the first party may recover the amount of digital assets if not already redeemed by the second party.

[0204] The lock time may be specified, for example, in units of time (human time, e.g., ms, seconds, minutes, hours, weeks, months, or years, etc.) or in terms of the number of mined transactions or blocks. The lock time may be specified as an absolute point in time, or as a relative lock time, i.e., the amount of time that has elapsed since a defined point in time, e.g., since the first transaction was mined.

[0205] In embodiments, the value of the lock time may be modified between two or more of the proposed instance, the counterproposed instance, and the further counterproposed instance of the first transaction.

[0206] In various embodiments, the locking script in each instance of the first transaction may specify multiple alternative conditions for redeeming the payment, including at least: i) a first condition requiring that an unlocking script of a first version of the second transaction include the data payload, and ii) a second condition requiring that the lock time expires and that an unlocking script of a second version of the second transaction include a cryptographic signature of the first party.

[0207] In embodiments, the first condition may further require that a cryptographic signature of the second party be included in the unlock script.

[0208] In various embodiments, the first and second applications may not share a common negotiation protocol for negotiating a transaction through a side channel other than the procedure for using the transaction protocol.

[0209] In various embodiments, the first and second client applications of an initiating party may be produced by different developers or may be different releases by the same developer.

[0210] In various embodiments, no negotiation messages other than a transaction formulated in accordance with the transaction protocol need to be exchanged between the first and second parties to negotiate an acceptable instance of the first transaction.

[0211] According to another aspect of the present disclosure, there is provided a computer program embodied on a computer readable storage device configured to perform the first party method according to any embodiment disclosed herein when executed on the first party's computing equipment.

[0212] According to another aspect of the present disclosure, there is provided a first party computer equipment comprising a memory comprising one or more memory units and a processing device comprising one or more processing units, the memory storing code configured to run on the processing device, the code being configured, when executed on the processing device, to perform the first party method according to any of the embodiments disclosed herein.

[0213] According to another aspect of the present disclosure, there is provided a computer-implemented method for recording at least a first transaction transferring an amount of a digital asset from a first party to a second party in a blockchain, where a copy of the blockchain is maintained across at least a portion of a network of nodes, the method including performing, at a computer facility of the second party: establishing a side channel separate from the network, the side channel being established between a first application on the computer facility of the first party and a second application on the computer facility of the second party; and performing a negotiation procedure over the side channel. The procedure includes: a) receiving a proposed instance of the first transaction from the first party over a side channel, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network for validating transactions and specifying a set of one or more values ​​for one or more parameters of the transaction including at least the amount of the digital asset; and b) the second party choosing not to accept the proposed instance of the first transaction and instead sending back, over the side channel, a counter-proposed instance of the first transaction, also formulated according to the transaction protocol but specifying a modified set of one or more values ​​for the one or more transaction parameters.

[0214] In embodiments, the method may further include the step of said second party according to any embodiment disclosed herein.

[0215] According to another aspect of the present disclosure, there is provided a computer program embodied on a computer readable storage configured to perform the second party method according to any embodiment disclosed herein when executed on a computing device of the second party.

[0216] According to another aspect of the present disclosure, there is provided a second party computer equipment comprising a memory comprising one or more memory units and a processing device comprising one or more processing units, the memory storing code configured to run on the processing device, the code being configured, when executed on the processing device, to perform the second party method according to any of the embodiments disclosed herein.

[0217] Other variations or uses of the disclosed techniques may be apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the claims that follow.< / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / pa> < / sighashflag>

Claims

1. 1. A computer-implemented method for recording in a blockchain at least a first transaction transferring an amount of a digital asset from a first party to a second party, wherein a copy of the blockchain is maintained among at least a portion of a network of nodes, the method comprising, in a computer facility of the first party: a) formulating a proposed instance of the first transaction and transmitting the proposed instance off-chain to a computing facility of the second party, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network for validating transactions and specifying a set of one or more values ​​for one or more parameters of each of the transactions including at least the amount of the digital asset; b) receiving off-chain a counterproposed instance of the first transaction, the counterproposed instance also formulated according to the transaction protocol, but specifying a modified set of one or more values ​​for the one or more transaction parameters; and c) selecting, by the first party's computer equipment based on input from the first party, whether to accept the counter-proposed instance received in b). method.

2. c) includes: reading the modified set of one or more values ​​from the counterproposed instance of the first transaction received in b) and making the selection as to whether to accept the counterproposed instance based on the modified set of values ​​read therefrom. The method of claim 1.

3. 3. The method of claim 1 or 2, further comprising: c) comprising: upon choosing not to accept the counterproposed instance received in b); formulating a further counterproposed instance of the first transaction and sending the further counterproposed instance off-chain to a computing equipment of the second party for acceptance by the computing equipment of the second party based on input from the second party, the further counterproposed instance also being formulated according to the transaction protocol but specifying a further set of one or more values ​​for the one or more transaction parameters.

4. 4. The method of claim 3 when relying on claim 2, wherein the further set of one or more values ​​is determined in dependence on the revised set of values ​​read from the counter-proposed instance of the first transaction received in b).

5. 5. A method according to claim 3 or 4, wherein at least on the first occurrence of b), based on input from the second party, the computer equipment of the second party does not accept the further counterproposed transaction, and instead, following c), the procedure returns to b) and continues from b) until a computer equipment of one of the parties accepts either the counterproposed transaction or a further counterproposed transaction.

6. 6. The method of claim 5, wherein the continuation of the procedure includes at least one repeated occurrence of both b) and c).

7. 7. The method of claim 1, wherein the accepting comprises: transmitting the accepted instance of the first transaction to be propagated through the network and thereby recorded on the blockchain.

8. 8. The method of claim 7, further comprising the first party's computer equipment accepting one of the counterproposals from the second party's computer equipment by the first party's computer equipment transmitting an accepted instance of the first transaction for propagation through the network.

9. The method of claim 7 when referring to any one of claims 3 to 6, wherein one of the further counter-proposed instances from the computer equipment of the first party is accepted by the computer equipment of the second party based on input from the second party, and the accepted instance is transmitted by the computer equipment of the second party for propagation through the network.

10. the proposed instance of the first transaction in a) is in the form of a template transaction having complete and incomplete portions and thus is not yet valid according to the node protocol, and the proposed transaction is formulated in accordance with the transaction protocol in that at least the complete portion is formulated in accordance with the transaction protocol; the accepted instance having the incomplete portion completed by a computer facility of the first party and / or the second party; 10. The method according to any one of claims 7 to 9.

11. 11. The method of claim 1, wherein each instance of the first transaction includes at least a first output specifying the amount and including an unlocking script, the unlocking script specifying at least one condition to be satisfied by an unlocking script in an input of a second transaction to unlock the first output and thereby redeem the amount of the digital asset.

12. The method of claim 11 when citing claim 10, wherein the complete portion includes a total of zero or more inputs and a total of one or more outputs including at least the first output, the template transaction is invalid at least in that the one or more outputs specify a total output value of the digital asset that is greater than a total input value of the zero or more inputs, and completion of the incomplete portion includes adding at least one input to make the total input value greater than or equal to the total output value.

13. 13. The method of claim 11 or 12 when relying on claim 10, wherein the complete portion includes zero or more inputs and one or more outputs including at least the first output, the template transaction is invalid in that it lacks at least a cryptographic signature of the first and / or second party, and completing the incomplete portion includes appending a signature of the first and / or second party to one or more existing inputs.

14. the proposed instance of the first transaction in a) does not include an input and includes the first output; said counter-proposed instance from said second party's computer facility at least in the latest occurrence of b) includes a signature of said second party; The accepted instance may include an input added by the first party, the input bringing the total input value to greater than or equal to the total output value, and including a signature of the first party.

14. The method according to any one of claims 11 to 13 when relying on at least claims 3 and 7.

15. The method of claim 1 , wherein the first party initiates the procedure by performing a).

16. 15. A method according to any one of claims 1 to 14, wherein the procedure is initiated at the first party's computer equipment by obtaining an advertising transaction from the second party's computer equipment, the advertising transaction including a non-usable output specifying an advertised set of one or more values ​​for the one or more parameters, and the first set of one or more values ​​of the one or more transaction parameters proposed by the first party is modified relative to the advertised set.

17. 17. The method of claim 16, wherein the advertising transaction further includes an input including the cryptographic signature of the second party, thereby providing the first party with the option to accept the advertising transaction on behalf of the first transaction instance by adding an input including the signature of the first party.

18. the second party is a miner, and the amount of the digital asset provides payment for the second party to perform a proof-of-work operation to cause a version of a second transaction that includes a data payload to be included in a block of the blockchain; the locking script at least requires that an unlocking script in the input of the second transaction include the data payload in order to redeem the payment; A method according to claim 10 or any one of claims 11 to 17 when claim 10 is recited.

19. 20. The method of claim 18, wherein the requirement to include a data payload is enforced by a hash challenge included in the lock script, the hash challenge including a hash of the data payload and a hash function to check that a hash of the data payload from the unlock script matches the hash included in the lock script.

20. 20. The method of claim 18 or 19, wherein the data payload comprises a document, including text, and / or media content, including audio and / or video.

21. 21. The method of claim 18, 19 or 20, wherein the data payload is communicated from the first party in a part of one of the instances of the first transaction that is not required to be signed, thereby enabling the data payload to be removed from the first transaction before being sent for propagation on the network.

22. 22. The method of any one of claims 1 to 21, wherein the set of transaction parameters in each instance of the first transaction further includes a lock time, after which the first party's computer equipment can recover the amount of digital assets if not already redeemed by the second party.

23. 23. The method of claim 22, wherein the lock time value may be modified between two or more of the proposed instance, the counterproposed instance, and the further counterproposed instance of the first transaction.

24. The locking script in each instance of the first transaction specifies a number of alternative conditions for redeeming the payment, the conditions including at least: i) a first condition requiring that an unlock script of a first version of the second transaction includes the data payload; and ii) a second condition requiring that the lock time has expired and that an unlock script for a second version of the second transaction includes a cryptographic signature of the first party; 24. The method according to claim 22 or 23 when relying on any one of claims 18 to 21.

25. 25. The method of claim 24, wherein the first condition further requires that a cryptographic signature of the second party be included in the unlock script.

26. 26. The method of claim 1, wherein the first and second applications do not share a common negotiation protocol for blockchain transaction negotiation other than the procedure for using the transaction protocol.

27. 27. The method of claim 1, wherein the first and second client applications of the initiating party are produced by different developers or are different releases by the same developer.

28. 28. The method of claim 1, wherein no negotiation messages other than a transaction formulated in accordance with the transaction protocol are exchanged between the computing equipment of the first and second parties to negotiate an acceptable instance of the first transaction.

29. A computer program embodied on a computer readable storage configured to perform the method of any one of claims 1 to 28 when executed on a computer facility of the first party.

30. a memory comprising one or more memory units; a processing device comprising one or more processing units; a computer facility of the first party, The memory stores code configured to run on the processing device, the code being configured, when executed on the processing device, to perform a method according to any one of claims 1 to 28. Computer facilities.

31. 1. A computer-implemented method for recording at least a first transaction transferring an amount of a digital asset from a first party to a second party in a blockchain, where a copy of the blockchain is maintained among at least a portion of a network of nodes, the method comprising, in a computer facility of the second party: a) receiving a proposed instance of the first transaction off-chain from a computing facility of the first party, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network for validating transactions and specifying a set of one or more values ​​for one or more parameters of each of the transactions including at least the amount of the digital asset; b) the second party's computer, based on input from the second party, choosing to reject the proposed instance of the first transaction and instead sending back, off-chain, a counter-proposed instance of the first transaction, the counter-proposed instance also formulated according to the transaction protocol, but specifying a modified set of one or more values ​​for the one or more transaction parameters. method.

32. 32. A computer program embodied on a computer readable storage configured to perform the method of claim 31 when executed on a computer facility of the second party.

33. a memory comprising one or more memory units; a processing device comprising one or more processing units; a computer facility of the second party, The memory stores code configured to run on the processing unit, the code being configured, when executed on the processing unit, to perform the method of claim 31. Computer facilities.

34. 1. A system for recording in a blockchain at least a first transaction transferring an amount of a digital asset from a first party to a second party, wherein a copy of the blockchain is maintained among at least a portion of a network of nodes, the system comprising: a first computer facility that is a computer facility of the first party; a second computer facility that is a computer facility of the second party; the first computer equipment and the second computer equipment are configured to establish a side channel therebetween that is separate from the network, the side channel being established between a first application on the first party's computer equipment and a second application on the second party's computer equipment; the first computer facility is configured to formulate a proposed instance of the first transaction and transmit the proposed instance over the side channel to the second computer facility, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network for validating transactions and specifying a set of one or more values ​​for one or more parameters of each of the transactions including at least the amount of the digital asset; the second computer facility configured to receive the proposed instance of the first transaction from the first computer facility over the side channel; the second computing facility is configured, based on input from the second party, to not accept the proposed instance of the first transaction and instead send back, over the side channel, a counter-proposed instance of the first transaction, the counter-proposed instance also formulated according to the transaction protocol but specifying a modified set of one or more values ​​for the one or more transaction parameters; the first computer facility is configured to receive the counterproposed instance of the first transaction via the side channel and select, based on input from the first party, whether to accept the counterproposed instance received via the side channel. system.

35. 1. A method of recording at least a first transaction in a blockchain that transfers an amount of a digital asset from a first party to a second party, wherein a copy of the blockchain is maintained among at least a portion of a network of nodes, the method comprising: establishing a side channel separate from the network between a first computer equipment and a second computer equipment, the first computer equipment being a first party's computer equipment and the second computer equipment being a second party's computer equipment, the side channel being established between a first application on the first party's computer equipment and a second application on the second party's computer equipment; formulating, by the first computer facility, a proposed instance of the first transaction and transmitting the proposed instance over the side channel to the second computer facility, the proposed instance being formulated according to a transaction protocol recognized by nodes of the network for validating transactions and specifying a set of one or more values ​​for one or more parameters of each of the transactions including at least the amount of the digital asset; receiving, by the second computing facility, the proposed instance of the first transaction from the first computing facility over the side channel; rejecting, by the second computing facility, the proposed instance of the first transaction based on input from the second party and instead transmitting back, via the side channel, a counter-proposed instance of the first transaction, the counter-proposed instance also formulated according to the transaction protocol but specifying a modified set of one or more values ​​for the one or more transaction parameters; receiving, by the first computer facility, the counter-proposed instance of the first transaction over the side channel, and selecting, based on input from the first party, whether to accept the counter-proposed instance received over the side channel. method.

36. 36. Computer software embodied on a computer readable storage configured to perform the method of claim 35 when executed on said first computer facility and said second computer facility.

Images