Method and system for multiple input transactions

Abstract

A method is provided, comprising: providing a first transaction specifying an output amount of a digital asset that is greater than an amount pointed to by its inputs, wherein an output of the first transaction comprises a locking script specifying a condition; receiving an input from each of a plurality of users via a side channel, adding each received input to the first transaction; once a target is reached whereby 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 to a blockchain network for recording in a blockchain. The second transaction comprises an input pointing to the output of the first transaction and comprising an unlocking script satisfying the condition. The condition requires the unlocking script to comprise a media key enabling a user to access a media content item.

Description

Technical Field

[0001] This disclosure relates to a mechanism for delivering content to users that utilizes the concept of input-level extensibility in the context of a blockchain-based system, namely the ability to add (or remove) inputs to a transaction without verifying the invalidity of the transaction. Background Technology

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

[0003] Transactions in blockchains are typically used to transfer digital assets, i.e., data as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in transaction outputs. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, thus enabling the incorporation of more complex data. For instance, this can be used to store electronic documents, or even audio or video data, on the blockchain.

[0004] Each node in the network can have one or both of the roles of forwarding and storage. Each forwarding node propagates a (valid) transaction to one or more other nodes, thus spreading the transaction among them to all nodes in the network. Each storage node stores its own copy of the blockchain blocks. To have a transaction recorded on the blockchain, one party sends the transaction to a node in the network to which it is intended to be propagated. Each node is configured to adhere to the same node protocol, which includes one or more conditions to guarantee the validity of the transaction. Invalid transactions will not be propagated or mined into blocks. Assuming the transaction has been verified as valid and is therefore accepted on the blockchain, the attached user data will continue to be stored as an immutable public record at various nodes in the P2P network.

[0005] In an "output-based" model (sometimes called a "UTXO-based model"), the data structure for a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of digital assets, sometimes referred to as a UTXO ("unspent transaction output"). The output may further include a locking script specifying the conditions for redeeming the output. Each input includes a pointer to such an output in a previous transaction and may further include an unlocking script for unlocking the locked script of the pointed-to output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets, including a locking script defining one or more conditions for unlocking the output. The second transaction includes at least one input, including a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0006] In these models, when a second transaction is sent to the P2P network for propagation and recorded in the blockchain, one of the validity criteria applied by each node is that the unlocking script meets the requirements defined in the locking script of the first transaction. Another condition for the second transaction to be valid is that the output of the first transaction has not yet been redeemed by another valid transaction. Any node that finds the target transaction invalid based on any of these conditions will not propagate the transaction, nor will it include it in the block to be recorded in the blockchain. Another common scenario is that the total amount of digital assets specified in the output does not exceed the total amount pointed to by the transaction's inputs. Currently, in practice, even if the transaction is valid, the total input amount must exceed the total output amount.

[0007] Returning to the idea of ​​the locking script, suppose the target transaction is the transfer of a certain amount of digital assets from a first party (“Alice”) to a second party (“Bob”). One of the requirements defined in the locking script of the first transaction is typically that the unlocking script of the second transaction contains Alice’s cryptographic signature. The signature must be generated by Alice signing a portion of the second transaction. Which portion, however, can 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 does not include some other parts of the second transaction, such as part or all of the unlocking script itself.

[0008] This makes "extensibility" possible. That is, the unsigned portion of a second transaction can be modified ("extensible") without invalidating the transaction. Extensibility is generally a known concept in cryptography. Using extensibility, a message can be maliciously modified but still be considered authentic, so extensibility is often considered a security issue. In the context of blockchain, extensibility doesn't necessarily pose a problem, but is simply a clever human invention. Using extensibility, a part of a transaction can be modified without invalidating it.

[0009] Recently, it has been proposed to specifically utilize extensibility to use transactions as carriers of media data. The data content can be contained within the transaction's unlocking script, which is then sent between the parties via a side channel. One party can extend the transaction to remove the data and continue sending the extended version to the P2P network for mining (however, if the data is not removed, the transaction will bloat the blockchain).

[0010] Before a transaction is broadcast to the P2P network for recording in the blockchain, side channels, such as payment channels, allow the exchange of transactions or transaction-related data between parties "off-chain." Side channels are separate from the P2P overlay network, so any transactions sent via a side channel are not (yet) propagated through the network for recording in the blockchain until one party chooses to publish the transaction to the network. Standard payment channels require a "funds transaction," whereby both parties can effectively co-custody funds. The funds transaction is broadcast to establish the channel, and then once the relevant service is provided, a settlement transaction is broadcast to close the channel and spend the funds transaction.

[0011] Several solutions already exist for "micropayment channels," where one party ("Alice") sends a sequence of transactions to another party ("Bob") to pay Bob small installment payments. This does not require a cash transaction. At least one solution utilizes a side channel to stream movie data within data packets. Bob sends a sequence of data packets to Alice, and in response to each packet, Alice returns the corresponding transaction. Bob can then broadcast the transaction across the network to receive payment for the corresponding movie data packet.

[0012] Another use case for side channels is crowdfunding that allows for transactions. A fundraiser (let's say Bob) creates a template transaction where at least one output specifies the desired amount to be transferred to themselves or a third party they represent. However, this transaction doesn't yet contain enough inputs to reach the target amount. Therefore, the template transaction is initially invalid because the total amount of digital assets pointed to by its inputs is less than the total amount specified in its outputs. Bob makes the template transaction available to the public by publishing it off-chain on his server. Public members can then extend the template transaction on the server by adding inputs, which gradually increase until the transaction becomes effective. Once the target is reached, Bob publishes it to the P2P network to mine it into a block. In practice, the target value will need to be slightly more than the specified amount paid to Bob. Summary of the Invention

[0013] The problem with existing solutions for delivering content to users via micropayment channels is that they only allow a one-to-one relationship between the streaming provider and the individual streamed content: a single user must pay for each packet of the quasi-streamed content, which is then returned to the specific individual user via a side channel. If an individual user wants to stream the same content, they need to use the streaming provider to replicate this process, sending their own transaction stream and paying the streaming provider again for each corresponding packet. For many users, this exacerbates network congestion on P2P networks and bloates the blockchain, requiring a large number of transactions to be published to the network and recorded in the blockchain (one transaction per user per packet).

[0014] As an alternative, crowdfunding technology can, in principle, be used to enable multiple parties to jointly fund a piece of content by adding inputs to a shared transaction. This means that the number of transactions that need to be published to a P2P network will only expand by data packets or content blocks, rather than by users, thereby alleviating network congestion and blockchain bloat. However, the problem with the existing crowdfunding concept is that it does not provide an integrated mechanism for publishing content to users once the crowdfunding goal is reached.

[0015] This disclosure provides an on-chain integration mechanism for publishing crowdfunding content to users.

[0016] According to one aspect disclosed herein, a computer-implemented method is provided for enabling multiple users to access media content items. The method includes, through a provider of the media content, providing a first transaction, the first transaction comprising: i) one or more outputs, the one or more outputs including at least a first output specifying an amount of digital assets transferred to the provider; and ii) initially, a sum of zero or more inputs, wherein the total amount of digital assets input specified in any output of any source transaction to which the zero or more inputs point is less than the total amount of digital assets output specified by the one or more outputs. The first output of the first transaction includes a locking script specifying a condition that must be satisfied for an unlocking script to unlock the first output. The method further includes receiving 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 corresponding source transaction specifying an amount of digital assets. Once a target is reached, whereby the total amount of inputs to which the inputs of the first transaction point equals or exceeds the output amount, the method includes causing the first transaction and a second transaction to be published to a blockchain network for recording in the blockchain, wherein the second transaction includes an input pointing to the first output of the first transaction and including the unlocking script satisfying the condition. The conditions specified in the locking script require that the unlocking script include a media key that enables the user to access the media content item.

[0017] The first transaction is hosted on the server at least until the goal is achieved, wherein input received from the user is received on the server and added to the first transaction stored on the server (wherein the server herein may refer to any service computer device implemented in one or more physical units in one or more geographic locations).

[0018] For each of the multiple transactions including the target transaction, at least some network nodes are configured to propagate each transaction if it is valid, and at least some nodes are configured to record each transaction in their blockchain copy if it is valid. The validity of the first transaction depends on the total input amount being at least equal to the total output amount. This means that the transaction cannot be valid until sufficient input is collected from users (e.g., Alice, Adam, Agnes, etc.) to satisfy the target. Further, the validity of the second transaction depends on the unlocking script that unlocks the output of the first transaction. This means that if the party performing the method (e.g., Bob) wants to request the output amount, it must publish the unlocking key to the blockchain. Once the key is thus immutably published on a publicly verifiable blockchain, users can retrieve the unlocking key and use it to access relevant data items from off-chain data sources. Optionally, Bob may also send the unlocking key directly to one, some, or all users via a side channel instead of requiring them to retrieve the unlocking key from the blockchain, but the fact that it must be published on the blockchain ensures that users can retrieve it themselves from the blockchain if Bob does not send it to them individually, and therefore Bob cannot cheat the system.

