Multiple Input Transactions

Abstract

To provide a method for allowing a plurality of users to access an item of media content.SOLUTION: A method comprises: developing, by a vendor, an initial template version of a first transaction Tx1 and hosting the same on an accessible server; receiving input for the first transaction from a user over a channel again and adding the input to the first transaction; checking whether the first transaction has enough input to meet a target Tm; and publishing the first transaction and a corresponding second transaction Tx2 to a network and including a secret key Sm in an unlock script of the second transaction.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present disclosure relates to mechanisms for delivering content to users that utilize the concept of input-level adaptability in the context of blockchain-based systems, i.e., the ability to add (or remove) inputs to a transaction without invalidating the transaction. [Background technology]

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

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

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

[0005] Miners who successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "generation transaction," that generates a new amount of digital asset. The transaction may also optionally specify an additional mining fee for successful miners. Proof-of-work encourages miners not to cheat the system by including double-spend transactions in their blocks, because mining a block requires a significant amount of computational resources, and because blocks containing double-spend attempts may not be accepted by other nodes. In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element, sometimes called a UTXO ("unspent transaction output"), that specifies the amount of a digital asset. The output may further include a locking script that specifies the conditions for redeeming the output. Each input includes a pointer to such an output in a preceding transaction and may further include an unlocking script for unlocking the pointed-to output's locking script. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction. The first transaction includes at least one output that specifies the amount of a digital asset 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 for unlocking the output of the first transaction.

[0006] In such a model, when a second transaction is sent to the P2P network to be propagated and recorded on the blockchain, one of the validity criteria applied at each node is that the unlock script meets the requirements defined in the lock script of the first transaction. Another condition for the second transaction to be valid is that the output of the first transaction has not already been redeemed by another valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction or mine it into a block for inclusion on the blockchain. Another condition is typically that the total amount of digital assets specified by the outputs does not exceed the total amount indicated by the transaction's inputs. If this is not the case, most protocols automatically reserve any positive difference between the total output amount and the total input amount as an additional mining fee on top of the amount provided in the generating transaction. Today, in practice, the total input amount must exceed the total output amount by enough mining fees to get miners to accept the transaction, even if it is valid (protocols typically do not force miners to accept valid transactions into their pools, but must incentivize them to do so).

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

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

[0009] Recently, a proposal has been made to judiciously exploit this adaptability to use transactions as carriers of media data: data content can be included in the unlock script of a transaction, which is then sent between parties via a side channel. One of the parties then malleates the transaction to remove the data and submits the modified version to the P2P network to be mined (whereas if the data had not been removed, the transaction would bloat the blockchain and typically also require higher mining fees, since the reward required by miners to accept the transaction typically scales with the data size of the transaction).

[0010] Side channels, like payment channels, allow transactions or data related to transactions to be exchanged "off-chain" between parties before the transaction is broadcast to the P2P network to be recorded on the blockchain. Side channels are separate from the P2P overlay network, so any transaction sent through a side channel is not (yet) propagated through the network for recording on the blockchain until one of the parties chooses to publish it to the network. Standard payment channels require a "funding transaction," whereby both parties effectively escrow their funds together. The funding transaction is broadcast to set up the channel, and then, once the targeted service has been provided, a settlement transaction is broadcast to close the channel, consuming the funding transaction.

[0011] There are also several existing proposals for a "micropayment channel," i.e., sending a sequence of transactions from one party ("Alice") to another ("Bob") for the purpose of paying Bob in small installments. This does not require funding transactions. At least one existing protocol uses a side channel to stream movie data in packets: Bob sends Alice a sequence of data packets, and in response to each packet, Alice returns a respective transaction, which Bob then broadcasts to the network to obtain payment for each packet of the movie.

[0012] Another separate known use of side channels is to enable crowdfunding of transactions. A fundraising party, say Bob, generates a template transaction with at least one output that specifies a desired amount to be transferred to himself or a third party acting on his behalf. However, this transaction does not yet include enough inputs to reach the target amount. Thus, the template transaction is initially invalid because the total value of the digital assets pointed to by its inputs is less than the total payment specified in its outputs. Bob makes the template transaction available to the public by publishing it off-chain on a server. Members of the public can then malleate the template transaction on the server by adding inputs, which gradually add up to the target amount until the transaction is valid. Once the target is reached, Bob publishes it to the P2P network to be mined and made into a block. In practice, the target needs to be slightly more than the specified payment to Bob to cover mining fees. Summary of the Invention

[0013] The problem with existing methods of delivering content to users via fine-grained payment channels is that they only allow for a one-to-one relationship between the streamer and an individual streamee. A single user must pay for each data packet to be streamed, which is then returned to the specific individual user via a side channel. If another user wants to stream the same content, they must replicate this process with the streamer, sending their own stream of transactions that each pay the streamer again for each packet. Over many users, this increases network congestion on P2P networks due to the huge number of transactions that need to be published to the network and recorded on the blockchain, and has the effect of making the blockchain bloated (one transaction per user per packet).

[0014] Alternatively, in principle, crowdfunding technology could be used to allow multiple parties to collectively fund a piece of content by each adding input to a common transaction. This means that the number of transactions that need to be issued to the P2P network scales only per packet or chunk of content, rather than per user, thus mitigating problems of network congestion and blockchain bloat. However, a problem with existing crowdfunding concepts is that they do not provide a unified mechanism for releasing content to users once the crowdfunding target has been reached.

[0015] The present disclosure provides an on-chain, integrated mechanism for releasing crowdfunded content to users.

[0016] According to one aspect disclosed herein, there is provided a computer-implemented method for enabling multiple users to access an item of media content, the method comprising: The method includes providing a first transaction, the first transaction including (i) one or more outputs, including at least a first output, specifying an amount of digital assets to be transferred to the vendor, and (ii) initially a total of zero or more inputs, wherein the total input amount of digital assets specified in any output of any source transaction specified by the zero or more inputs is less than the total output amount of digital assets specified by the one or more outputs. The first output of the first transaction includes a lock script specifying a condition to be satisfied by an unlock script to unlock the first output. The method includes receiving inputs from each of the plurality of users via a side channel, and adding each received input to the first transaction, each received input pointing to an output of a respective source transaction specifying the amount of the digital assets. When a target is reached, such that the total input amount pointed to by the inputs of the first transaction equals or exceeds the output amount, the method includes publishing the first transaction and a second transaction to a blockchain network to be recorded on the blockchain, the second transaction including an input that points to the first output of the first transaction and including an unlock script that satisfies the condition, the condition specified by the lock script requiring that the unlock script include a media key that enables the user to access an item of media content.

[0017] The first transaction is hosted on a server, at least until it reaches the target, and input received from the user is received by the server and added to the first transaction stored on the server (wherein a server may represent any serving computing equipment implemented in one or more physical units at one or more geographic sites).