[0019] In embodiments, the method may include repeating the method for each of a plurality of data items, wherein each content item forms a different corresponding item in a sequence of portions of media content. For example, the media content may include text, audio, and / or video content. It may include, for example, an episode of a television program or talk show, a movie, or a series of episodes of a program. In embodiments, the portion may be a data packet of a given episode or standalone program or movie, such as a television program or talk show, streamed in real time to a user. Alternatively, the portion may, for example, be different episodes of a television series.

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

[0021] According to another aspect disclosed herein, a program for performing the method is provided, and / or a computer device programmed to perform a provider's or user's method. Attached Figure Description

[0022] To aid in understanding embodiments of this disclosure and to show how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0023] Figure 1 This is a schematic block diagram illustrating a system for implementing blockchain.

[0024] Figure 2 The illustrations show some examples of transactions that can be recorded in the blockchain.

[0025] Figure 3This is a schematic block diagram of another system for implementing blockchain.

[0026] Figure 4 This is a schematic diagram of a system that uses blockchain to distribute crowdfunding content to multiple users.

[0027] Figure 5 It is a diagram illustrating a set of transactions.

[0028] Figure 6 This is a flowchart illustrating the crowdfunding method and the distribution of media content items to multiple users. Detailed Implementation

[0029] System Overview

[0030] Figure 1 An exemplary system 100 for implementing blockchain 150 is shown. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer's computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or electrically erasable read-only memory, and / or optical media such as optical disc drives.

[0031] Blockchain 150 comprises a series of data blocks 151, with each of the more than 160 nodes in the P2P network maintaining a corresponding copy of blockchain 150. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0032] At least some nodes 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some nodes 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storing a corresponding copy of the same blockchain 150 in its respective storage. A given node 104 can be a forwarding node 104, a storage node 104S, or any combination thereof.

[0033] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, a previous transaction can be any transaction in pool 154 or any block 151. To ensure the validity of the current transaction, the previous transaction 152i does not necessarily need to exist when the current transaction 152j is created or even sent to network 106, but the previous transaction 152i must exist and be valid. Therefore, "previous" in this context refers to an earlier point in the logical sequence connected by pointers, not necessarily the time of creation or sending in the time series. Therefore, the possibility that transactions 152i and 152j were created or sent out of order is not necessarily excluded (see the description of orphaned transactions below). The previous transaction 152i can also be referred to as a preceding or earlier transaction.

[0034] The input to the current transaction 152j also includes the signature of user 103a, whose output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for modification). In some cases, the transaction may also have multiple inputs, aggregating the amounts from multiple outputs of one or more previous transactions and redistributing them to one or more outputs of the current transaction.

[0035] The above can be referred to as an "output-based" transaction protocol, sometimes also called an Unspent Transaction Output (UTXO) protocol (where the output is called a UTXO). The user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special "wallet" application 105 to organize all of the user's UTXO values, which are scattered across many different transactions 152 in the blockchain 151.

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

[0037] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to a node 104 (currently typically a server or data center, but in principle, it could be another user terminal) on the P2P network 106. This node 104 checks the validity of the transaction according to the node protocol applied to each node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i that the new transaction input points to. In some transaction protocols, the condition may be defined at least in part by a custom script contained in the input and / or output. Alternatively, this can be fixed by the node protocol alone, or by a combination thereof. Regardless of the method, if the new transaction 152j is valid, the current node forwards the new transaction to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the node 104 network.

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

[0039] Besides verification, at least some nodes 104M compete to create transaction blocks. At node 104M, new transactions are added to the pool of valid transactions that haven't yet appeared in the block. Then, they compete to assemble a new valid transaction block 152 (151) from transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value such that when the random number is concatenated with transaction pool 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the condition could be that the output of the hash value has a predefined number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs. Therefore, this search can only be performed by brute force, requiring each node 104M to consume significant processing resources to solve the puzzle.

[0040] The first node 104M to solve the puzzle announces its solution on network 106, providing the solution as proof. Other nodes 104 in the network can then easily check the solution (once a hash value is provided, checking if the output of the hash value meets the conditions is relatively simple). Based on each node checking the solution announced by the winner, the transaction pool 154 of the winner who solved the puzzle is then recorded as a new block 151 in blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S. A block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the chain. Proof-of-work helps reduce the risk of double-spending because creating a new block 151 requires significant work, and any block containing double-spending may be rejected by other nodes 104. Therefore, node 104M is incentivized not to include double-spending in its blocks. Once created, block 151 cannot be modified because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes ordering on block 151. Because transaction 152 is recorded in ordered blocks on each of the 104S storage nodes of the P2P network 106, it provides an immutable public ledger of transactions.

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

[0042] Each node 104's memory stores software configured to run on the node 104's processing device to perform its corresponding role and process transactions 152 according to the node protocol. It should be understood that any action taken by node 104 in this document can be performed via software running on the processing device of the corresponding computer. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

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

[0044] Each party 103's computer device 102 includes a corresponding processing means comprising one or more processors, such as one or more central processing units, other accelerator processors, application-specific processors, and / or field-programmable gate arrays. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media like solid-state drives, flash memory or electrically erasable read-only memory, and / or optical media like optical disc drives. The memory on each party 103's computer device 102 stores corresponding instances of at least one client application 105 set to run on the processing means. It should be understood that any action of the given party 103 can be performed by software running on the processing means of the given computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The given party 103's computer device 102 may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0045] The client application or software 105 may initially be made available to any given party 103's computer device 102 via a suitable computer-readable storage medium, such as by downloading from a server, or by being made available on a removable storage device, such as a removable solid-state drive, flash memory key, removable electrically erasable read-only memory, removable disk drive, floppy disk or tape, optical disc (such as CD or DVD ROM), or removable optical drive, etc.

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

[0047] An instance of client application 105 on each computer device 102 is operatively coupled to at least one forwarding node 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query blockchain 150 for any transaction to which the corresponding party 103 is the recipient (or actually inspect other party transactions in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify transaction 152 according to a node protocol, in the case of forwarding node 104F forwarding transaction 152, for propagation throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes to exist within it). All nodes 104 in network 106 use the same node protocol (although they can distinguish and process different transaction subtypes according to the rules of subtypes, and different nodes can also play different roles, thus implementing different corresponding aspects of the protocol).

[0048] As previously described, blockchain 150 includes a series of blocks 151, each block 151 comprising one or more transactions 152 created by the previously discussed proof-of-work process. Each block 151 also includes a block pointer 155 pointing to previously created blocks 151 in the chain, defining the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154 awaiting inclusion in new blocks via the proof-of-work process. Each transaction 152 includes a pointer to the previous transaction, defining the order of the transaction sequence (note: the sequence of transactions 152 can branch). The chain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the chain. One or more original transactions 152 in the earlier chain 150 point to the genesis block 153, not to previous transactions.

[0049] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152j from client application 105 to one of one or more forwarding nodes 104F that it is connected to. For example, this could be a forwarding node 104F that is most recently or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets specific conditions for being "valid," specific examples of which will be described in detail later. In some transaction protocols, the verification conditions can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0050] If the newly received transaction 152j passes the validity test (i.e., is "verified"), any storage node 104S that receives transaction 152j will add the newly verified transaction 152 to pool 154 of the blockchain 150 replica maintained by node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the verified transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0051] Once pool 154, which includes the new transaction 152j, completes its proof-of-work, it will become an immutable part of block 151 in blockchain 150. Each transaction 152 includes pointers to earlier transactions, so the order of transactions is also immutably recorded.

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

[0053] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising 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 is not redeemed). The UTXO specifies the amount of digital asset (a store of value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this 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 original transaction 152.

[0054] Suppose Alice 103a wants to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is marked "Tx1". It retrieves the amount of digital assets locked to Alice in the output 203 of the previous transaction 152j in the sequence, and transfers at least a portion of such amount to Bob. Figure 2 The previous transaction 152j in the pool is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to the next transaction in pool 154. Tx1 can refer to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0055] When Alice creates her new transaction Tx1, or at least when she sends it to network 106, the previous transaction Tx0 may have already been verified and included in blockchain 150. It may already be included in block 151 at this point, or it may still be waiting in pool 154, in which case it will soon be included in new block 151. Alternatively, Tx0 and Tx1 may be created and sent together to network 102, or Tx0 may even be sent after Tx1 if the node protocol allows buffering of “orphaned” transactions. The terms “previous” and “subsequent” as used in the context of transaction ordering in this paper refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can also be replaced by terms such as “early” and “subsequent,” “previous” and “successor,” “previous generation” and “descendant,” or similar terms. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (or "child transactions") that point to a previous transaction (the preceding transaction or "parent transaction") are not verified until the parent transaction is verified. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. According to the node protocol, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0056] One or more outputs 203 of the previous transaction Tx0 include a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script. This locking script defines the conditions that the unlocking script in the subsequent transaction input 202 must meet for the subsequent transaction to verify and successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following condition: the unlocking script in the subsequent transaction input includes the cryptographic signature of the party whose account was locked in the previous transaction.