[0018] For each of a plurality of transactions, including the target transaction, at least some nodes of the network are configured to propagate each transaction, provided that the transaction is valid, and at least some nodes are configured to record each transaction in their copy of the blockchain, provided that the transaction is valid. The validity of the first transaction is conditioned on the total input amount being at least equal to the total output amount. This means that a transaction cannot become valid until enough inputs are collected from users (e.g., Alice, Adam, Agnes, etc.) to meet the target. Furthermore, the validity of the second transaction is conditioned on an unlock script unlocking the output of the first transaction. This means that when a party executing the method (e.g., Bob) wants to claim the output amount, he must publish an unlock key to the blockchain. Once the key is immutably published to a public, inspectable blockchain, this allows a user to retrieve the unlock key and use it to consume a targeted data item from an off-chain data source. Optionally, Bob may also send the unlock key directly via a side channel to one, some, or all of his users instead of requiring them to retrieve it from the blockchain. However, the fact that it must be published on the blockchain ensures that users can retrieve the unlock key from the blockchain themselves if Bob does not send it to them separately. Thus, Bob cannot trick the system.

[0019] In embodiments, the method may include repeating the method for each of a plurality of data items, each item of content forming a different respective one of a sequence of portions of media content. For example, a piece of media content may include text, audio, and / or video content. It may include, for example, a TV or spoken word program episode, a movie, a series of program episodes. In embodiments, a portion may be a given episode streamed in real time to a user, or an independent program or movie, e.g., a packet of a TV program or spoken word program. Alternatively, the portions may be, for example, different episodes of a series.

[0020] According to another aspect of the present disclosure, a corresponding method is provided that is performed by one of the users.

[0021] According to further aspects disclosed herein, there is provided a program for performing the method and / or a computing device programmed to perform the vendor's or user's method. [Brief explanation of the drawings]

[0022] To facilitate an understanding of embodiments of the present disclosure, and to show how such embodiments may be put 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 for implementing a blockchain. [Figure 2] 1 shows a schematic diagram of some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] FIG. 1 is a schematic block diagram of a system for releasing crowdfunding content to multiple users via a blockchain. [Figure 5] FIG. 1 is a schematic diagram of a set of transactions. [Figure 6]1 is a flowchart illustrating a method for crowdfunding and releasing an item of media content to multiple users. DETAILED DESCRIPTION OF THE INVENTION

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

[0024] A blockchain 150 refers to a chain of blocks of data 151, each copy of which is maintained at each of multiple nodes in a peer-to-peer (P2P) network 160. Each block 151 in the chain contains one or more transactions 152, where 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 for each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the quantity of a digital asset belonging to the user for which that output is cryptographically locked (requiring that user's 103 signature to be unlocked and thereby redeemed or spent). Each input points back to the output of the preceding transaction 152, thereby linking the transactions.

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

[0026] For a given current transaction 152j, the input (or each of them) contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist when the current transaction 152j was created or sent to the network 106, but the previous transaction 152i must exist and be verified in order for the current transaction to be concluded. Thus, "preceding" herein refers to something that precedes in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in the chronological order. Thus, it does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0027] The input of the current transaction 152j also includes the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can also be cryptographically locked to a new user 103b. Thus, the current transaction 152j can transfer an amount defined by the input of the previous transaction 152i to the new user 103b defined by the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs, dividing the input amount among multiple users (one of whom becomes the original user for making the change). In some cases, a transaction may have multiple inputs, combining amounts from multiple outputs of one or more previous transactions and redistributing them into one or more outputs of the current transaction.

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

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

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

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

[0032] In addition to validation, at least some of the nodes 104M compete to be the first to create a block of transactions in a process called mining, which is backed by a "proof of work." Mining nodes 104M add new transactions to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. This typically involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. A property of hash functions is that they have unpredictable outputs with respect to their inputs. This search can therefore only be performed by brute force and therefore consumes a significant amount of processing resources at each node 104M attempting to solve the puzzle.

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

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

[0035] In most blockchains, winning miners 104M are automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of thin air (a regular transaction transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "generation" transaction; it automatically forms part of a new block 151n. This reward incentivizes miners 104M to participate in proof-of-work competitions. Often, regular (non-generation) transactions specify an additional transaction fee in one of their outputs to further reward the winning miner 104M who produced the block 151n containing that transaction.

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

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

[0038] Also connected to the network 101 are computing devices 102 for each of a plurality of parties 103 acting as consumer users. These parties act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computing device 102a, and a second party 103b and its respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice, and the second party 103b will be referred to as Bob; however, this is not intended to be limiting, and it will be understood that references herein to Alice or Bob can be interchanged with "first party" and "second party," respectively.

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

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

[0041] 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 among the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0042] An instance of a client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. Each node 104 executes software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, forward the transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols 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 a transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 in the network 106 (although many nodes may handle different transaction subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0043] 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 previously described. Each block 151 also includes a block pointer 155 that points back to a previously created block 151 in the chain, defining a sequential order for the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 awaiting inclusion in a new block by the proof-of-work process. Each transaction 152 includes a pointer to a previous transaction to define an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 stretches back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a previous transaction.

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

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

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

[0047] Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations.

[0048] 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 of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO specifies a quantity of a digital asset (a store of value). It includes, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input and output fields 202 and 203. The header 201 may also include the transaction's ID. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the miner 104M.

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

[0050] The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she submits it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 154, in which case it will be included immediately in the new block 151. Alternatively, Tx0 and Tx1 may be generated and submitted to the network 102, or Tx0 may be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions within a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may equally be replaced by “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily refer to the order in which they are created, submitted to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") will not be validated unless the parent transaction is validated. A child that arrives at node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or miner behavior.

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

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

[0053] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A[ChecksigPA] contains the public key PA from Alice's public / private key pair. Input 202 of Tx1 contains a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Input 202 of Tx1 contains an index that identifies UTXO0 within Tx0, in order to distinguish it among any other possible outputs of Tx0. Input 202 of Tx1 also contains an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <sigpa>The data (or "message") that Alice needs to sign to provide a valid signature may be defined by the lock script, by the node protocol, or by a combination of these.

[0054] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <SigP A > <P A > || [Checksig P A ] where '||' denotes concatenation, '<...>' means placing data on a stack, and '[...]' are functions contained in the unlock script (in this example, a stack-based language). Equivalently, the scripts may be executed one by one using a common stack rather than concatenating them. Either way, when executed together, the scripts will use Alice's public key P, contained in the lock script in the output of Tx0. A is used to authenticate that the lock script in the input of Tx1 contains Alice's signature, which signs the expected portion of the data. The expected portion of the data (the "message") must also be included in Tx0 to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx0 (thus a separate element needs to be explicitly included in specifying the signed portion of the data, since the signed portion of the data is already inherently present).

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

[0056] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the node 104 considers Tx1 valid. If it is a storage node 104S, this means adding it to the pool 154 of transactions awaiting proof-of-work. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106, thereby propagating it throughout the network. Once Tx1 is validated and included in the blockchain 150, it defines it as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume outputs already consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

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