[0057] A locking script (also known as 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 a "script" (with an uppercase S). The locking script specifies the information required for the spend transaction output 203, such as Alice's signature requirement. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0058] Therefore, in the example shown, UTXO0 in Tx0 output 203 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A Including the public key P in Alice's public-private key pair A Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A This includes Alice's cryptographic signature, which is created by Alice applying the private key from her key pair to a predetermined portion of the data (sometimes referred to as a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

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

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

[0061] Here, "||" indicates concatenation, "<...>" indicates placing data on the stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, using a regular stack, the script can run sequentially instead of being chained. Regardless of the method used, when running together, the script uses Alice's public key P. A (Included in the locking script at the Tx0 output) to verify whether the locking script at the Tx1 input contains the signature Alice used when signing the expected portion of the data. The expected portion of the data itself (“message”) also needs to be included in Tx0 in order to perform this verification. In this embodiment, the signed data comprises the entire Tx0 (therefore, a separate element is needed to plaintext the signed portion of the data, as it already exists).

[0062] Those skilled in the art will be familiar with the details of verification via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), any entity, such as Node 104, capable of verifying the encrypted version of the message must have already signed it by Alice. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thereby enabling any holder of the public key to verify the signature. Therefore, it is important to note that references herein to a specific data fragment, a portion of transaction content, or similar signatures may refer to signing the hash value of that data fragment or portion of transaction content.

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

[0064] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount in a UTXO can be divided among multiple outputs of the next transaction. For example, the amount defined in UTXO0 of Tx0 can be divided among multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob all the amount defined in UTXO0, she can use the remaining portion to make change herself in the second output of Tx1, or pay the other party.

[0065] It should also be noted that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, then the transaction in most of the transaction models is invalid. Therefore, such a transaction will not be propagated or mined into block 151.

[0066] Alice and Bob's digital assets consist of unspent UTXOs locked in any of their transactions 152 within blockchain 150. Therefore, typically, the assets of the given party 103 are dispersed across the UTXOs of various transactions 152 throughout blockchain 150. The total balance of the given party 103 is not defined within blockchain 150. The wallet function of the client application 105 serves to consolidate the different UTXO values ​​locked to the corresponding party and not yet spent in other subsequent transactions. This is achieved by querying any copy of blockchain 150 stored by any storage node 104S, such as the storage node 104S that is most recently or best connected to the corresponding party's computer device 102.

[0067] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, writing [ChecksigP] A ] means [Checksig P A ] = OP_DUP OP_HASH160 <H(P A OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by the 'sig' input. Similarly, OP_RETURN is a scripting language opcode used to create a non-spendable output for a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0068] Signature P A This is a digital signature. In this embodiment, it is based on the elliptic curve digital signature algorithm using secp256k1. A digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input, all of the transaction output, or part of the transaction output. The specific portion of the signed output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the signed output (and thus fixed at the time of signing).

[0069] Locking scripts are sometimes called "scriptPubKey," meaning they include the public key of the party locking the corresponding transaction. Unlocking scripts are sometimes called "scriptSig," meaning they provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0070] Figure 3 A system 100 for implementing blockchain 150 is shown. In addition to additional communication functions, system 100 is connected to… Figure 1 The content shown is essentially the same. The client applications on each of Alice and Bob's computer devices 102a and 120b include additional communication capabilities. That is, this allows Alice 103a to establish a side channel 301 separate from Bob 103b (at the instigation of either party or a third party). Side channel 301 enables data exchange independently of the P2P network. Such communication is sometimes referred to as "off-chain" communication. For example, when exchanging transaction 152 between Alice and Bob, if they do not want to publish the transaction (yet) to the P2P network 106 or mine block 150, they can use this communication until one party chooses to broadcast the transaction to network 106. Such side channel 301 is sometimes referred to, for example, as a "payment channel."

[0071] Side channel 301 can be established via the same packet-switching network 101 as the P2P overlay network 106. Alternatively, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between Alice and Bob's devices 1021, 102b. Generally, side channel 301 as referred to herein can include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e., independently of the P2P overlay network 106). When multiple links are used, the entire bundle or collection of off-chain links can be referred to as side channel 301. Therefore, it is important to note that while Alice and Bob may exchange specific information or data fragments or similar items via side channel 301, this does not necessarily mean that all these data fragments must be sent via the same link or even the same type of network.

[0072] Exemplary definition

[0073] Below are some exemplary definitions that may be used in some implementations. It should be noted that these exemplary definitions are not intended to completely limit all possible implementations, but are merely to help understand specific possible implementations, such as definitions that may be used in some possible implementations of the exemplary use cases described below.

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

[0075] Definition 2: Inputs. The inputs to a transaction form an ordered list. Each entry in this list contains an output point (an identifier for the unspent transaction output) and a scriptSig (unlock script). It may also include a serial number.

[0076] Definition 3: Output. The output of a transaction forms an ordered list. Each entry in this list contains a numerical value (the amount of digital assets expressed in basic units) and a scriptPubKey (locking script).

[0077] Definition 4: Output Point. An output point is uniquely defined by transaction ID (TxID) and index number i. It refers to the i-th entry in the output of transaction TxID, representing the unique position of an unspent transaction output (UTXO). The term "unspent" here means that the output point never appears in any valid subsequent transaction.

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

[0079] Definition 6: scriptPubKey. This refers to a script that locks funds associated with a specific UTXO. Funds can only be unlocked and spent if and only if scriptSig is added to scriptPubKey and the execution of the combined script shows TRUE. If this is not the case, the transaction is invalid and will be rejected. It is called "scriptPubKey" because the script typically contains the hash of the ECDSA public key used for standard transactions.

[0080] In the next definition, if a signed input is referenced, it means that the signature does not include the scriptSig part (see Definition 2).

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

[0082] logo Functional meaning SIGHASH_ALL Sign all inputs and outputs SIGHASH_SINGLE Sign the output and all inputs using the same index. SIGHASH_NONE Sign all inputs, excluding outputs. SIGHASH_ALL|ANYONECANPAY Sign its own inputs and all outputs SIGHASH_SINGLE|ANYONECANPAY Use the same index to sign its own inputs and outputs. SIGHASH_NONE|ANYONECANPAY Sign its own inputs, without outputs.

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

[0084] Definition 8: Blockchain Time Locks. Generally, two types of time locks can be used in transactions: absolute time locks and relative time locks. An absolute time lock specifies a specific point in time; information occurring after that point is considered valid. A relative time lock specifies a time period; information occurring after that time period is considered valid. In both cases, when using blockchain time locks, block height (the number of blocks mined) or elapsed time (e.g., UNIX time) can be used to proxy time.

[0085] Another attribute of blockchain time locks lies in their location and the transactions they apply to. In this sense, they can be divided into two categories: transaction-level time locks, used to lock the entire transaction; and script-level time locks, used to unlock specific outputs. Both categories can be used to implement absolute or relative time locks. The table below summarizes four mechanisms for implementing time locks based on the aforementioned attributes.

[0086]

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

[0088] Definition 10: nSequence. The sequence number (nSequence) represents the transaction version as a message. Modifying a transaction increments the sequence number. The maximum value of nSequence is 2. 32 -1, and typically, the sequence number is set to this maximum value by default to indicate that the transaction is complete. Each input to a transaction defines an nSequence value, which specifies the time period required from when the UTXO referenced by the input is included in a block until the input becomes available as a valid input. However, this feature is usually disabled.

[0089] Definition 11: CheckLockTimeVerify(OP_CLTV). The OP_CHECKLOCKTIMEVERIFY(OP_CLTV) opcode is a script-level absolute time lock that can be used to lock a specific output of a transaction at a specific future time or block height. If the current Unix time or block height referenced in the transaction by the UTXO is less than the Unix time or block height at which the UTXO was created, along with the parameters specified before the OP_CLTV opcode, then the execution of the script for the spent transaction will fail.

[0090] Definition 12: CheckSequenceVerify(OP_CSV). The OP_CHECKSEQUENCEVERIFY(OP_CSV) opcode is a script-level relative time lock that can be used to lock specific outputs of transactions within a specific time period or block number in the future. It is similar to OP_CLTV, except that the parameters provided to OP_CSV represent relative time. If the current Unix time or block height referenced in the UTXO within the transaction is less than the parameter specified before the OP_CSV opcode, then the script execution for the transaction will fail.