[0058] In practice, Alice typically also needs to include a fee for the winning miner, because today, the reward for the generated transaction alone is typically not enough to incentivize mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and thus, while technically valid, it will still not be propagated and included in the blockchain 150 (the miner's protocol does not force the miner 104M to accept transaction 152 if the miner does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount pointed to by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically awarded to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference automatically goes to the winning miner 104M. However, nothing necessarily precludes being able to explicitly specify a miner's fee in a unique one of the UTXOs 203 of transaction 152, alternatively or additionally.

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

[0060] Alice and Bob's digital assets consist of the unspent UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, a given party's 103's assets are typically dispersed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to aggregate the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on any of the storage nodes 104S, for example, the storage node 104S that is closest to or best connected to each party's computer device 02.

[0061] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ] to [ChecksigP A ]=OP_DUPOP_HASH160 <H(P A )>OP_EQUALVERIFYOP_CHECKSIG. "OP_...." represents a specific opcode in a scripting language. OP_CHECKSIG (also known as "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, all occurrences of the signature ("si") are removed from the script, but additional requirements, such as a hash puzzle, remain in the transaction, which is verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for generating an unspent output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata can include a document that is desired to be stored on the blockchain.

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

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

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

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

[0066] <Example definition> Below are some example definitions that may be employed in some implementations. Note that these are not intended to limit all possible implementations, but are provided only to aid in understanding certain possible implementations that may be utilized in some possible implementations of the exemplary use cases described below.

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

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

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

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

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

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

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

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

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

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

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

[0078] Definition 9: nLocktime. 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, meaning that a transaction can only be added to the blockchain after a specified block or a specified time. If nLocktime is set less than 500,000,000, it is considered block height. If it is set greater than or equal to 500,000,000, it is considered a representation of UNIX time. It is the number of seconds after 00:00:00 on January 1, 1970.

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

[0080] Definition 10: nSequence. The sequence number (nSequence) indicates the version of a transaction as a message. Any change to the transaction increments the sequence number by one. The maximum value of nSequence is 2. 32 -1, and sequence numbers typically default to this maximum value to indicate a transaction is complete. An nSequence value is defined for each input of a transaction, specifying the time period after the UTXO referenced by the input is included in a block before it becomes available as a valid input. If a miner sees two transactions with the same input, it will choose the transaction with the higher sequence number. However, this feature is commonly disabled.

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

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

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

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

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

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

[0087] On-chain mechanism for releasing content to users The following describes an exemplary mechanism for releasing content to multiple users based on inputs added by multiple users to a transaction, a so-called crowdfunding transaction, with an integrated on-chain mechanism for releasing the content to users once the crowdfunding target is reached. For example, this may be used as a novel means of implementing multi-party streaming, whereby there is a new crowdfunding transaction for each portion or "chunk" of media data in the stream.

[0088] The media content is divided into M parts D1, D2, ... D M The total amount of digital assets is divided into M parts, and M respective crowdfunded transactions are generated (preferably in advance) and hosted on a (e.g., generally public) server accessible to multiple different users. Each of these transactions has an output that specifies the amount of digital assets to be paid to a content vendor (e.g., Bob) for each portion. A locking script in the output of each transaction ensures that for a second transaction requesting to redeem the output, the input of the second transaction is a respective secret value S m This also includes scripts that require that the script must contain m acts as a key to release (e.g., decrypt) each portion of the media content. m is simply called secret in the sense that it is secret until it is published to the blockchain 150 as part of a second transaction, after which it is no longer secret.

[0089] For each portion m=1...M, each of the N users accesses the server-hosted crowdfunding transaction via a side channel 301 (i.e., off-chain) and adapts it by adding inputs. This is done until the funding target is met, i.e., the inputs total at least enough to form the output amount (or the transaction is no longer valid), and in fact also covers the mining fees (or the transaction is not accepted by any miner 104M for mining, even if technically valid).

[0090] "Streaming" then occurs when a vendor (e.g., Bob) sends a secret S m (One payment transaction redeeming the output of one crowdfunding transaction can instead broadcast one secret S m (Discloses ). In some embodiments, Vendor Bob may send each secret separately directly to users via side channel 301 in addition to publishing it on blockchain 150. Or, if he does not, then possibly some or all of the users may be peers (acting nodes 104) in the P2P network. In this case, they will also receive it in the payment transaction when Bob broadcasts it to the P2P network. Either of these should be fast, since they can be done as fast as the information can be transmitted. If neither is the case, secret S m is ultimately on the blockchain 150, where some or all of the users can retrieve it. Thus, Vendor Bob accepts payments but does not have a secret key S m Therefore, it is not possible to commit fraud by not releasing the

[0091] This secret key S m may be referred to herein as a “media key,” which allows a user who obtains the key to access the corresponding portion D of media data content hosted on an off-chain data source 401. m In an embodiment, the media key S m contains at least one decryption key. In this case, the user downloads it to his / her computer 102 and obtains the decryption key S m , and accesses the portion of the media data by decrypting it using .

[0092] key S m There are at least two possible scenarios for S. Scenario 1: m may simply act as a single common key, directly allowing all users 103a to unlock their respective pieces of content, i.e., once funding is raised, the content is made available to anyone with access to the P2P network 106 (but if no one contributes, the content is not shown to anyone). However, this is considered unfair, as it also makes the content available to any other member of the public, even if they did not contribute to the funding.

[0093] Therefore, in the embodiment, scenario 2 is used. m is that each user has their own individual key s, one for each user n=1...N who contributed input. m,1 …s m,N , where a given user can generate a portion of content D m In order to access (e.g., so that the user can decrypt the content), the user must m and their own individual key s generated based on some information personal to the user m,n must be applied to each individual key s m,n is thus tied to each user, allowing only that user to access (e.g., decrypt) the intended content. An example of how this can be done is described below.

[0094] The secret key (S) that is revealed when the output of the crowdfunding transaction is spent. m ) to the transaction, this allows crowdfunding the on-chain disclosure of a secret, rather than crowdfunding some off-chain process or event. This advantageously integrates the realization of crowdfunding results into on-chain mechanisms.

[0095] In some embodiments, the disclosed process may be used to simply crowdfund and release a single, independent piece of content D. However, as discussed, it may also be used to crowdfund and release part D. m It can also be used to release a sequence or stream of content, where m=1...M, each based on its corresponding crowdfunding transaction. The advantage of this is that it adds granularity to crowdfunding, and content can be crowdfunded one portion at a time. For example, if a TV series is divided into its episodes, the vendor (Bob) can ask people to crowdfund them and release one episode as fast as they are crowdfunded. For example, this could be used by an over-the-top (OTT) video streaming service. The service advertises that they have the rights to a popular series and that they will release each episode as soon as it is crowdfunded by a user. Users who actually pay for the crowdfunded transaction get early access to the episodes, for example.

[0096] Granularity means that each episode can also be divided into smaller packages, for example, by seconds or as appropriate.

[0097] Similar techniques can be applied to many other applications such as online education or lectures or radio shows, by replacing "TV episodes" with lectures etc.

[0098] An exemplary implementation will be discussed in detail with reference to FIGS.

[0099] Figure 4 shows an extension to the configuration of Figure 3, whereby each computing device 102a-1, 102a-2, ..., 102a-N of a plurality of first users 103a-1, 103a-2, ..., 103a-N operates to connect to Bob 103b's computing device via side channel 301. By way of general illustration only, the first users are here given different names, all beginning with "A," e.g., Alice, Adam, and Agnes. What has been discussed above with respect to device 102a and client 105a of first party 102a may equally apply to any of the first users' devices 102a-1, 102a-2, ..., 102a-N in the scenario of Figure 4.

[0100] In this exemplary scenario, Bob plays the role of a media content vendor. Bob's computing device 102b is configured in the role of a server, which may include the resources of one or more dedicated server units at one or more geographic sites, or one or more user devices playing the server role, or any combination thereof. Bob's device 102b also remains installed at client 105b of P2P network 106, as does each of first user's devices 102a-1, 102a-2, ... 102a-N. The above discussion regarding Bob's device 102b and client 105a, and side channel 301, may equally apply to the scenario of FIG. 4. Note again that side channel 301 does not necessarily imply a single link or a single access technology. Thus, in an embodiment, the side channel 301 discussed with respect to FIG. 4 may represent a bundle of links between Bob's device 103b and devices 103b-1, 103b-2, 103bN of different first users 102a, 102a-2, ..., 102a-N using one or more types of access technologies.

[0101] The system also includes an off-chain data source 401 (i.e., a source that stores and makes available to users 102a data that is not recorded on the blockchain 150). This is shown separate from Bob's device 102b in FIG. 4, but may form part of Bob's device 102b. Alternatively, it may actually be separate from Bob's device 102b; for example, Bob may act as a vendor representing content hosted by a third party on his own behalf. Either way, the off-chain data source 401 may store one or more portions D of media data to be crowdfunded. m The off-chain data source 401 is accessible to the client software 105a-1, 105a-2, ... 105a-N on each of the first party devices 102a-1, 102a-2, 102a-N via a network. The network may be the same network 101 (e.g., the Internet) through which the P2P overlay network 106 is implemented, or a separate network such as a mobile cellular network or an intranet within an organization, or any combination thereof.

[0102] The following is described in relation to an example where content is divided into multiple portions (m=1...M). However, it will be understood that the same mechanism can be used to release single portions of data. Each portion of media data (content) may comprise an entire episode of an audio or video program series, or a portion of a given episode or standalone program (e.g., a movie). The granularity can also be reduced to the level of individual packages or packets of programs crowdfunded on a packet-by-packet basis (e.g., per second or finer).

[0103] 6 illustrates a set of transactions 152 for use in accordance with embodiments disclosed herein. Each data portion D m For example, the set includes multiple zeroth transactions Tx0, first transactions Tx 1-m , and the second transaction Tx 2-m Note that these names are merely convenient labels. They do not necessarily mean that these transactions are immediately placed one after the other in block 151 or blockchain 150, or that transaction 0 is the first transaction in block 151 or blockchain 150. Also, these labels do not imply anything about the order in which these transactions are sent to network 106. They simply represent a logical series in which the output of one transaction is pointed to by the input of the next transaction. Recall that in some systems, it is possible for a parent to be sent to network 106 after its children (in which case the "orphaned" child is buffered at one or more nodes 104 for a period of time, waiting for its parent to arrive).

[0104] The zeroth transaction Tx0 may be referred to as the source transaction for the purposes of the present invention and serves as the source of the amount of digital assets of the first transaction. 1-m may be referred to as a crowdfunding transaction for the purposes of this invention. m Acts as an intermediary to conditionally transfer an amount of digital assets from source transaction Tx0 to fund the release of second transaction Tx 2-m may be called a payment transaction or target transaction, and is the transaction that unlocks the conditions in the first transaction and provides payment to Vendor Bob (or, in some cases, the beneficiary represented by Bob).

[0105] As shown in FIG. 6, each zeroth or source transaction Tx0 includes at least one output 2030 (e.g., output 0 in the figure) that specifies an amount of a digital asset, and further includes a locking script that locks this output to a user, such as Alice 103a or Adam 103b. This means that the locking script of source transaction Tx0 requires a condition to be met. This condition is that an input of any transaction that attempts to unlock the output (and thus redeem the amount of the digital asset) must include a cryptographic signature of the user in its unlocking script, the input locked to that user, and the signature generated using the user's public key. In this sense, the amount defined in the output of Tx0 is said to be owned by that user, such as Alice or Adam. The output may be referred to as a UTXO. For purposes of this invention, it is not particularly important which outputs of previous transactions point to the input of source transaction Tx0 (as long as they are sufficient to cover the total outputs of source transaction Tx0).

[0106] In the present case, the transaction that unlocks the output of source transaction Tx0 is the data part D m First crowdfunding transaction for Tx 1-m Therefore, Tx 1-m The final instance of Tx has multiple inputs 2021, each containing a pointer to a respective output of a respective one of the source transactions Tx0. 1-m Each output of Tx0 further includes an unlock script configured to unlock the pointed output of each Tx0 according to conditions defined in the lock script of that output, requiring at least the signature of the respective user. 1-m Some protocols require that some part of Tx be signed. 1-m The part is Tx 1-m This can be a setting defined within the unlock script. For example, this can be set by the SIGHASH flag, which is a byte appended to the signature. So, in data terms, the unlock script is: <Sig P A > <sighashflag><P A Alternatively, the part of the that needs to be signed can simply be Tx 1-m In either case, the part to be signed is typically the same as the part to be signed, excluding the unlock script itself, and the Tx 1-m This means that some or all of the inputs of Tx 1-m This means that inputs are adaptable, allowing the user to add inputs 2021.

[0107] First or intermediate transaction Tx 1-m has at least one output 2031 (e.g., Tx 1-m The output specifies the amount of the digital asset to be transferred. The output also includes a locking script that defines the conditions required to unlock the output and thus redeem the amount. The conditions are specified in Tx 1-m , in this case the first version of the second transaction, Tx 2-m , requires that the unlock script of a transaction attempting to unlock a piece of content D includes Bob's cryptographic signature and a payload that Bob must include in his unlock script. As described in more detail below, this payload is used by users 103a-1...103a-N to unlock a piece of content D. m A secret key S that allows you to release m The requirement to include a payload is 1-m The signature requirement can be imposed by a hash challenge included in the lock script of the Tx. The challenge includes a hash of the payload (but not the payload itself) and a script fragment that (when executed on node 104 together with the unlock script) is configured to test whether the hash of the payload provided in the corresponding unlock script is equal to the hash value provided in the lock script. The requirement on the signature is imposed, for example, by CheckSig as described above. In an embodiment, the first condition is that Alice's signature is equal to Tx 2-m does not require that the unlock script be included. Tx must be signed by Bob. 2-m The part is Tx 2-m This may be a setting in the unlock script (e.g., specified by the SIGHASH flag) or may be fixed. Either method typically excludes at least the unlock script.

[0108] Second, target transaction Tx 2-m has at least one input 2022 (e.g., Tx 2-m input 0), which is Tx 1-m The above output (in the example shown, Tx 1-m Contains a pointer to the output (0) of the Tx 1-m Tx based on meeting the conditions defined in the lock script 1-m The second transaction Tx further includes an unlock script configured to unlock the output of the second transaction Tx. 2-m has at least one output 2032 (e.g., Tx 2-m 0), which specifies the amount of digital assets to be transferred to Bob. Output 2032 also contains a lock script that locks it to Bob (i.e., it requires any further future transactions that include Bob's signature in the unlock script to be used). In this sense, the target transaction Tx 2-m The output is said to be owned by Bob. This output may again be called a UTXO.

[0109] Figure 6 shows item D of the crowdfunding data. m 1 illustrates a method for using a set of transactions such as those described in connection with FIG. 5 to release a set of user data to multiple users 103a-1...103a-N. The method is described from the perspective of vendor Bob 103b. The method may be performed by software 105b executing on Bob's equipment 102b. It will be appreciated that, according to another aspect, a corresponding method is provided that is performed from the perspective of a user 103a, such as Alice 103a-1, by a client application 105a executing on the user's equipment 102a. Phrases such as "by Alice (or user)," "by Bob (or vendor)," and "by a third party" may be used herein as shorthand for "by software 105a executing on user's 103a's computing equipment 102a," "by software 105b executing on vendor's 103b's computing equipment 102b," and "by software executing on a third party's computing equipment," respectively. Also, note that the equipment of a given party may include one or more user devices used by that party, or some server resources, such as cloud resources, utilized by that party, or any combination thereof, which does not necessarily limit operations to being performed on a single user device or at a single physical location.

[0110] In step S10, the vendor (Bob) 1-m and hosts it on the server of his device 102b, thus allowing Tx 1-m available to any of users 103a-1...103a-N. As mentioned above, vendor Bob's server may include any serving computer equipment acting as a server, and may include one or more dedicated server units (or resources thereof) and / or one or more user devices located at one or more geographic sites. It may be made accessible to devices 103a-1...103a-N of users 102a-1...102a-N via the same network 101 on which the P2P overlay network is implemented (e.g., the Internet), or a separate network (e.g., a mobile cellular network or an internal intranet within an organization), or any combination thereof.

[0111] In an embodiment, Bob may download media data D before releasing or receiving funding for the first part in the sequence. m For all parts of the crowdfunding transaction Tx 1-m , m=1...M initial template forms may be formulated and stored. However, for simplicity, the following method is m and its corresponding crowdfunding transaction Tx 1-m In an alternative embodiment, the crowdfunding transaction Tx 1-m Note also that one, some, or all of the Tx transactions may be created for Bob by a third party and provided to him for hosting on his serving device 102b. The following is a summary of how Bob processes each crowdfunding transaction (i.e., first transaction) Tx 1-m While the vendor "Bob" will be described in terms of formulating the "Bob" himself, it will be understood that this is not limiting. It will further be understood that the vendor "Bob" may in fact be an organization that includes more than one person, rather than an individual user.

[0112] Tx originally created by vendor Bob 1-m includes at least one output 2031, which is a media content D m A value X specifying the amount of digital assets he wishes to receive for releasing each portion of m Contains X m is the number of all m (i.e., media D m may be the same for all parts of part D m Bob also has media data D stored on his device 102b. m The target value T required to release each part of m Stores T m In systems that do not require mining fees (e.g., consortium blockchain systems), m Alternatively, T m =X m +M, where M is the mining fee. The mining fee M may be a function of time t that depends on the current price, or may be fixed (e.g., set to a high enough margin that may cover any reasonable mining fee fluctuations over the period in which funding from users 103a-a...103a-N is expected).

[0113] Tx 1-m Output 2021 also contains a locking script. The locking script is used by the transaction that attempts to redeem output 2021, in this case Tx 2-m , the unlock script for the media content D m The secret access key S for each part of m (media key). As mentioned above, this requirement may be implemented with a hash challenge: the lock script contains a hash of the payload containing the media key, and the script piece is configured to hash the value of the payload contained in the unlock script, compare this to the value of the hash in the lock script, and unlock the output if they match.

[0114] In an embodiment, vendor Bob may send his own input 2021 to the Tx 1-m This input is included in the version of each source transaction Tx locked to Bob. 0-m-B The amount of the digital asset specified in this output may be zero or a nominal (negligible) amount (e.g., if the protocol does not allow zero amounts in spendable outputs). 0-m-B The locking script for an output of is executed by signing Bob's signature into the input of the transaction that unlocks it, in this case Tx 1-m requires that the unlock script in Bob's input be included. 1-m Bob's input in Tx 1-m The unlock script contains Bob's signature, which signs the part of the certificate, and also contains Bob's public key, which allows verification of Bob's signature.

[0115] Tx 1-m The purpose of this input may be to provide Vendor Bob with a way to sign the transaction, thus signaling that he endorses the transaction. 1-m should preferably have at least one initial input to vouch for (sign) the output 2031. Without an input, the output is released and anyone can replace it. However, as long as there is at least one input 2021 that signs the output 2031, the output cannot be changed.

[0116] Further, in an embodiment, Tx 1-m Vendor Bob's input to Tx also provides one or more of the users 103a-1, ..., 103a-N with a way to verify the authenticity of the transaction before adding their own input 2021 to fund the transaction. For example, the system may include a trusted third party database 402 made accessible to one, some, or all of the users' devices 102a-1, ..., 102a-N. It may be accessible via the same network 1 (e.g., the Internet) 01 on which the P2P overlay network 106 is implemented, or a separate network such as a mobile cellular network or an intranet, or any combination thereof. The database 402 contains a list of public keys of one or more vendors recommended by trusted third parties. Thus, if the database 402 is accessed and Bob's public key is listed therein (i.e., if the value is Tx 1-m By checking that the public key matches the one found in Bob's input to , they can gain confidence that Bob is a legitimate vendor.

[0117] However, vendor Bob's input is optional. Alternatively, the Tx 1-m does not include input 2021.

[0118] In step S20, vendor Bob begins receiving input from one or more users 103a-1...103a-N. Each such user 103a submits a crowdfunding transaction Tx 1-m , and thereby adapts this transaction to add her own respective input 2021. The inputs added by each of these users 103a-n are added to the respective source transaction Tx 0-m-n , which specifies the amount of digital assets locked for that user 103a-n and contains a locking script that locks the respective output for that user. 0-m-n The locking script of a transaction unlocks it, in this case Tx 1-m , requires that the unlock script for each input of includes the signature of each user 103a-n. 1-m The user input to Tx 1-m The unlock script contains the user's signature signing the portion of the .txt file, and also contains the user's public key allowing verification of her signature.

[0119] After receiving one or more inputs from one or more users 103a, vendor Bob sends a Tx 1-m is his target T m That is, he checks whether he has enough inputs to satisfy the source transaction Tx pointed to by the inputs received so far. 0-m and the amounts in Output 2030 are added together and are at least the target amount T m If not, the method loops back and continues from step S20.

[0120] Tx 0-m The total amount of points contributed by the inputs is at least the target T m When the number of Tx 1-m and the corresponding payment transaction Tx 2-m to the network 106, the P2P network 106. That is, he issues Tx 1-m and Tx 2-m to at least one of the forwarding nodes 104F, from where it is propagated throughout the network 106. Each of these transactions is validated at each node 104, mined by one of the mining nodes 104M into a block 151, and recorded in the copy of the blockchain 150 maintained at each storage node 104S. Alternatively, he may send each of these transactions Tx 1-m and Tx 2-m to one of users 103a or a third party, who then forwards it to network 106. Either way, Vendor Bob then causes both transactions to propagate through nodes 104 of network 106 and be publicly recorded on blockchain 150.

[0121] Crowdfunding Transaction Tx 1-m The output 2031 is the data part D m Payment to Bob for X m and includes a lock script. Payment transaction Tx 2-m Tx 1-m It points to the output of and contains an input 2022 containing the lock script. Tx 2-m includes an output 2032 that includes a lock script that specifies an amount of a digital asset and locks this amount to Bob.

[0122] Tx 1-m The lock script in the output of 2-m , 103a-N includes a specified payload. For example, this requirement may be imposed by a hash challenge in the lock script, as described above. This payload is required when users 103a-1, ..., 103a-N download media content D from an off-chain data source 401. m a media key (e.g., a decryption key) S that allows accessing (e.g., decrypting) the corresponding portion of m To request his payment, Vendor Bob sends a payment transaction Tx 2-m is S m This means that when Bob claims payment, it must be made publicly visible on the blockchain 150.

[0123] Each user 103a-1, ..., 103a-N therefore has a media key S m They can then inspect the blockchain 150 to find the media key S m 401 from the off-chain data source 401 using m can be acquired and consumed.

[0124] In some cases, vendor Bob may optionally provide media key S to one or more or all of users 103a via side channel 301 in addition to publishing it on blockchain 150. m and / or, if one or more of the users 103a are also peers 104 in the P2P network 106, they may send a payment transaction Tx 2-m When is propagated through the network 106, optionally before it is mined, S m Alternatively, in the future, an API may be available that allows users to query the pool 154 of mining nodes 104M, thus allowing users to see the data in pending transactions before they are mined. However, whatever media User 103a receives, the key is that Vendor Bob receives media key S via at least one channel (blockchain 150). m is made available to user 103a. Thus, Bob cannot commit fraud by taking payments but not releasing the corresponding media content.

[0125] In an embodiment, a media key S m contains at least one decryption key. In this case, the user 103a receives the media data D m to his / her respective computing device 102a, and then applies the decryption key to download the media data portion D m , thus obtaining a (clear) copy of the data on their respective computing devices 102a. Alternatively or additionally, the media key S m First, place the media data part D m In this case, the user may enter the passcode S m to the off-chain data source 401, and in response, m to his / her respective computing device 102a. In some embodiments, the media key S m may include both encryption keys and passcodes, and access may combine both approaches.

[0126] Some embodiments may use just one single passcode or generic decryption key that allows anyone to access the data elsewhere. This is simple to implement, but may be undesirable since it allows non-paying users to access the data if the code is compromised. A more secure option is therefore to use a single public key based approach of group-based public key cryptography (this public key can be generated using any chosen group-based public key cryptography, preferably ECDSA). Contributors already have their public key, i.e., PK i The organizer generates a private key V and m = V G, and S m,i =V·PK i Calculate S i is a shared secret between the organizer and contributor i. The value can be hashed to generate a secret key for symmetric cryptography. The organizer uses the shared secret to encrypt data for each contributor i. This encrypted data is preferably communicated off-chain. Currently, contributors cannot decrypt the data.

[0127] In the unlock script, the organizer is S m Each contributor can use their own private key to calculate the shared secret and derive the decryption key if necessary. The drawback of this is that the public cannot provide S to the organizer in the lock script. m Anything that actually forces you to disclose (S m The key is that the user must trust the identity of the user (which may be a hash of the identity of the user). This may not be an issue for a well-known OTT provider, for example. In embodiments, the scheme can also be coupled with a trusted database 402 for further trust.

[0128] Therefore, in the embodiment, the media data D m To access portions of the media, each user 103a-n must have a respective individual media key (e.g., decryption key) s that is tied to that particular user. m,n In this case, Vendor Bob must use Tx 1-m Based on the public key of each user 103a-n included in each input of each user 103a-n to Tx 1-m Media key S contained in m Each user 103a-n calculates S m Upon receiving the media key, they will use their own individual media key s m,n and uses this to retrieve media content D from an off-chain data source 401 m The individual media key for each user who has access to the corresponding portion of is unique to that user (where "unique" means that the probability of collision is at least small, near zero).

[0129] This may be accomplished by using one of a variety of available key-agreement techniques known in the art. Each contributing user 103a-1, ..., 103a-N shares their respective public key with Tx 1-m Vendor Bob can then use the public key in conjunction with a key-agreement technique to generate a secret that is shared with each contributor. Bob can then use the shared secret, such as a symmetric encryption key, to encrypt the media data D m , 103a-N). This includes sending it to vendor Bob himself if data source 401 is implemented on his device 102b, or triggering it to be sent from a third party if data source 401 is implemented elsewhere. Either way, each contributor 103a-n can, in effect, create a portion of the media data content D m Bob receives a customized encrypted version of the part of S on-chain. m Upon disclosing the shared secret s, each individual 103a-n m,n Note that each has a different shared secret (here "shared" means shared between vendor Bob and each user 103a-n, not shared among different users 103a-1, ..., 102a-N). The individual shared keys are unique as long as the public keys used in the inputs are unique.

[0130] An exemplary implementation is as follows, which is based on the standard Diffie Hellman key exchange: I. Alice contributes and provides her public key PK_A in her input. II. There is a hash check H(PK_B) in the lock script, meaning that to unlock it, Bob must reveal PK_B. III.Bob is (sk B Penalty kick A ) and use it as a symmetric encryption key to encrypt the data just for Alice. IV. When Bob reveals PK_B, Alice can A Penalty kick B ) can be used to compute the same symmetric key. Similarly for other contributing users Adam, Agnes, etc. Note that this is just one of many possible implementations implemented using standard key agreement techniques.

[0131] As an example scenario, say Bob wants to broadcast a video, which could be a lecture, a tutorial, or a general event.

[0132] In this scenario, Bob knows exactly when he wants to start his broadcast. He also has a predetermined price for his broadcast. The video data is encrypted chunk by chunk and sent off-chain. The partial secret value s m are generated by Bob and exchanged on-chain, chunk by chunk.

[0133] The participants then derive the perfect secret key to decrypt the data.

[0134]

number

[0135]

number

[0136]

number

[0137] This process continues until the value of the input covers the value of the output or the time lock expires.

[0138] It may be possible for Bob to cheat by falsely advertising his event. However, it may be required that there be a publicly verifiable source linking the event to a public key. The public key may be the ECDSA public key claimed in input 0 of TX1. Thus, interested parties can tell whether TX1 is authentic.

[0139] If there is not enough input and Bob wants to go further, he can fill the price gap himself.

[0140] If there is more interest than Bob expected, he can create another transaction or allow participants to copy the output from TX1 and create new transactions themselves.

[0141] Each participant 103a is identified by their public key in their input 2021. The public key is used to calculate a customized secret key to encrypt data. m Upon disclosing, participants will be able to see the data they received, D m The secret key to decrypt the

[0142] To continue viewing the content, participant 103a simply follows the subsequent transaction and fills input 2021.

[0143] As mentioned above, for security reasons, outputs must be locked with a signature, such as an ECDSA signature. As a result, no one can modify the output; that is, neither Bob nor Alice (or any other user) can add their modification address to the output. Therefore, Alice or Bob must ensure that their UTXO provides the exact amount they want to pay.

[0144] It will be understood that the above embodiments have been described by way of example only. More generally, there may be provided a method, program, apparatus, or set of transactions according to any of the following statements. It will be understood that all independent statements define optional features.

[0145] (Statement 1) According to one aspect disclosed herein, there is provided a computer-implemented method for enabling multiple users to access an item of media content, the method comprising: providing a first transaction, the first transaction including: (i) one or more outputs including at least a first output specifying an amount of digital assets to be transferred to the vendor; and (ii) initially a total of zero or more inputs, where a total input amount of the digital assets specified in any outputs of any source transaction pointed to by the zero or more inputs is less than a total output amount of the digital assets specified by the one or more outputs, the first output of the first transaction including a lock script specifying a condition to be satisfied by an unlock script to unlock the first output; receiving an input from each of the plurality of users via a side channel and adding each received input to the first transaction, each received input pointing to an output of a respective source transaction specifying an amount of the digital asset; when a target is reached, such that a total input amount pointed to by the inputs of the first transaction equals or exceeds the output amount, causing the first transaction and a second transaction to be published onto a blockchain network to be recorded on a blockchain, wherein the second transaction points to the first output of the first transaction and includes the unlock script that satisfies the condition; Including, A method is provided in which the condition specified by the lock script requires that the unlock script include a media key that allows the user to access the item of media content.

[0146] (Statement 2) In an embodiment, a method may be provided as in Statement 1, wherein the target is such that the total input amount exceeds the total output amount by at least enough mining fees to cause the first transaction to be accepted by a miner for mining into a block.

[0147] (Statement 3) In an embodiment, a method as described in statement 1 or 2 may be provided, comprising repeating the method for each of a plurality of data items, each item of content forming a different respective one of a sequence of portions of media content.

[0148] (Statement 4) In an embodiment, a method may be provided as in statement 3, wherein the portion is a given episode or packet of an independent program or movie that is streamed to a user in real time.

[0149] (Statement 5) In an embodiment, there may be provided a method according to statement 3, wherein the portions are different episodes in a series.

[0150] (Statement 6) In an embodiment, a method may be provided as described in any of Statements 1 to 5, wherein instructions linked to the first transaction are listed in a database operated by a third party independent of the vendor and user, thereby enabling the user to verify that the first transaction is legitimate media for obtaining the media key.

[0151] (Statement 7) In an embodiment, a method according to any of Statements 1 to 6 may be provided, wherein the zero or more initial inputs include at least one initial input including an unlock script included by the vendor for unlocking the output of each source transaction, and the unlock script in the input of the vendor includes the vendor's public key and the vendor's signature formed using the vendor's private key corresponding to the public key.

[0152] (Statement 8) In an embodiment, a method may be provided as in statements 6 and 7, wherein the instructions include a copy of the content provider's public key, thereby enabling the user to perform the verification by comparing the public key in the unlock script of the vendor's initial input with a copy of the public key in a database.

[0153] (Statement 9) In an embodiment, a method may be provided according to any of statements 1 to 8, including a step in which, after receiving multiple inputs from the user, the vendor adds further inputs to form at least a difference, although this is not yet sufficient to reach the target.

[0154] (Statement 10) In an embodiment, a method may be provided for any of Statements 1-9, including: in response to receiving excess input from a user indicating an amount of digital assets greater than that required to meet the target, generating a new instance of the first transaction and adding the excess input to the new instance of the first transaction.

[0155] (Statement 11) In an embodiment, a method may be provided according to any of statements 1 to 10, wherein the media key includes a decryption key, and the user is enabled to access the item of media content by decrypting the item of media content using at least the decryption key.

[0156] (Statement 12) A method may be provided according to any of statements 1 to 11, wherein the media key is configured to allow an individual media key to be calculated by each of the plurality of users, thereby ensuring that only users who have provided input have access to the item of media content.

[0157] (Statement 13) In an embodiment, the method of statements 11 and 12 may be provided, wherein each individual media key includes an individual decryption key. (Statement 14) In an embodiment, a method according to any of Statements 1 to 13 may be provided, wherein each of the user inputs includes a respective unlock script that unlocks a respective source transaction output, and wherein each of the unlock scripts includes a respective public key of the user and a respective signature of the user formed using the user's private key.

[0158] (Statement 15) In an embodiment, a method is provided in statement 14, which is dependent on statement 12 or 13, in which an individual media key for each user is generated based on the user's respective public key taken from input received from that user.

[0159] (Statement 16) According to another aspect disclosed herein, there is provided a computer program embodied on a computer-readable storage device and configured to perform the method described in one of statements 1 to 15 when executed on a vendor's computing equipment.

[0160] (Statement 17) According to another aspect disclosed herein, a vendor's computer equipment includes: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device is provided, wherein the memory stores code configured to run on the processing device, the code configured to perform the method according to one of statements 1 to 15.

[0161] (Statement 18) According to another aspect disclosed herein, there is provided a method of accessing an item of media content made available in an off-chain data source, the method comprising: accessing a vendor's server hosting a first transaction, the first transaction including: (i) one or more outputs including at least a first output specifying an amount of digital assets to be transferred to the vendor; and (ii) initially a total of zero or more inputs, where a total input amount of the digital assets specified in any outputs of any source transaction pointed to by the zero or more inputs is less than a total output amount of the digital assets specified by the one or more outputs, and the first output of the first transaction includes a lock script specifying a condition to be satisfied by an unlock script to unlock the first output; sending to the server via a side channel at least one input among the plurality of inputs sent by the plurality of users to be added to the first transaction, each input pointing to an output of a respective source transaction specifying an amount of the digital asset, thereby allowing the vendor to publish the first transaction and a second transaction on a blockchain network to be recorded on a blockchain when a target is reached, whereby the total input amount pointed to by the inputs of the first transaction equals or exceeds the output amount, wherein the second transaction points to the first output of the first transaction and includes the unlock script that satisfies the condition; Including, the condition specified by the lock script requires that the unlock script include a media key; There is provided a method, the method further comprising using the media key to unlock the item of media content.

[0162] (Statement 19) According to another aspect disclosed herein, there is provided a computer program embodied on a computer-readable storage device and configured to perform the method described in statement 18 when executed on a user's computing device.

[0163] (Statement 20) According to another aspect disclosed herein, a user's computing device includes: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device is provided, wherein the memory stores code configured to run on the processing device, the code configured to perform the method described in statement 18.

[0164] (Statement 21) According to another aspect disclosed herein, a set of transactions for recording in a blockchain, the set embodied on one or more computer-readable data media: a first transaction including: (i) one or more outputs including at least a first output specifying an amount of digital assets to be transferred to a vendor; and (ii) a plurality of inputs from a plurality of different users, each input pointing to an output of a respective source transaction specifying the amount of the digital assets, wherein a total input amount of digital assets pointed to by the inputs of the first transaction equals or exceeds a total output amount specified by the one or more outputs, and the first output of the first transaction includes a lock script specifying a condition to be satisfied by an unlock script to unlock the first output; a second transaction including an input that points to the first output of the first transaction, the input of the second transaction including an unlock script that satisfies the condition, the condition specified by the lock script requiring that the unlock script include a media key that enables access to an item of media content stored in an off-chain data source; and A set of transactions is provided, including:

[0165] Other variations or uses of the disclosed technology may become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.< / sighashflag> < / sigpa>

Claims

1. 1. A computer-implemented method for enabling a respective computing device of each first party of a plurality of first parties to access an item of media content, the method comprising: providing a first transaction, the first transaction including: (i) one or more outputs including at least a first output specifying an amount of digital assets to be transferred to a second party; and (ii) initially a total of zero or more inputs, where a total input amount of the digital assets specified in any outputs of any source transaction pointed to by the zero or more inputs is less than a total output amount of the digital assets specified by the one or more outputs, the first output of the first transaction including a lock script specifying a condition to be satisfied by an unlock script to unlock the first output; receiving an input off-chain from a respective computing device of each first party among the plurality of first parties, and adding each received input to the first transaction, wherein each received input points to an output of a respective source transaction specifying an amount of the digital asset; when a target is reached, such that a total input amount pointed to by the inputs of the first transaction equals or exceeds the total output amount, causing the first transaction and a second transaction to be published onto a blockchain network to be recorded on a blockchain, the second transaction including an input that points to the first output of the first transaction and includes the unlock script that satisfies the condition; Including, wherein the condition specified by the lock script requires that the unlock script include a media key that enables the respective computing device of each first party of the plurality of first parties to access the item of media content.

2. 2. The method of claim 1, wherein the target comprises the total input amount exceeding the total output amount by at least enough mining fees to cause the first transaction to be accepted by a miner for mining into a block.

3. 3. The method of claim 1 or 2, wherein the step of repeating the method for each of a plurality of data items, each item of content forming a different respective one of the sequences of portions of media content.

4. 4. The method of claim 3, wherein the portions are given episodes or packets of independent programs or movies that are streamed in real time to the respective computing devices of each of the plurality of first parties.

5. The method of claim 3 , wherein the portions are different doses in a series.

6. 6. The method of claim 1, wherein the instructions linked to the first transaction are listed in a database operated by a third party using a computer device of the third party independent of the second party and the first party, thereby enabling the computer device of each first party among the plurality of first parties to verify that the first transaction is legitimate media for obtaining the media key.

7. 7. The method of claim 1, wherein the zero or more initial inputs include at least one initial input contained by a computing device of the second party, the at least one initial input including an unlock script for unlocking outputs of each source transaction, the unlock script in the second party input including a public key of the second party and a signature of the second party formed using a private key of the second party corresponding to the public key.

8. instructions linked to the first transaction are listed in a database operated by a third party using a computer device of the third party independent of the second party and the first party, thereby enabling the computer device of each first party of the plurality of first parties to verify that the first transaction is a legitimate media for obtaining the media key; 8. The method of claim 7, wherein the instructions include a copy of the public key of the second party, thereby enabling the respective computing device of each first party of the plurality of first parties to perform the verification by comparing the public key in the unlock script of the initial input of the second party with a copy of the public key in a database.

9. 9. A method according to any preceding claim, further comprising the step of, after receiving a plurality of inputs from each of the plurality of first parties, the second party's computer device adding further inputs to form at least a difference, but not yet sufficient to reach the target.

10. 10. The method of claim 1, further comprising: in response to receiving excess input from a computing device of the first party and / or another party, the excess input indicating an amount of digital assets greater than that required to meet the target, generating a new instance of the first transaction and adding the excess input to the new instance of the first transaction.

11. 11. A method according to claim 1, wherein the media key comprises a decryption key, and wherein the decryption key is used to decrypt an item of media content, thereby enabling the respective computing device of each first party of the plurality of first parties to perform the access of the item of media content.

12. 12. A method according to any preceding claim, wherein the media key is configured to enable an individual media key to be calculated by the respective computer device of each first party of the plurality of first parties, thereby ensuring that only the computer device of the party that provided input can access the item of media content.

13. the media key includes a decryption key, and wherein the decryption key is used to decrypt an item of media content to enable the respective computing device of each first party of the plurality of first parties to effect the access of the item of media content; The method of claim 12 , wherein each individual media key comprises an individual decryption key.

14. 14. The method of claim 1, wherein each of the first party inputs includes a respective unlocking script that unlocks a respective source transaction output, the respective unlocking script including a respective signature of the respective first party formed using the respective public key of the respective first party and the respective private key of the respective first party.

15. 15. A method according to claim 14 when dependent on claim 12 or 13, wherein an individual media key for each first party is generated based on the public key of each first party taken from input received from the first party.

16. A computer program embodied on a computer readable storage device and configured to perform the method of any of claims 1 to 15 when executed on a second party computing device.

17. a second-party computing device, a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to run on the processing device, the code being configured to perform a method according to one of claims 1 to 15 when executed on the processing device.

18. 1. A method of accessing an item of media content made available in an off-chain data source, the method comprising: accessing a first transaction, the first transaction including: (i) one or more outputs including at least a first output specifying an amount of digital assets to be transferred to a second party; and (ii) initially a total of zero or more inputs, where a total input amount of the digital assets specified in any outputs of any source transaction pointed to by the zero or more inputs is less than a total output amount of the digital assets specified by the one or more outputs, and the first output of the first transaction includes a lock script specifying a condition to be satisfied by an unlock script to unlock the first output; sending to the second party off-chain at least one input among the plurality of inputs sent by the plurality of first party computer devices to be added to the first transaction, each input pointing to an output of a respective source transaction specifying an amount of the digital asset, thereby enabling the second party computer device to publish the first transaction and a second transaction onto a blockchain network to be recorded on a blockchain upon reaching a target whereby the total input amount pointed to by the inputs of the first transaction equals or exceeds the total output amount, wherein the second transaction includes an input pointing to the first output of the first transaction and including the unlock script that satisfies the condition; Including, the condition specified by the lock script requires that the unlock script include a media key; The method further includes using the media key to unlock the item of media content.

19. 20. A computer program embodied on a computer readable storage device and configured to perform the method of claim 18 when executed on a first party computing device.

20. a first-party computing device, a memory including one or more memory units; a processing device including one or more processing units; Including, The memory stores code configured to execute on the processing device, the code comprising:

20. A computing device configured to perform the method of claim 18 when executed on the processing device.

21. 21. A system comprising: a second party computing device according to claim 17; and a first party computing device according to claim 20.

Images