[0091] Definition 13: Extensibility. Generally speaking, blockchain transactions may have two main categories of extensibility, both of which allow modification of the transaction content without invalidating the signature provided in the input.

[0092] To illustrate these two categories, let's take the first transaction Tx as an example, which contains an input, a signature in that input, and an output.

[0093] Category 1: Script-level Extensibility. This extensibility leverages the fact that the signature to be checked using the script opcode OP_CHECKSIG does not sign any input script fields in a transaction. This fact allows us to generate a signature on transaction Tx, modify the input script so that transaction Tx′ is not equivalent to Tx, and still view Tx and Tx′ as valid transaction messages signed by the same signature under the blockchain consensus rules.

[0094] Category 2: Input / Output Level Scalability. This scalability relies on the use of SIGHASH flags, rather than SIGHASH ALL used in the transaction. If a transaction Tx has an input signature that uses any of the other five SIGHASH flag combinations, then inputs or outputs can be added to create unequal transactions Tx′, such that both will be considered valid transaction messages under the consensus rules without requiring signature modification.

[0095] On-chain mechanism for publishing content to users

[0096] The following describes an exemplary mechanism for publishing content to multiple users based on inputs added by users to a transaction, a so-called crowdfunding transaction, but with an integrated on-chain mechanism that publishes content to users once the crowdfunding goal is reached. For example, this could serve as a new way to implement multi-party streaming, where each part or "block" of media data in the streaming process has a new crowdfunding transaction.

[0097] The media content is divided into M parts, namely D1, D2...D M M corresponding crowdfunding transactions (preferably in advance) are created and hosted on servers accessible to multiple different users (e.g., the general public). Each of these transactions has an output specifying the amount of digital assets to be paid to the content provider (e.g., Bob) for the corresponding portion of the media data. The locking script in each transaction's output also includes a script that, when a second transaction is requested to redeem that output, the input of that second transaction must include the corresponding secret value S. m This secret value serves as the key for publishing (e.g., decrypting) the corresponding portion of media content. Note that S m It was called a secret only before it was published on Blockchain 150 as part of a second transaction; after that, it was no longer a secret.

[0098] For each segment m = 1...M, each of the N users accesses the crowdfunding transaction hosted on the server via side channel 301 (i.e., off-chain) and extends it by adding inputs. This continues until the fundraising goal is reached; that is, until the inputs point to a total amount that is at least sufficient to cover the output amount (otherwise the transaction will be invalid).

[0099] "Streaming" is like a supplier (such as Bob) secretly sending S in a spending transaction. m Broadcasting to a P2P network is as simple as 106 (a spending transaction redeems the output of a crowdfunding transaction, thus revealing a secret S). m In some embodiments, in addition to publishing on blockchain 150, supplier Bob may also send each secret individually to users directly via side channel 301. Alternatively, if he does not do so, some or all users may also be peers (operating node 104) of the P2P network, in which case they will also receive the secret in the spending transaction when Bob broadcasts the secret to the P2P network. Either of these secret transmissions can be as fast as the information transmission, and therefore should be fast. If neither of these cases is true, once the settlement transaction is mined into block 151, secret S is... m It will still end on Blockchain 150, and some or all users can retrieve it from there. Therefore, supplier Bob cannot simply collect funds without issuing the key S. m To deceive.

[0100] The key S in this article m This can be referred to as a "media key." This allows users who obtain the key to unlock (i.e., access) media data content D hosted on an off-chain data source 401. m The corresponding part. In the embodiment, the media key S m At least a decryption key is included. In this case, the user downloads it to his / her computer 102 and uses the decryption key S. m Decryption allows access to this portion of the media data.

[0101] Key S m There are at least two possible scenarios. Scenario 1: S m It can act as a single public key, allowing all users 103a to directly unlock the corresponding portions of the content. That is, once funds are raised, the content is publicly available to anyone with access to the P2P network 106 (but if no one contributes, the content will not be shown to anyone). However, this could be considered unfair, as it would allow any other public member who has not contributed to also access the content.

[0102] Therefore, scenario 2 is used in the embodiment: S m Configured to enable each user to generate their own individual keys m,1 ...s m,N That is, the corresponding key for each user (n = 1...N) contributing input. In this case, to enable a given user to access content D... m For some parts (e.g., in order for a user to decrypt the content), the user needs to apply their own separate key. m,n The key is based on S m This is generated along with some of the user's personal information. A corresponding individual key is also generated. m,n Therefore, it is bound to the corresponding user, and only that user is allowed to access (e.g., decrypt) the relevant content D. m Examples of how this can be achieved will be discussed later.

[0103] By adding a key (S) to the process m The key is made public when the output of a crowdfunding transaction is spent, enabling the disclosure of secrets on the crowdfunding chain, rather than crowdfunding some off-chain process or event. This facilitates the integration of crowdfunding results into on-chain systems.

[0104] In some embodiments, the disclosed process can be applied to crowdfunding and the release of a single, independent portion of content D. However, as discussed, it can also be used to release a sequence or streaming of portions D, where m = 1...M, each based on a corresponding crowdfunding transaction. The advantage of this is that it increases the granularity of crowdfunding, allowing content to be partially crowdfunded, one portion at a time. For example, if a TV series is divided into episodes, the provider (Bob) can ask people to crowdfund it and release an episode as soon as the crowdfunding is complete. This could be used, for example, by an over-the-top (OTT) video streaming service. This service advertises that it owns the rights to popular series and releases an episode as soon as users crowdfund it. For example, users who actually pay for the crowdfunding transaction can watch the series early.

[0105] Granularity means that each episode can even be broken down into smaller data packets, such as one second at a time or other suitable sizes.

[0106] By replacing "TV series" with lectures, similar technologies can be applied to many other applications, such as online education, lecture series, or radio programs.

[0107] For reference Figures 4 to 6 Exemplary implementations will be discussed in more detail.

[0108] Figure 4 It shows Figure 3 The arrangement is expanded such that corresponding computer devices 102a-1, 102a-2, ..., 102a-N of multiple first users 103a-1, 103a-2...103a-N are operable to connect to Bob's computer device 103b via side channel 301. For illustrative purposes only, the first users are all given different names beginning with "A" herein, such as Alice, Adam, and Agnes. Any content discussed above relating to device 102a of the first party 102a and client 105a is equally applicable. Figure 4 Any one of the devices 102a-1, 102a-2, ..., 102a-N of the first user in the scenario.

[0109] In this exemplary scenario, Bob acts as a media content provider. Bob's computer device 102b is configured as a server. This may include resources of one or more dedicated server units in one or more geographic locations, or one or more user devices acting as servers, or any combination of these. Bob's device 102b also has a client 105b installed on the P2P network 106, as do each of the first user's devices 102a-1, 102a-2...102a-N. Anything discussed above relating to Bob's device 102b and client 105b, as well as the side channel 301, is equally applicable. Figure 4 In this scenario, it is important to note again that the side channel 301 in this paper does not necessarily imply a single link or even a single access technology. Therefore, in the embodiments, regarding... Figure 4 The side channel 301 discussed may represent a set of links between Bob's device 103b and devices 103b-1, 103b-2, ..., 103b-N of different first users 102a, 102a-2, ..., 102a-N, where one or more access technologies are used.

[0110] The system also includes off-chain data source 401 (i.e., a source for storing data not recorded in blockchain 150 and making it available to user 102a). This is related to... Figure 4 Bob's device 102b is described separately, but can constitute part of Bob's device 102b. Alternatively, it can indeed be separate from Bob's device 102b, for example, acting as a provider on behalf of third-party hosted content rather than self-hosted content. Regardless of the approach, off-chain data source 401 stores the media data D for the proposed crowdfunding. m Each of one or more parts. The off-chain data source 401 can access client software 105a-1, 105a-2...105a-N on each first-party device 102a-1, 102a-2, 102a-N via a network. The network accessible to it can be the same network 101 (e.g., the Internet) on which the P2P overlay network 106 is implemented, or a separate network such as a mobile cellular network or an organizational intranet, or any combination of these.

[0111] The following description uses an example where content is divided into multiple parts (m = 1...M). However, it should be understood that the same mechanism can be used to publish even individual data segments. Each segment of media data (content) may include an entire episode of a series of audio or video programs, or a portion of a given drama or standalone program (e.g., a movie). The granularity can even be reduced to the level of individual packets or data packages of a program (e.g., per second or less), with the aim of crowdfunding per packet.

[0112] Figure 6A set of transactions 152 used according to the embodiments disclosed herein is shown. For each data portion D m This set includes multiple zeroth transactions Tx0 and first transactions Tx. 1-m Second transaction Tx 2-m It is important to note that these names are merely convenience labels. They do not necessarily mean that these transactions will be immediately placed sequentially in block 151 or blockchain 150, nor do they mean that the zeroth transaction is the initial transaction in block 151 or blockchain 150. These labels do not necessarily imply any information about the order in which their transactions are sent to network 106. They only refer to a logical sequence where the input of the next transaction points to the output of a transaction. It is worth remembering that in some systems, the parent transaction can be sent to network 106 after its child transactions (in which case, the "orphaned" child transaction will be buffered at one or more nodes 104 for a period of time while waiting for the parent transaction to arrive).

[0113] Each zeroth transaction Tx0 can also be referred to as the source transaction for the purposes of this invention, as it serves as the source of the digital asset amount of the first transaction. For the purposes of this invention, the first transaction Tx... 1-m This can also be called a crowdfunding transaction. It acts as a conditional transfer of digital assets from the source transaction Tx0, thereby providing a portion of the media data D. m The release of [the document / initiative] provides a funding intermediary. The second transaction, Tx... 2-m It can also be called a spending transaction or a target transaction, because the transaction will unlock the conditions in the first transaction and pay the supplier Bob (or a potential beneficiary represented by Bob).

[0114] like Figure 6 As shown, each zeroth or source transaction Tx0 includes at least one output 2030 (e.g., output 0 in the figure) specifying the amount of digital assets, and further includes a locking script that locks the output to a user such as Alice 103a or Adam 103b. This means that the locking script of the source transaction Tx0 requires that the input of any transaction attempting to unlock the output (and thus redeem the amount of digital assets) must contain a cryptographic signature of the user locked in the unlocking script, generated using that user's public key. In this sense, the amount defined in the output of Tx0 can be said to be owned by a user such as Alice or Adam. This output can be called a UTXO. For the purposes of this invention, the output of the previous transaction to which the input of the source transaction Tx0 points is not particularly important (as long as it is sufficient to cover the total output of the source transaction Tx0).

[0115] In this case, the transaction that unlocks the output of the source transaction Tx0 is used for the data part D. m First or crowdfunding transaction Tx 1-m Therefore, Tx 1-mThe final instance will have multiple inputs 2021, each including a pointer to the corresponding output of a source transaction Tx0. 1-m Each output further includes an unlock script configured to unlock the corresponding output pointed to by the Tx0 according to conditions defined in the locking script of that output, which requires at least the signature of the corresponding user. The signature required for the locking script of Tx0 needs to be signed by Tx0. 1- Part of m. In some agreements, a Tx needs to be signed. 1-m The part can be Tx 1-m The settings are defined in the unlock script. For example, this can be set via the SIGHASH flag, which is appended to the signature and is one byte in size, so in terms of data, the unlock script appears as: <Sig P A > <sighashflag><P A Alternatively, the part that needs to be signed can be only the fixed part of Tx 1-m . In either way, the part to be signed typically does not contain the unlocking script itself, and can not include any or all of the inputs of Tx 1-m . This means that the inputs of Tx 1-m are extensible, which allows the user to add inputs 2021.

[0116] The first or intermediate transaction Tx 1-m has at least one output 2031 (e.g. output 0 of Tx 1-m in the figure), which specifies an amount of digital asset to be transferred later, and further includes a locking script that defines the required condition to unlock the output and thus redeem the amount. This condition requires that the unlocking script of a transaction that tries to unlock Tx 1-m (in this case, the second transaction Tx 2-m ) includes Bob's cryptographic signature and a payload that Bob must include in its unlocking script. As will be discussed in more detail later, this payload includes a key S m that enables the user 103a-1...103a-N to publish the piece of content D m . The requirement to include the payload can be imposed by a hash challenge included in the locking script of Tx 1-m . This challenge includes a hash value of the payload (not the payload itself) and a piece of script configured to test (when run on a node 104 together with the unlocking script) whether the hash value of the payload provided in the corresponding unlocking script is equal to the hash value provided in the locking script. The requirement for the signature can be imposed by, e.g., CheckSig discussed earlier. In embodiments, the first condition does not require Alice's signature to be included in the unlocking script of Tx 2-m . The part of Tx 2-m that needs to be signed by Bob can be the setting of the unlocking script of Tx 2-m (e.g. specified by a SIGHASH flag), or can be fixed. In either way, it typically does not contain the unlocking script at least.

[0117] The second target transaction Tx 2-m has at least one input 2022 (e.g. input 0 of Tx 2-m ) that includes a pointer to an output of the above-mentioned Tx 1-m (in the illustrated example, output 0 of Tx 1-m ), and further includes an unlocking script that is configured to unlock the output of Tx 1-m based on satisfying the condition defined in the locking script of Tx 1-m . The second transaction Tx 2-m Having at least one output 2032 (e.g., Tx) 2-m Output 0), which specifies the amount of digital assets to be transferred to Bob. Output 2032 also includes a locking script to lock this to Bob (i.e., requiring further subsequent transactions to include Bob's signature in the unlocking script). In this sense, the target transaction Tx 2-m The output can be said to be owned by Bob. This output can also be called a UTXO.

[0118] Figure 6 It shows the use of, for example, about Figure 5 Describes a set of transaction methods for crowdfunding and publishing data item D. m This method applies to multiple users 103a-1...103a-N. The method is described from the perspective of provider Bob 103b. This can be executed by software 105b running on Bob's device 102b. It should be understood that, according to another aspect, from the perspective of user 103a such as Alice 103a-1, a corresponding method is provided, executed by a client application 105a running on that user's device 102a. It should also be understood that phrases such as "by Alice [or the user]", "by Bob [or the provider]", and "by a third party" in this document can be used as abbreviations for "software 105a running on user 103a's computer device 102a", "software 105b running on provider 103b's computer device 102b", and "software running on a third party's computer device," respectively. Furthermore, it should be noted again that a given party's device may include one or more user devices used by that party, or server resources such as cloud resources used by that party, or any combination of these. This is not necessarily limited to actions performed on a single user device or in a single physical location.

[0119] In step S10, the supplier (Bob) sets Tx 1-m The initial template version, and hosted on his device 102b's server, thus enabling Tx 1-m Available to any user 103a-1…103a-N for extension via side channel 301. As previously described, the provider Bob's server may include any service 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 in one or more geographic locations. The devices 103a-1…103a-N of user 102a-1…102a-N can be accessed via the same network 101 implementing the P2P overlay network (e.g., the Internet), or a separate network (e.g., a mobile cellular network or an intranet within an organization), or any combination of these.

[0120] In one embodiment, Bob can target media data D prior to the first part of the funding in the release or even reception sequence. m All parts of the crowdfunding transaction Tx are designed and stored 1-m The initial template form is given by m = 1...M. However, for simplicity, for media data D... m One of the given parts and its corresponding crowdfunding transaction Tx 1-m The following method is described. It should also be noted that, in alternative embodiments, one, part, or all of the crowdfunding transaction Tx 1-m This can be designed for Bob by a third party and provided to him for hosting on his service device 102b. The following will describe each crowdfunding transaction (i.e., the first transaction) Tx designed by Bob himself. 1-m This description is presented from the perspective of [the provider], but it should be understood that this does not constitute a limitation. Furthermore, it should be understood that the provider "Bob" may actually comprise an organization of more than one person, rather than a single user.

[0121] Tx was originally formed by supplier Bob. 1-m Includes at least one output 2031. This includes the value Xm, which specifies the amount of digital assets he wishes to receive for publishing media content D. m The corresponding part. X m It is possible for all m (i.e., media D) m All parts are the same, or it can also be found in D. m Some or all of them differ. Bob will also release media data D. m The target value T required for the corresponding part m It is stored on its device 102b. In some systems (such as consortium blockchain systems), T m It can be equal to X m .

[0122] Tx 1-m Output 2021 also includes a locking script. The locking script requires an attempt to redeem output 2021 (in this case, Tx). 2-m The unlocking script for the transaction includes information for media content D. m The corresponding part of the secret access key S m (Media key). As mentioned earlier, this requirement can be achieved through hash challenge. That is, the locking script includes a hash of a payload, which includes a media key and a script configured to: hash the payload value contained in the unlock script, compare it with the hash in the locking script, and unlock the output if they match.

[0123] In an embodiment, supplier Bob in its initially formed Tx 1-m The version includes its own input 2021. This input points to the corresponding source transaction Tx locked to Bob. 0-m-B The output. The amount of digital assets specified in this output can be zero or a nominal (negligible) amount (e.g., if the protocol does not allow a zero spendable output amount). Tx 0-m-B The output locking script requires Bob's signature to be included in the unlocking script of the transaction input that is being unlocked, in this case, Bob's Tx. 1-m Input. Therefore, Bob in Tx 1-m The input includes an unlock script, which includes Bob's signed Tx 1-m A portion of the signature, and the public key Bob used to verify his signature.

[0124] The Tx 1-m The purpose of this input may be to provide supplier Bob with a way to sign off on the transaction and thus indicate his approval of it. And / or crowdfunding transaction Tx 1-m It is preferable to have at least one initial input to guarantee (signature) of output 2031. Without any input, the output is loose: anyone can replace it. However, once at least one input 2021 is present to sign output 2031, the output cannot be changed.

[0125] Furthermore, in one embodiment, supplier Bob supplies Tx 1-m The input also provides one or more users 103a-1…103a-N with a method to verify the authenticity of a transaction before adding their own input 2021, thereby providing them with funds. For example, the system may include a database 402 of a trusted third party, which is accessible to one, some, or all of the user devices 102a-1…102a-N. Access is possible through the same network 101 (e.g., the Internet) that implements the P2P overlay network 106, or a separate network such as a mobile cellular network or an intranet, or any combination of these. Database 402 includes a list of public keys of one or more providers recognized by the trusted third party. Therefore, by accessing database 402 and observing Bob's public key listed there (i.e., checking Bob's Tx...), 1-m If they find a value in the input that matches the public key, they can believe that Bob is a legitimate supplier.

[0126] However, the input from supplier Bob is optional. Alternatively, Tx is initially formed by Bob. 1-m No input for 2021 is included.

[0127] In step S20, supplier Bob begins receiving input from one or more users 103a-1...103a-N. Each of these users 103a accesses the crowdfunding transaction Tx on Bob's server 102b via side channel 301. 1-m The current version, and thus the transaction is modified to add her own corresponding input 2021. Each of these added inputs in user 103a-n points to the corresponding source transaction Tx. 0-m-n The output specifies the amount of digital assets locked to the user (103a-n) and includes the locking script corresponding to the output locked to the user. That is, Tx 0-m-n The locking script requires the corresponding input of the unlocking script (in this case, Tx) to unlock the transaction. 1-m This includes the signature of the corresponding user 103a-n. Therefore, the user's signature on Tx 1-m The input includes an unlock script, which includes signing a Tx 1-m A portion of the user's signature and the user's public key used to enable signature verification.

[0128] After receiving one or more inputs from one or more users 103a, then in step S30, supplier Bob checks Tx 1-m Is there currently enough input to satisfy its objective T? m That is, he will refer to the source transaction Tx pointed to by the inputs received so far. 0-m Add the amounts in the output 2030 and check if it is at least equal to the target amount T. m If not, return and continue from step S20.

[0129] Once Tx 0-m The amount pointed to by the input must at least reach the target T. m Supplier Bob then proceeds to step S40, where he will transfer Tx 1-m and the corresponding transaction cost Tx 2-m It was published to network 106 and then to P2P network 106. In other words, it transferred Tx... 1-m and Tx 2-m Each of these transactions is sent to at least one of the forwarding nodes 104F to propagate from there through network 106; each of these transactions is verified at each node 104, mined into block 151, and recorded in a copy of the blockchain 150 maintained by each storage node 104S. Alternatively, he can transfer these transactions (Tx 1-m and Tx 2-m One or both of the transactions are sent to one or a third party in user 103a, so that they can then forward them to network 106. In either case, supplier Bob has thus caused both transactions to be propagated through node 104 of network 106 and publicly recorded in blockchain 150.

[0130] Crowdfunding Transaction Tx 1-m Output 2031 specifies the data portion D m Payment X to Bob m It also includes a locking script. The transaction cost is Tx. 2-m Including the input 2022, which points to Tx 1-m The output includes the locking script. Tx 2-m It includes output 2032, which specifies the amount of digital assets and includes a locking script to lock that amount to Bob.

[0131] Tx 1-m The lock script in the output requires the unlock script for the transaction to be unlocked (in this case, Tx). 2-m This includes the specified payload. For example, as previously mentioned, this requirement can be imposed via a hash challenge in the locking script. The payload includes a function to enable users 103a-1, ..., 103a-N to access (e.g., decrypt) media content D from off-chain data source 401. m The corresponding part of the media key (e.g., decryption key) S m Because of the transaction cost Tx 2-m S must be included m To enable supplier Bob to request payment, it means that when Bob requests payment, it must be made publicly visible on Blockchain150.

[0132] Each user 103a-1, ..., 103a-N can therefore check blockchain 150 to retrieve the media key S. m Then, they can use the media key S m Obtain and use the corresponding media data portion D from off-chain data source 401. m .

[0133] In some cases, in addition to publishing on blockchain 150, supplier Bob can optionally transmit the media key S via side channel 301. m Send to one, multiple, or all users 103a. And / or if one or more of users 103a are also peers 104 of the P2P network 106, they may propagate the consumer transaction Tx through the network 106. 2-m Receive S m As another possibility, the future API could allow users to query pool 154, enabling them to observe data in pending transactions before mining. However, regardless of the medium through which user 103a receives the data, the key is that supplier Bob cannot prevent the media key S. m It is available to user 103a through at least one channel (blockchain 150). Therefore, Bob cannot deceive by simply collecting payments without publishing the corresponding media content.

[0134] In the embodiment, the media key S m This includes at least the decryption key. In this case, user 103a queries off-chain data source 401 to download a portion of the media data D. m To his / her corresponding computer device 102a, and then apply the decryption key to unlock the media data portion D. m And thus obtain a (plaintext) copy of the data on its corresponding computer device 102a. Additionally / or, the media key S m This can include downloading media data D m The first part requires a password. In this case, the user will enter the password S. m Submit to an off-chain data source 401, and in response, allow the media data portion D to be transferred. m Download or stream to its corresponding computer device 102a. In some embodiments, the media key S m It can include encryption keys and passwords, and access can be achieved by combining both methods.

[0135] Some implementations may use only a single password or a common decryption key, allowing everyone to access the data elsewhere. This can be implemented directly, but may be undesirable because if the code is leaked, it could allow unpaid users to access the data. Therefore, a more secure option is a single public key approach using a group-based public key encryption scheme (where the public key can be generated using any chosen group-based public key encryption scheme, preferably ECDSA). The funders have already provided their public key, i.e., the PK, in their input. i The organizer creates a private key V and calculates S. m =V·G, and S m,i =V·PK i S i This is the shared key between the organizer and funder i. This value can be hashed to create a key for a symmetric encryption scheme. The organizer uses the shared key to encrypt the data for each funder i. This encrypted data is preferably communicated off-chain. So far, no funder has been able to decrypt the data.

[0136] In the unlock script, the organizers then released S m Then, each contributor will be able to calculate the shared key using their own private key and derive the decryption key as needed. The downside is that the public must trust everything in the locking script (which could be S...). m (the hash value), which would force organizers to disclose S. m For example, this might not pose a problem for well-known OTT providers. Furthermore, in embodiments, the scheme can be combined with a trusted database 402 to increase trust.

[0137] Therefore, in this embodiment, in order to access media data D m For each user (103a-n), a separate media key (e.g., decryption key) bound to that specific user is required. m,n In this case, supplier Bob is based on the inclusion of Tx 1-m Its corresponding input 2021 uses the public key of each user 103a-n to calculate the Tx 1-m Media key S m When each user 103a-n receives S m At that time, they calculated their own individual media keys. m,n And using this key, access media content D from off-chain source 401. m The corresponding part. Each user's individual media key is unique to that user (where "unique" in this context means that the probability of a collision is at least close to zero).

[0138] This can be achieved by using one of the various available key-sharing techniques known in the art. Each contributing user 103a-1...103a-N will have their Tx 1-m The input reveals their respective public keys. Supplier Bob can use the public keys, along with key-sharing technology, to create a shared key with each contributor. Bob can then use the shared key as a symmetric encryption technique to encrypt portions of the media data D. m And send it to the target audience (funders 103a-1...103a-N). This may include sending it itself if data source 401 is implemented on provider Bob's device 102b, or triggering it to send it from a third party if data source 401 is implemented elsewhere. In either case, each funder 103a-n will effectively receive the media data portion D. m A custom encrypted version. When Bob revealed S on the chain... m At that time, each individual user 103a-n will be able to derive the shared key s m,n It is important to note that each will have a different shared key (here, "shared" means shared between the provider Bob and the corresponding user 103a-n, not between different users 103a-1...102a-N). Each shared key is unique, provided the public key used in the input is unique.

[0139] The following is an exemplary implementation based on standard Diffie-Hellman key exchange:

[0140] I. Alice provided the funding and her public key, PK_A, in her input;

[0141] II. The locking script contains a hash check: H(PK_B), meaning that Bob must reveal PK_B when unlocking;

[0142] III. Bob's Calculation (sk) B ·PK A And use it as a symmetric encryption key to encrypt only Alice's data;

[0143] IV. Once Bob reveals PK_B, Alice will be able to calculate (sk) A ·PK B To compute the same symmetric key;

[0144] The same applies to other contributing users such as Adam and Agnes. It should be noted that this is just one of many possible implementations using standard key-sharing technology.

[0145] As an example scenario, suppose Bob wants to play a video. The video could be a lecture, a tutorial, or a regular event.

[0146] In this scenario, it can be assumed that Bob knows the exact time he wants to start broadcasting. His broadcast also has a pre-set price. The video data will be encrypted block by block and transmitted off-chain. Partial secret value s m It will be generated by Bob and exchanged on the chain for each data block.

[0147] The participants will then derive the complete key to decrypt the data.

[0148] Payment channel initialization - TX 1-m

[0149] Lock time: 60

[0150] Input 0:

[0151] Bob's own UXTO, worth little.

[0152] Bob's signature and SIGHASH_SINGLE|ANYONECANPAY

[0153] Output 0:

[0154] • Locking conditions:

[0155] If Bob provides s m If his signature is given, then output can be requested.

[0156] • Value: 100,000 units

[0157] Alice joins the channel - TX 1-m-A1

[0158] Lock time: 60

[0159] Input 0:

[0160] Bob's own UXTO, worth little.

[0161] Bob's signature and SIGHASH_SINGLE|ANYONECANPAY

[0162] Input 1:

[0163] Alice's UTXO

[0164] Alice's signature and SIGHASH_ALL|ANYONECANPAY

[0165] Output 0:

[0166] • Locking conditions:

[0167] If Bob provides s m If his signature is given, then output can be requested.

[0168] • Value: 100,000 units

[0169] Adam joins the passage after Alice - TX 1-m-A1-A2

[0170] Lock time: 60

[0171] Input 0:

[0172] Bob's own UXTO, worth little.

[0173] Bob's signature and SIGHASH_SINGLE|ANYONECANPAY

[0174] Input 1:

[0175] Alice's UTXO

[0176] Alice's signature and SIGHASH_ALL|ANYONECANPAY

[0177] Input 2:

[0178] Adam's UTXO

[0179] Adam's signature and SIGHASH_ALL|ANYONECANPAY

[0180] Output 0:

[0181] • Locking conditions:

[0182] If Bob provides s m If his signature is given, then output can be requested.

[0183] • Value: 100,000 units

[0184] This process can continue until the input value covers the output value or the time lock expires.

[0185] Bob could deceive people through false advertising of his event. However, it is possible to require a publicly verifiable source linking the public key to the event. The public key could be the ECDSA public key required in input 0 of TX1. Therefore, interested participants could determine whether TX1 is genuine.

[0186] If there isn't enough input and Bob still wants to continue, he can fill in the price difference himself.

[0187] If Bob is more interested than he anticipated, he can create another trade or allow participants to copy the output from TX1 and create their own new trades.

[0188] Each participant 103a is identified by the public key in their input 2021. This public key will be used to calculate a custom key to encrypt data. When Charlie reveals... m At that time, participants will be able to compute the key to decrypt the data D they received. m .

[0189] To continue viewing the content, participant 103a only needs to follow the subsequent transactions and fill in input 2021.

[0190] As shown above, for security reasons, the output must be locked with a signature such as an ECDSA signature. Therefore, the output cannot be modified. That is, neither Bob nor Alice (or any other user) can add their changed addresses to the output. Therefore, Alice or Bob must ensure that their UXTO provides the exact amount they wish to pay.

[0191] It should be understood that the above embodiments are described by way of example only. More generally, a method, program, apparatus, or set of transactions can be provided according to any of the following statements. It should be understood that, except for individual statements, all statements define optional characteristics.

[0192] Statement 1: According to one aspect of the disclosure herein, a computer-implemented method is provided that enables multiple users to access media content items, the method comprising, through a provider of the media content: providing a first transaction, the first transaction comprising: i) one or more outputs, the one or more outputs including at least a first output, the first output specifying an amount of digital assets transferred to the provider; and ii) initially, a summation of zero or more inputs, wherein the total amount of digital assets input specified in any output of any source transaction to which the zero or more inputs point is less than the total amount of digital assets output specified by one or more outputs, and wherein the first output of the first transaction includes a locking script specifying a decryption... The locking script unlocks the first output under certain conditions; it receives input from each of the plurality of users via a side channel and adds each received input to the first transaction, each received input pointing to the output of the corresponding source transaction for a specified amount of digital assets; and once the target is reached, the total amount of inputs pointed to by the inputs of the first transaction equals or exceeds the output amount, thereby causing the first transaction and the second transaction to be published to the blockchain network for recording in the blockchain, wherein the second transaction includes an input pointing to the first output of the first transaction and includes an unlocking script that satisfies the conditions; wherein the conditions specified by the locking script require the unlocking script to include a media key, the media key enabling the user to access media content items.

[0193] Statement 2: In an embodiment, the method described in statement 1 may be provided, wherein the objective includes: a total input amount that exceeds a total output amount.

[0194] Statement 3: In an embodiment, the method according to statement 1 or 2 may be provided, comprising repeating the method for each of a plurality of data items, wherein each content item forms a different corresponding item in a sequence of portions of media content.

[0195] Statement 4: In an embodiment, the method described in statement 3 may be provided, wherein the portion is a data packet of a given episode or standalone program or movie that is streamed to a user in real time.

[0196] Statement 5: In an embodiment, the method described in statement 3 may be provided, wherein the portion is a different episode of a TV series.

[0197] Statement 6: In an embodiment, the method described in any of the preceding statements may be provided, wherein the indications associated with the first transaction are listed in a database operated independently of the provider and the user by a third party, thereby enabling the user to verify that the first transaction is a legitimate medium for obtaining the media key.

[0198] Statement 7: In an embodiment, the method described in any of the preceding statements may be provided, wherein zero or more initial inputs include at least one initial input contained by the supplier, the initial inputs including an unlocking script for unlocking the output of the corresponding source transaction, the unlocking script in the supplier's inputs including the supplier's public key and the supplier's signature, the signature being formed using the supplier's private key corresponding to the public key.

[0199] Statement 8: In an embodiment, the method described in statements 6 and 7 may be provided, wherein the instruction includes a copy of the content provider's public key, thereby enabling a user to perform the verification by comparing the public key in the provider's initial input unlock script with a copy of the public key held in the database.

[0200] Statement 9: In an embodiment, the method described in any of the foregoing statements may include, after receiving multiple inputs from the user but before such inputs are sufficient to achieve the goal, the supplier adding further inputs to at least compensate for the discrepancies.

[0201] Statement 10: In an embodiment, the method described in any of the preceding statements may include: in response to receiving an excessive input from a user indicating an amount of digital assets greater than required to satisfy a target: creating a new instance of the first transaction and adding the excessive input to the new instance of the first transaction.

[0202] Statement 11: In an embodiment, the method described in any of the preceding statements may be provided, wherein the media key includes a decryption key, enabling a user to perform the access to the media content item by at least decrypting the media content item using the decryption key.

[0203] Statement 12: In an embodiment, the method described in any of the preceding statements may be provided, wherein the media key is configured to be able to compute a separate media key by each of the plurality of users, thereby enabling only the user providing the input to access the media content item.

[0204] Statement 13: In an embodiment, the method described in statements 11 and 12 may be provided, wherein each individual media key includes a separate decryption key.

[0205] Statement 14: In an embodiment, the method described in any of the preceding statements may be provided, wherein: each of the user's inputs includes a corresponding unlocking script to unlock the output of the corresponding source transaction, the corresponding unlocking script including the user's corresponding public key and the user's corresponding signature, the user's corresponding signature being formed using the user's private key.

[0206] Statement 15: i In an embodiment, the method described when statement 14 is subordinate to statement 12 or 13 may be provided, wherein each user’s individual media key is generated based on the user’s corresponding public key obtained from input received from that user.

[0207] Statement 16: According to another aspect disclosed herein, a computer program contained on a computer-readable storage medium is provided, configured to perform the method described in any one of statements 1 to 15 when run on a provider's computer device.

[0208] Statement 17: According to another aspect disclosed herein, a provider's computer device is provided, comprising: a memory including one or more memory cells, and a processing means including one or more processing units; wherein the memory stores code configured to run on the processing means, the code being configured to execute the method described in any one of statements 1 to 15 when run on the processing means.

[0209] Statement 18: According to another aspect disclosed herein, a method is provided for accessing media content items available in an off-chain data source, the method comprising, by a user: accessing a server hosting a provider of a first transaction, the first transaction comprising: i) one or more outputs, the one or more outputs including at least a first output specifying an amount of digital assets transferred to the provider; and ii) initially, a sum of zero or more inputs, wherein the total amount of digital assets input specified in any output of any source transaction to which the zero or more inputs point is less than the total amount of digital assets output specified by one or more outputs, and wherein the first output of the first transaction includes a locking script specifying an unlocking script to decrypt... The lock requires the first output to meet certain conditions; and at least one of multiple inputs from multiple users is sent to the server via a side channel to be added to the first transaction, each input pointing to the output of a corresponding source transaction for a specified amount of digital assets, thereby enabling the supplier; once the target is reached, the total amount of inputs pointed to by the inputs of the first transaction is equal to or exceeds the output amount, causing the first and second transactions to be published to the blockchain network for recording in the blockchain, wherein the second transaction includes an input pointing to the first output of the first transaction and includes an unlocking script that satisfies the conditions; wherein the conditions specified by the locking script require the unlocking script to include a media key; wherein the method further includes unlocking media content items using the media key.

[0210] Statement 19: According to another aspect disclosed herein, a computer program contained on a computer-readable storage medium is provided, configured to execute the method described in statement 18 when run on a user's computer device.

[0211] Statement 20: According to another aspect disclosed herein, a user's computer device is provided, comprising: a memory including one or more memory cells; and a processing apparatus including one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute the method described in statement 18 when run on the processing apparatus.

[0212] Statement 21: According to another aspect disclosed herein, a set of transactions for recording in a blockchain is provided, the set comprising: a first transaction contained on a computer-readable data medium or medium, the first transaction comprising: i) one or more outputs, the one or more outputs including at least a first output, the first output specifying an amount of digital assets transferred to a supplier; and ii) multiple inputs from multiple different users, each input pointing to an output of a corresponding source transaction specifying an amount of digital assets, wherein the total amount of digital assets input to which the inputs of the first transaction point is equal to or exceeds the total amount of outputs specified by the one or more outputs, and wherein the first output of the first transaction includes a locking script specifying a condition that an unlocking script must satisfy to unlock the first output; and a second transaction, the second transaction including inputs pointing to the first output of the first transaction, the inputs of the second transaction including an unlocking script satisfying the conditions, wherein the conditions specified by the locking script require the unlocking script to include a media key, the media key enabling access to media content items stored in an off-chain data source.

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

Claims

1. A computer-implemented method of enabling a plurality of users to access a media content item, the method being performed by a supplier of the media content, the supplier being a party other than the plurality of users, the method comprising: providing, on an off-chain data source, a first transaction to the plurality of users, the first transaction comprising: i) one or more outputs, the one or more outputs comprising at least a first output specifying an amount of a digital asset to be transferred to the supplier; and ii) initially, a sum of zero or more inputs, wherein a total input amount of digital asset specified in any output of any source transaction to which the zero or more inputs point is less than a total output amount of digital asset specified by the one or more outputs, and wherein the first output of the first transaction comprises a locking script specifying a condition to be satisfied by an unlocking script for the first output to be unlocked; after the providing, receiving, through a side channel, an input from each of the plurality of users, 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 digital asset; checking whether a target has been reached, whereby a total input amount of the inputs of the first transaction point to is equal to or exceeds the output amount; and in response to checking that the target has been reached, causing the first transaction and a second transaction to be published to a blockchain network for recording in a blockchain, wherein the second transaction comprises an input pointing to the first output of the first transaction and comprising the unlocking script satisfying the condition; wherein the condition specified by the locking script requires the unlocking script to comprise a media key, the media key enabling a user to access the media content item. the target comprises a total input amount that exceeds the total output amount.

2. The method of claim 1, wherein, each content item forms a different respective item in a sequence of parts of the media content.

3. The method of claim 1, comprising repeating the method for each of a plurality of data items, wherein, the parts are data packets of a given episode or standalone programme or movie streamed in real time to the users.

4. The method of claim 3, wherein, the parts are different episodes of a serial.

5. The method of claim 3, wherein, an indication relating to the first transaction is listed in a database operated by a third party independent of the supplier and users, thereby enabling a user to verify that the first transaction is a legitimate vehicle for obtaining the media key.

6. The method of claim 1, wherein, the zero or more initial inputs comprise at least one initial input included by the supplier, the initial input comprising an unlocking script unlocking an output of a respective source transaction, the unlocking script in the input of the supplier comprising a public key of the supplier and a signature of the supplier, the signature being formed using a private key of the supplier corresponding to the public key.

7. The method of claim 1, wherein, 8. The method of claim 7, wherein, an indication relating to the first transaction is listed in a database operated by a third party independent of the supplier and users, thereby enabling a user to verify that the first transaction is a legitimate vehicle for obtaining the media key; ​ The indication comprises a copy of the public key of the content provider, thereby enabling the user to perform the verification by comparing the public key in the unlocking script of the provider's initial input with the copy of the public key held in the database.

9. The method of claim 1, comprising the provider adding further input to at least make up for the difference after receiving a plurality of inputs from the user but before the target has been reached.

10. The method of claim 1, comprising in response to receiving an excess input from the user pointing to a larger amount of the digital asset than required to meet the target: creating a new instance of the first transaction, and adding the excess input to the new instance of the first transaction.

11. The method of claim 1, wherein, The media key comprises a decryption key, enabling the user to perform the access to the media content item at least by decrypting the media content item using the decryption key.

12. The method of claim 1, wherein, The media key is configured to enable computation of an individual media key by each of the plurality of users, thereby enabling only the user providing the input to access the media content item.

13. The method of claim 12, wherein, The media key comprises a decryption key, enabling the user to perform the access to the media content item at least by decrypting the media content item using the decryption key; Each individual media key comprises an individual decryption key.

14. The method of claim 1, wherein: Each of the user's inputs comprises a respective unlocking script to unlock an output of the respective source transaction, the respective unlocking script comprising a respective public key of the user and a respective signature of the user, the respective signature of the user being formed using a private key of the user.

15. The method of claim 14, wherein: The media key is configured to enable computation of an individual media key by each of the plurality of users, thereby enabling only the user providing the input to access the media content item; The individual media key of each user is generated based on the respective public key of the user taken from the input received from that user.

16. A computer program product embodied on a computer readable storage medium configured to perform the method of any one of claims 1 to 15 when run on a computer device of the provider.

17. A computer device of a provider, comprising: a memory, the memory comprising one or more memory units, and a processing apparatus, the processing apparatus comprising one or more processing units; wherein the memory stores code arranged to run on the processing apparatus, the code being configured to perform the method of any one of claims 1 to 15 when run on the processing apparatus.

18. A method of accessing a media content item available in an off-chain data source, the method comprising by a user: accessing a server hosting a supplier of a first transaction, the first transaction comprising: i) one or more outputs, the one or more outputs comprising at least a first output, the first output specifying an amount of a digital asset to transfer to the provider; and ii) initially, a sum of zero or more inputs, wherein any total input amount of a digital asset specified in any output of any source transaction to which the zero or more inputs point is less than a total output amount of a digital asset specified by the one or more outputs, and wherein the first output of the first transaction comprises a locking script specifying a condition that must be satisfied by an unlocking script to unlock the first output; and after the accessing the server, sending at least one of the plurality of inputs sent by a plurality of users to the server through a side channel to add to the first transaction; the provider being a party other than the plurality of users; wherein each input points to an output of a respective source transaction specifying the amount of the digital asset, thereby enabling the provider; once a target is reached whereby the 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 to a blockchain network for recordation in a blockchain, wherein the second transaction comprises an input pointing to the first output of the first transaction and comprising the unlocking script satisfying the condition; wherein the condition specified by the locking script requires the unlocking script to comprise a media key; and wherein the method further comprises unlocking the media content item using the media key.

19. A computer program product embodied on a computer readable storage medium configured to perform the method of claim 18 when run on a computer device of the user.

20. A computer device of a user comprising: a memory comprising one or more memory units, and a processing apparatus comprising one or more processing units; wherein the memory stores code arranged to run on the processing apparatus, the code being configured to perform the method of claim 18 when run on the processing apparatus.

21. A computer readable data medium comprising a set of transactions for recordation in a blockchain, the set of transactions comprising: a first transaction comprising: i) one or more outputs, the one or more outputs comprising at least a first output specifying an amount of a digital asset to transfer to a provider; 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 asset, wherein a total input amount of the digital asset pointed to by the inputs of the first transaction equals or exceeds a total output amount specified by the one or more outputs, and wherein the first output of the first transaction comprises a locking script specifying a condition that must be satisfied by an unlocking script to unlock the first output; and a second transaction comprising an input pointing to the first output of the first transaction, the input of the second transaction comprising an unlocking script satisfying the condition, wherein the condition specified by the locking script requires the unlocking script to comprise a media key enabling access to a media content item stored in an off-chain data source.

Images