Sharing data via blockchain transactions

Abstract

To provide a method and the like related to the use of transactions in a blockchain for recording and communicating additional data content such as documents or images.SOLUTION: According to a first aspect of the present disclosure, there is provided a method for accessing one or more destination transactions stored on a blockchain. The method includes selecting one or more hyperlinks that link to the destination transactions. According to a second aspect of the present disclosure, there is provided a request-response protocol for requesting access to data from destination transactions.SELECTED DRAWING: Figure 6A

Description

[Technical Field]

[0001] The present disclosure relates to the use of transactions in a blockchain to record and communicate additional data content, such as documents or images. [Background technology]

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

[0003] Each node in the network can have any one, two, or all three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions through the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own copies of mined blocks in the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes of the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to participate in the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or mined into blocks. Assuming the transaction is verified and thereby accepted into the blockchain, the transaction (including any user data) therefore remains stored in each node of the P2P network as an immutable public record.

[0004] Miners who successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "generation transaction," that generates a new amount of digital asset. Proof-of-work incentivizes miners not to cheat the system by including double-spend transactions in their blocks, because mining a block requires a significant amount of computational resources and because blocks containing double-spend attempts may not be accepted by other nodes.

[0005] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element, sometimes called a UTXO ("unspent transaction output"), that specifies the amount of a digital asset. The output may further include a locking script that specifies the conditions for redeeming the output. Each input includes a pointer to such an output in a preceding transaction and may further include an unlocking script for unlocking the pointed-to output's locking script. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input that includes a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

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

[0007] An alternative type of transaction model is the account-based model, where each transaction transfers by referencing absolute account balances, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of all accounts is stored and constantly updated by miners separate from the blockchain.

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

[0009] As a given blockchain becomes more popular and more resources are stored on-chain, it is rivaling the World Wide Web as a framework for storing, publishing, and securely communicating resources such as text, images, and audio. For example, the so-called Metanet is one such framework implemented by blockchain.

[0010] However, as blockchains grow and are increasingly used as a means for storing and transmitting content, it is also becoming increasingly difficult to discover desired resources on the chain, which has the potential to hinder the use of blockchain-based systems as a medium for communicating content.

[0011] To address this, according to one aspect disclosed herein, there is provided a method implemented by a computing device of a consumer party, the method comprising: a) accessing at least a first document that includes one or more hyperlinks, each hyperlink including a respective identifier of a respective piece of anchor content and a respective destination associated with the respective anchor content; b) rendering content of at least a portion of the first document through a user output device of the computing device of the consumer party, the rendering including rendering anchor content of each of one or more of the hyperlinks; c) receiving user input via a user input device of the consumer party's computing device selecting one of the hyperlinks by selecting a respective anchor content from among the rendered content; d) in response to the user input, automatically accessing data from the associated destinations based on respective identifiers included in the first document; Including, A method is provided wherein a destination of at least each of the selected hyperlinks includes a destination transaction in a blockchain maintained across at least some nodes of a blockchain network, and wherein accessing the data includes inspecting the destination transaction in the blockchain via the blockchain network.

[0012] For example, the first document may include a list of respective hyperlinks to different destination transactions. The first document may be a hypertext document, written in a markup language such as HTML, but augmented with additional types of tags that link transactions. An item of data within one or more of the destination transactions may itself contain one or more further documents, such as one or more further hypertext documents that may contain one or more further onward hyperlinks.

[0013] The first document itself may be stored in another source transaction on the blockchain. Alternatively, the first document may be a web page or document such as a word processing document, email, spreadsheet, slideshow, etc. stored locally on the consumer party's computing device or on a third-party server.

[0014] In an output-based model, documents or other such data content may be stored in the unavailable outputs of their respective documents, for example outputs that are made unavailable by OP_RETURN.

[0015] Alternatively or additionally, it may be desirable to provide a mechanism for integrating payment with data transfer in a manner that ensures that the provider party receives payment and the consumer party receives the data.

[0016] Thus, according to another aspect of the present disclosure, there is provided a method for a consumer party to access data from a provider party, the data being stored in an encrypted form in a first transaction on a blockchain that requires an access key to decrypt the data, the method comprising: i) communicating to the provider party a second transaction for recording on the blockchain, the second transaction specifying a payment for the data and further including an identifier of the first transaction and a signal indicating a request for the data; and in response to the second party broadcasting a third transaction for recording on the blockchain, the third transaction including an encrypted password; ii) examining the blockchain to retrieve the encrypted password from the third transaction, the password being encrypted based on a shared secret between the consumer party and the provider party, and the access key being a first predetermined function of the password; iii) decrypting the received password based on the shared secret, determining the access key by applying the predetermined function to the decrypted password, and decrypting the data based on the determined access key; The data is included in the second transaction along with a message authentication code that is a second predetermined function of the password, the second predetermined function also being a function of the data. iv) calculating the message authentication code based on the decrypted data and the determined password, and comparing the calculated message authentication code with the message authentication code included in the first transaction to authenticate the data.

[0017] This may be used together with the first aspect or separately. [Brief explanation of the drawings]

[0018] To facilitate an understanding of embodiments of the present disclosure, and to show how such embodiments may be put into effect, reference will now be made, by way of example only, to the accompanying drawings in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 shows a schematic diagram of some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] FIG. 2 is a schematic block diagram of a client application. [Figure 5] 5 is a simplified simulated representation of an exemplary user interface presented by the client application of FIG. 4, according to embodiments disclosed herein. [Figure 6A] 1 illustrates a schematic diagram of an exemplary set of transactions according to embodiments disclosed herein. [Figure 6B] 1 illustrates a schematic diagram of an exemplary set of transactions according to embodiments disclosed herein. [Figure 7] 1 is a flowchart of a method for providing a session key according to embodiments disclosed herein. [Figure 8] FIG. 1 is a schematic block diagram illustrating a hypertext transfer protocol, according to embodiments disclosed herein. [Figure 9] 1 illustrates the structure of an exemplary pair of request and response transactions according to embodiments disclosed herein. [Figure 10] 1 is a flowchart of a method for storing encrypted data in a blockchain, according to embodiments disclosed herein. [Figure 11] 1 is a flowchart illustrating an example of a data exchange procedure according to embodiments disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0019] Blockchains offer a decentralized, tamper-resistant alternative to traditional database servers. However, as block capacities increase to accommodate more data storage, a data retrieval system is desired to efficiently access information stored on the blockchain. Traditionally, the only way to access information used on a blockchain is by having a specific transaction reference or by searching the entire blockchain (currently 168 GB for one common blockchain and projected to grow rapidly with increasing block sizes). More recently, methods for organizing data on the blockchain have been proposed as part of the Metanet. Other solutions have also been proposed that allow for querying data stored on the blockchain, including bitDB and the B: / / bitcoin data protocol. However, more tools are desirable to assist in finding relevant data on the chain.

[0020] Today, the World Wide Web (WWW) makes it possible to navigate the Internet and retrieve information efficiently through continuous links between documents (web pages). The standard protocol for linking such information, the Hypertext Transfer Protocol (HTTP), uses hyperlinks (references to data) to establish connections between pages in a database or server. A user makes a request to a server by clicking on a hyperlink, and the server returns the requested information, which is displayed to the user as hypertext (text with hyperlinks).

[0021] The following embodiments provide a protocol for retrieving and displaying encrypted data from organized, linked data stored on a blockchain. Many files can be linked in a series of domain redirects and stored in OP_RETURN data (and verified by miners, if necessary). A smart wallet can decrypt and decompress the data for presentation to a user. For example, embodiments may utilize the speed and efficiency of an XOR encryption scheme for encryption and decryption. In embodiments, the Lempel-Ziv Markov Chain (LZM) compression algorithm, or its derivatives, or other compression techniques may be integrated to accommodate different compression speed requirements. In embodiments, the XZ algorithm may be used for streaming data that can be linked and seeded from LZM links. These can also set peer seed data for P2P file sharing for large files (e.g., multimedia files), streams, or messages.

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

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

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

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

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

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

[0028] As part of the account-based transaction model, another type of transaction protocol is sometimes called an "account-based" protocol. In an account-based system, each transaction transfers by referencing an absolute account balance, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in a series of past transactions. The current state of every account is stored and constantly updated by miners separate from the blockchain. In such a system, transactions are ordered using an account's sequential transaction record (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign a transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

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

[0030] In an output-based model, the definition of whether a given output (e.g., a UTXO) is spent is whether it has already been validly redeemed by an input in another onward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to spend or redeem has not yet been consumed / redeemed by another valid transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded on the blockchain. This prevents double-spending, where a payer attempts to spend the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single, defined state at a time.

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

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

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

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

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

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

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

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

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

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

[0041] NOTE: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in two or more different application suites, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

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

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

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

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

[0046] Once a miner node 104M enters the pool 154 within a copy of the blockchain 150 maintained by one or more storage nodes 104, it starts competing to solve the proof-of-work puzzle for the latest version of the pool 154 that includes the new transaction 152 (other miners 104M are still trying to solve the puzzle based on an older view of the pool 154, but whoever gets there first defines where the next new block 151 ends and a new pool 154 starts, and ultimately someone solves a part of the puzzle for the pool 154 that includes Alice's transaction 152j). Once proof-of-work is done for the pool 154 that includes the new transaction 152j, it becomes part of one of the blocks 151 within the blockchain 150. Since each transaction 152 includes a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0047] Different nodes 104 may first receive different instances of a given transaction, and thus may have conflicting views as to which instance is "valid" before one instance is mined into the block 150, at which point all nodes 104 agree that only the mined instance is the valid instance. If a node 104 accepts one instance as valid and then discovers that a second instance is recorded in the blockchain 150, the node 104 must accept this and discard the previously accepted but not yet mined instance (i.e., treat it as invalid).

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

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

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

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

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

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

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

[0055] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts.

number

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

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

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

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

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

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

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

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

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

[0065] <Optional Side Channel> FIG. 3 illustrates a further system 100 for implementing a blockchain 150. The system 100 is substantially the same as that described in connection with FIG. 1, except that additional communication functionality is included. Client applications residing on each of Alice's and Bob's computing devices 102a, 102b each include the additional communication functionality. That is, it allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the solicitation of either party or a third party). The side channel 301 allows for the exchange of data separately from the P2P network. Such communication is sometimes referred to as "off-chain." For example, it may be used to exchange transactions 152 between Alice and Bob without the transaction being published to the P2P network 106 or on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

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

[0067] <Client software> 4 illustrates an exemplary implementation of a client application 105 for implementing embodiments of the disclosed techniques. The client application 105 includes a transaction engine 404 and a user interface (UI) layer 401. The transaction engine 404 is configured to implement the underlying transaction-related functionality of the client 105, such as forming transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or submitting transactions to be propagated through the P2P network 106, according to the techniques described above and discussed in detail below. Furthermore, according to embodiments disclosed herein, the transaction engine 401 of at least Bob's client 105b (and possibly other clients) may further include any one or more of the following functional modules: a hyperdocument engine 402, a data transfer engine 403, and / or a program launcher 405. The hyperdocument engine 402, the data transfer engine 403, and the program launcher 405 may together form a hypertext SPV (simple payment verification) engine 406. The entire client application 105 may be described as an SPV wallet, or referred to herein as a hypertext SPV wallet. The functionality of these various modules will be discussed in more detail shortly.

[0068] The UI layer 401 is configured to render a user interface via user input / output (I / O) means of each user computing device 102, including outputting information to each user 103 by user output means of the device 102 and receiving input from each user 103 by user input means of the device 102. For example, the user output means may include one or more display screens (touch or non-touch screen) that provide visual output, one or more speakers that provide audio output, and / or one or more tactile output devices that provide tactile output, etc. The user input means may include, for example, one or more touchscreen input arrays (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms that receive speech or audio input, one or more gesture-based input devices that receive input in the form of manual or physical gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0069] Note: Although various functions are sometimes described herein as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in two or more different suites of applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of any of modules 401, 402, 403, 404, and 405 may be implemented in two or more separate applications in any combination. Also, nothing precludes some or all of the described functionality being implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, it is understood that this is merely an example, and more generally, the described functionality may be implemented in any form of software.

[0070] 5 provides a simulated representation of an example user interface (UI) 500 that may be rendered by the UI layer 401 of the client application 105 on Bob's device 102b in a scenario where Bob is the consumer of data. It is understood that a similar UI may be rendered by the client 105 of any other consumer party. The UI 500 may include one or more UI elements, e.g., 501, 502, that are rendered by the user output means of the consumer device 102.

[0071] In embodiments, UI 500 may include hyperdocuments rendered by hypertext engine 403 through UI layer 401. The term "hyperdocument" is used herein to refer to any document that includes one or more hyperlinks anchored by any piece of text or anchor content 502, such as a still or video image. If at least one of the links is anchored by a piece of text, the document may be referred to as a hypertext document.

[0072] Each hyperlink includes a user-selectable UI element, called anchor content 502. User input means are configured to allow user 103 (in this case Bob 103b) to select anchor content 502, for example by clicking or touching on the screen. When this is detected, UI layer 401 signals the selection to hyperdocument engine 402, which in response triggers the respective link to the respective destination.

[0073] It is understood that the particular means of rendering the various UI elements and selecting hyperlinks is not important. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 500 shown in FIG. 5 is merely a schematic mock-up, and that in practice it may include one or more additional UI elements that are not shown for the sake of brevity. Hyperdocument 501 may be of different formats and include different numbers of hyperlinks.

[0074] <Transaction Hypertext> As more non-payment data is stored on the blockchain, a dedicated, secure data request and retrieval system is desirable to efficiently utilize the stored data. Such a system may incorporate one or both of two functions: processing data requests and linking related data. Building on existing hypertext protocols, the following discloses a blockchain-based hypertext protocol that uses a novel hypertext SPV wallet to retrieve data embedded in transactions. In embodiments, the wallet may incorporate a blockchain program launcher to decrypt and display data embedded in transactions. Additionally, embodiments may incorporate secure end-to-end encryption into the system to enable the transfer of sensitive data.

[0075] The present disclosure provides a hypertext document 500 or other such hypertext document for use in blockchain storage functions. In embodiments, it operates in a manner similar to traditional hypertext documents. The following is described in terms of an exemplary scenario in which a second party, Bob 103b, is a consumer ("consumer party") of data provided by a first party, Alice 103a ("provider party"). In this scenario, Bob may be the payer and Alice may be the payee. Of course, it will be understood that the same or similar techniques can be applied mutatis mutandis with the roles of consumer party and provider party reversed, or between other combinations of parties as consumer party and provider party. As previously mentioned, each party can be an individual or an organization such as a company, academic institute, government body, or charity. The provider party 103a may also be referred to herein as a "service provider," which does not necessarily mean a company or an organization of more than one person.

[0076] Various operations below may be described as being performed by the consumer party 103b and the service provider 103a. It will be understood that this may be used as shorthand to mean that the operations are performed by respective software 105a, 105b running on respective computing equipment 102a, 102b of the respective parties 103a, 103b.

[0077] As mentioned above, consumer party 103b retrieves hyperdocument 501 from storage and renders it through the UI layer 401 of their client software 105b. In some embodiments, hyperdocument 501 may be retrieved from storage on consumer party's own computing equipment 102b, for example, from local storage on consumer party 103b's user terminal or from a private storage location on a server. In the latter case, it may be accessed via the same packet-switched network 101 as blockchain network 106, e.g., the Internet, or another network such as consumer party 103b's private local area network. In other embodiments, hyperdocument 501 may be retrieved from a website on the World Wide Web. If packet-switched network 101 is the Internet, document 501 may again be accessed via the same physical network as blockchain network 106.

[0078] As shown in FIG. 6A, in a further embodiment, the hyperdocument 501 may be stored in an existing transaction 152S on the blockchain 150, which may be referred to as the “source transaction” for purposes of the present invention (note that in this context, “source” refers to the source of the document, not necessarily the source of the payment). The hyperdocument 501 is stored in and accessed from one or more appropriate payload fields of the source transaction 152S where payload data (content) may be stored. For example, in an output-based model, the hyperdocument 501 may be stored in an unspent output 203S of the source transaction 152S, e.g., an unspent UTXO. The output in question may be made unspent by the inclusion of an opcode such as OP_RETURN that terminates execution of the script contained in the output.

[0079] In such an embodiment, consumer party 103b accesses hyperdocument 501 via blockchain network 150 (again, via packet-switched network 101 as the physical network on which blockchain network 106 sits) by inspecting relevant fields of source transaction 152S on blockchain 150.

[0080] As shown in FIG. 6A , in an output-based model, a source transaction 152S includes at least one input 202S that points back to some other prior transaction (not shown). For example, the prior transaction could be another transaction of the same service provider, Alice, and / or a negligible amount of dust. Thus, the service provider need only pay a mining fee to place the source transaction 152S on the blockchain 150. The source transaction 152S also includes at least one output 203S1, which, in embodiments, takes the form of an unspendable output. For example, using the Script language, this may be implemented by including an OP_RETURN opcode in the lock script of the output 203S1, which terminates the script when executed on a node 104 of the blockchain network 150. This makes the output usable instead of carrying any payload data. In embodiments, this is used to store the source hyperdocument 501. Most transaction protocols also require transactions to have at least one usable output 203S0. This may specify a refund to the service provider and / or a dust payment. In embodiments, the output may be referred to as a UTXO. The source transaction 152S is here represented by a TxID S It also includes a header field 201S containing a source transaction ID labeled

[0081] Other formats, transaction protocols, or transaction models of source transactions in other blockchains 150 are not excluded. For example, it is not excluded that models based on different types of outputs can be implemented that allow payload data in unspendable outputs 203S0 or that do not require all transactions to have usable outputs. Other scripting languages may have other opcodes for generating unspendable outputs. In another alternative, the hyperdocument 501 can be included in a smart contract field of a transaction in an account-based model.

[0082] While the following is described in terms of the source hyperdocument 501 being stored in and accessed from the unusable output 203S1 of the source transaction 152 in an output-based model, it will be understood that this is not a limitation and that more generally the same techniques regarding the content and functionality of the hyperdocument 501 can be applied to different types of transactions, even if they are stored off-chain.

[0083] A hyperdocument 501 is a document that contains one or more hyperlinks. As shown in FIG. 6A , a hyperlink contains at least three parts: a piece of anchor content 502 (sometimes simply referred to as an “anchor”), a destination identifier 601 where the linked item of data content can be found, and one or more code elements 602 that associate the identifier 601 with each anchor content 502 and identify the hyperlink as a link. If the hyperdocument 501 is created in a markup language such as HTML, the code elements take the form of one or more tags that tag each anchor content 502 with its respective identifier 601 and allow it to act as a front end for the link. The anchor content 502 is the user-visible portion of the link and also acts as a user control through which a user can access the link. If the anchor content of at least one hyperlink contains text, the hyperdocument 501 may be referred to as a hypertext document. However, it is not excluded that the anchor content of one or more hyperlinks may alternatively or additionally contain other types of content, such as still images or video.

[0084] Hyperdocument 501 may take any suitable form, such as an HTML page, a word processing document, a spreadsheet, a slide deck, etc.

[0085] When the hyperdocument engine 402 renders the hyperdocument 501 by the UI 401 / 500 (e.g., on-screen) of the device 102b of the consumer user 103b, it renders the anchor content 502 to the user, rather than the underlying identifier 601 or code element 602. The anchor content thus acts as a front end for the link. Typically, the hyperdocument engine 402 may render links differently, for example, by underlining the links or adapting the link color, to indicate to the user that they are links and to distinguish them from other non-hyperlink content. However, this is not required for all possible implementations (e.g., the links could be hidden links like Easter eggs, or the content itself could inherently explain or indicate to the user that it precedes the link).

[0086] User interface 500 allows a user to select anchor content 502, for example, by clicking via a point-and-click interface or by touching on a touchscreen. In response, UI layer 401 sends a signal indicating this to hyperdocument engine 402. In response, hyperdocument engine 402 initiates one or more operations necessary to access the destination content from the destination resource linked by the respective identifier 601, for example, sending one or more signals to access the destination content over a network such as packet-switched network 101 (e.g., the Internet).

[0087] Conventionally, the identifier 601 of a hyperlink destination may be a uniform resource locator (URL) that identifies the destination in the form of a web resource. However, according to one aspect disclosed herein, the destination of at least one of the hyperlinks in the hyperdocument 501 is another transaction 152D on the blockchain 150, and the respective identifier may be the transaction ID (referred to herein as TxID) of the destination transaction. D In an embodiment, the language used to create hyperdocument 501 or at least one of the transaction hyperlinks therein may include a custom markup language or other such hypertext or hyperdocument language specifically designed for transactional applications. More specifically, however, hyperdocument 501 is created using an existing language such as Hypertext Markup Language (HTML). In this case, only minor extensions to the existing language are required to introduce new variations of existing types of tags traditionally used to create hyperlinks to URLs. Other existing types of tags may also be used within hyperdocument 501, for example, to create bold text, set fonts, play MIDI files, create tables, or add effects such as scrolling text.

[0088] HTML is a standard language for web page design, containing instructions for content presentation (e.g., headings, fonts, images, etc.) and hyperlinks (links to other web pages in the format expected by HTTP: http: / / www.DOMAIN / PAGE). The blockchain hypertext document 501 disclosed herein can contain the same HTML commands for presentation:

number

number

[0089] FIG. 6A illustrates an example of one destination transaction 152D1, according to an embodiment. In an embodiment utilizing an output-based model, destination transaction 152D1 includes at least one input 202D that points back to some other prior transaction (not shown). For example, the prior transaction of destination transaction 152D1 could be another transaction of the same service provider, Alice, and / or a negligible amount of dust. Note that input 202D1 of destination transaction 152D need not use output 203S0 of source transaction 162S (which is a source in the sense of being the source of hyperdocument 501). However, this is not excluded. Source transaction 152D1 also includes at least one output 203D11, which in an embodiment takes the form of an unavailable output. For example, using the Script language, this may again be implemented by including an OP_RETURN opcode in the lock script of output 203S1. In an embodiment, this unavailable output 203D11 is used to store destination data 603. Most transaction protocols also require a transaction to have at least one spendable output 203D10, which again may designate a refund to a service provider and / or a dust payment. In embodiments, the output may again be referred to as a UTXO. The destination transaction 152D1 here is represented by a TxID D1 It also includes a header field 201D1 containing a D for each of the destination transactions I labeled as follows:

[0090] Other formats, transaction protocols, or transaction models of destination transactions in other blockchains 150 are not excluded. For example, it is not excluded that models based on different types of outputs can be implemented that allow payload data in unspent outputs 203D10 or that do not require all transactions to have usable outputs. Other scripting languages may have other opcodes for generating unspent outputs. In another alternative, the destination data 603 can be included in a smart contract field of a transaction in an account-based model.

[0091] The following is described in terms of the destination data 603 being included in the unusable output 203D1 of at least one destination transaction 152D on the blockchain 150 in an output-based model, but it will be understood that this is not a limitation and that the same techniques relating to data 603 can be applied more generally when stored in different types of transactions on other types of blockchains.

[0092] In embodiments, source hyperdocument 501 may include multiple hyperlinks. One or more of them may be links to destination transactions 152D on blockchain 150. In embodiments, one or more others may be conventional links to URLs. In embodiments, source hyperdocument 501 may include multiple hyperlinks to different destination transactions 152D1, 152D2 on blockchain 150. While two are shown in FIG. 6A for illustrative purposes, it is understood that other numbers may be present. In this manner, hyperdocument 501 can function as a kind of index to resources stored in multiple other transactions 152D1, 152D2, etc.

[0093] In an embodiment, each destination transaction 152D1, 152D2, etc. may have the same format as described above with respect to the first destination transaction 152D1.

[0094] Note that the service provider providing source hyperdocument 501 need not be the same service provider (provider party) that provides destination data 602. In an embodiment, Alice 103a is at least the provider of destination data 603 in at least one destination transaction 152D. The source hyperdocument may be provided by Alice, a third-party provider, or may be generated by Bob himself.

[0095] Destination data 603 can be virtually any type of content, i.e., payload data or user content (as opposed to elements of transaction 152D that are relevant to how it functions as a transaction on blockchain network 106). For example, destination data 603 may include text, one or more still or video images, and / or audio content. It may take the form of another document or file. In embodiments, the destination data in at least one of destination transactions 152D may include another hyperdocument, e.g., a hypertext document, that includes one or more additional hyperlinks and / or URLs to one or more additional transactions 152. Different data 603 may be included in different ones of destination transactions 152D.

[0096] When the consumer user 103b selects (e.g., clicks or touches) the anchor 502 of one of the hyperlinks linking to a destination transaction 152D on the blockchain 152, the hyperdocument engine 402 triggers the data transfer engine 403 to perform a set of operations to retrieve the destination payload data 603 from the relevant field (e.g., unusable output 203D11) of each destination transaction 152D (e.g., 152D1) based on the respective transaction ID 601 as retrieved from the hyperlink. This includes accessing the respective destination transaction 152D1 from one of the storage nodes 104S on the blockchain network 106 via the physical network 101 (e.g., the Internet) on which the blockchain network 106 is implemented.

[0097] In embodiments, in an output-based model, the hyperlink may also include an identifier for the particular output in which the data is stored. For example, the hyperlink may include a transaction TxID D1 For example, the data transfer engine 403 may specify output 1 (203D11) of the destination transaction. In this case, the output identifier is retrieved from the hyperlink and is also used to identify the data. However, this is not required. Alternatively, the data transfer engine 403 may be configured to always retrieve data from the same predetermined output number of the destination transaction (e.g., it is assumed to always be stored in output #1). Or, more generally, in other models, the data may be stored in a specific, predetermined location located within the data structure of the destination transaction 152D. As another alternative, the data transfer engine 403 may be configured to search the data structure of the destination transaction 152D for outputs or data of a predetermined type or marked with a predetermined format, for example, by searching for any output 203 containing OP_RETURN, or by searching for some other predetermined marker.

[0098] The program launcher 405 is configured to execute program code downloaded from the payload of a transaction 152 on the blockchain 150, for example, from an unspent output (such as a UTXO containing OP_RETURN). In an embodiment, the data 603 is accessed by selecting a hyperlink, which may include a program or portion thereof. In this case, the hyperdocument engine 402 may be configured, in response to selecting the hyperlink, to not only trigger the data transfer engine 403 to access the program code from the destination transaction 152D on the blockchain 150, but also to trigger the program launcher 405 to execute this code 603. The code 603 stored in the destination transaction 152D may include any suitable interpretable, compilable, or executable code, such as Java script, Python, C++, or executable machine code.

[0099] Alternatively or additionally, the hyperdocument engine 402 itself, or portions thereof, may take the form of a module of program code that has already been pre-downloaded from another transaction 152 (not shown) on the blockchain 150 (e.g., from an unspent output such as a UTXO containing OP_RETURN). In this case, the code in question is accessed by some other means than selecting a hyperlink, and the program launcher 405 is configured to execute this portion of code in order to implement the above-described functionality of the hyperdocument engine 402.

[0100] In some embodiments, the destination data 603 may be unencrypted and freely available. In that case, the data transfer engine 403 can simply read the data 603 from each destination transaction 152D. The data may also be compressed, for example, using LZM or any other known compression technique. In this case, reading the data includes decompressing the data. If the data 603 is in a format that can be rendered to the user 103b, such as text or image data, the data transfer engine 403 then renders it through the UI layer 401 and the UI 500. If the destination data 603 includes a hyperdocument, such as a hypertext document, this may include rendering it with the hyperdocument engine 402.

[0101] In other embodiments, however, at least a portion of the destination data 603 may be encrypted, for example, based on XOR encryption or any other known encryption technique, and therefore require a decryption key for decryption. The decryption key may also be referred to herein as an access key. In such embodiments, then, in response to activation of the respective hyperlink, the data transfer engine 403 decrypts each destination data 603 using the access key before decompressing or rendering the respective destination data 603 to the consumer user 103b.

[0102] In some scenarios where the destination data 603 is encrypted, the consumer party 103b may not have the necessary access key to decrypt the data 603 when activating the respective hyperlink. In such embodiments, the data transfer engine 403 may be configured to send a request to the service provider 103a (the provider party, i.e., the provider of at least the destination data 603) in response to the activation of the respective hyperlink. The request may be sent via a side channel 301 or via the blockchain 150 itself. Either way, in response, the provider 103a sends a copy of the access key back to the consumer party 103b, subject to meeting any conditions imposed by the provider (such as receiving payment from the consumer party 103b and / or verifying the identity of the consumer party 103b).

[0103] In certain embodiments, this process may involve another transaction 152C, referred to herein as a "client transaction" because it is issued by the data transfer engine 403 of a consumer user 103b acting as a client of a data service provider 103a (the donor party). An example is shown in Figure 6B.

[0104] The client transaction 152C serves one or both of two functions: first, to pay the providing party 103a for the data 603, and / or second, to signal a request to the providing party 103a.

[0105] As shown in Figure 6B, in the output-based model, client transaction 152C includes at least one input 202C pointing to an output of another, earlier transaction of consumer party Bob 103b. It may also include a usable output 203C0 specifying a payment to provider 103a of data 603. And / or it may include an unusable output 203C1 that has been disabled, for example, by OP_RETURN. The unusable output 203C1 includes at least two elements: the transaction ID 604 of the destination transaction of the selected link (TxID in this example) and D1 ), and a code element 605 that acts as a signal that destination data 603 is requested from destination transaction 152D (in this example, transaction 151D1 of FIG. 6B) with a specified transaction ID. Consumer party 103b may sign portions of client transaction 152C, such as portions that include one or more of outputs 203C.

[0106] In response to the consumer user 103b selecting the hyperlink, the data transfer engine 403 automatically generates a corresponding client transaction 152C and transmits it for receipt by the service provider 103a.

[0107] In embodiments, this may include sending client transaction 152C to service provider 103a via side channel 301. In this case, service provider 103a receives client transaction 152C, then she reads ID 604 and request signal 605 and, in response, returns the corresponding access key to consumer 103b. This can be done by sending it via side channel 301 or by placing transaction 152 on blockchain 150. Service provider 103a then broadcasts client transaction 152C to blockchain network 106 for recording on blockchain 150 to receive her payment. In some cases, consumer party 103b may send the client transaction to service provider 103a in the form of a template transaction that lacks one or more parts necessary to be recorded on blockchain 150, such as the signature of service provider 103a. In this case, service provider 103a takes the necessary steps to add the missing portions, for example, by signing the transaction (e.g., by signing the portion including one or more of outputs 203C) before broadcasting it to network 106. In an embodiment, service provider 103a transmits the access key to consumer party 103a, for example, by malleating the client transaction to include the access key in the unusable output, and broadcasting the adapted client transaction to be recorded on blockchain 150.

[0108] In an alternative embodiment, consumer party 103b communicates client transaction 152C to service provider 103a by broadcasting client transaction 152C to blockchain 150 himself to have client transaction 152C publicly recorded on blockchain 150. Optionally, consumer party 103b may signal service provider 103a via side channel 301 to let her know that client transaction 152C is now on-chain. However, this is not required. Because spendable output 203C0 of client transaction 152C is addressable to service provider 103a, this means that she can find it on chain 150. Furthermore, the transaction's unlock script is identifiable as originating from consumer Bob because it includes Bob's public address and a cryptographic signature, which would have required knowledge of Bob's private key.

[0109] Upon finding a satisfactory client transaction 152C on-chain, service provider 103a responds with an access key. She reads ID 604 and request signal 605 and, in response, returns the corresponding access key to consumer 103b. Again, this can be done by sending it over side channel 301 or by placing yet another transaction 152 on blockchain 150 (see below).

[0110] As mentioned above, one way for service provider 103a (Alice) to provide consumer 103b with the access key is to publicly place it in yet another transaction (not shown) on blockchain 150. For example, again, this could be done in an output-based model by placing it in an unspendable output (e.g., a UTXO containing OP_RETURN). The access key itself could now be stored in plaintext. However, this could make the data 603 inaccessible to anyone in the public, even if a particular consumer 103b (Bob) meets the conditions for access (e.g., has made a payment and / or meets any other verification criteria, such as his identity). To solve this, in embodiments, the access key is placed on the blockchain itself in an encrypted form, encrypted based on a shared secret known only to Alice and Bob, or at least to a select group including Alice and Bob.

[0111] In a variation of the above scheme, a more complex cryptographic puzzle may be used to ensure that only Bob obtains the access key. In this case, Alice places encrypted pieces of information on the chain that allow Bob to derive the access key. For example, Alice may place an encrypted password on the blockchain 150 that is encrypted based on a shared secret. The destination data 603 itself may be encrypted based on an access key that is a function of the password (e.g., a function including one or more hashes). In this case, once Alice receives Bob's payment and / or verifies any other conditions for access, she makes the encrypted password available on the blockchain 150. Bob can access it, decrypt it based on the shared secret, then use the decrypted password to calculate the access key and use the access key to decrypt the data.

[0112] Some exemplary implementations of the above protocols will be described in more detail shortly.

[0113] In embodiments, Alice may signal Bob via side channel 301 to let him know that the access key, encrypted access key, or other such piece of access information is now available on blockchain 150. Alternatively, Alice does not do this; instead, Bob's identifier in the transaction allows him to find it himself. For example, Alice may address the transaction output (e.g., a UTXO) to Bob, preferably containing the dust amount of access information (since Bob is the one paying Alice in this scenario).

[0114] In embodiments, it may be desirable to update information stored in transaction 152, such as source hyperdocument 501 in source transaction 152S or destination document or other such data in destination transaction 152D. Once recorded in the blockchain, existing transactions cannot be modified. Instead, therefore, in embodiments, updates can be performed by post-adding a new transaction to the chain, where the new transaction uses the available output of the existing transaction that stores the data being updated. Thus, a page, etc., can be updated by using transaction 152D that contains the previous version. This linking can also be used to provide a complete version history that can be freely recalled, with the latest version always included in the TUXO set.

[0115] To accomplish this, the existing transaction (being updated) may include at least a spendable output (and potentially an unspendable output under OP_RETURN, etc., if data is included). Once validated, the spendable output is included in a UTXO set maintained by some or all of the storage and / or mining nodes 104S, 104M (e.g., typically stored by all miners and some storage nodes). To update, the spendable UTXO of the existing transaction may be used and the updated data may be included in a new transaction (e.g., a new unspendable output of the new transaction, again using an OP_RETURN opcode, etc.). Once validated, this new transaction is now included in the UTXO set. Thus, the most recent information is always available in the UTXO set maintained by each storage and / or mining node 104S / M. For example, one of the destination transactions 152D1 may be updated using that destination transaction 152D1 to generate a new destination transaction 152D1′ (not shown) that includes the updated data. The pre-existing source document 501 still links to the TxID under destination transaction 152D1. However, when hyperdocument engine 402 follows that link, in embodiments, it automatically retrieves from one of storage or mining nodes 104S / M by UTXO set whether there are any subsequent transactions that use the linked destination transaction 152D1. If so, it automatically retrieves the data from the later transaction instead.

[0116] <Example Data Transfer Protocol> The following describes some example implementations of data transfer protocols that may be utilized by the data transfer engine 403. In embodiments, any of these may be triggered when consumer party (Bob) 103b selects a hyperlink from a hyperdocument 501 as a means of requesting access to data from a linked destination transaction 152D. Alternatively, however, any of these protocols may be used to enable provider party (Alice) 103a to provide Bob access to data via a transaction 152 on the blockchain 150 (e.g., from an unspent output), regardless of how the request for access is triggered, not necessarily by selecting a hyperlink.

[0117] A first exemplary protocol is described with reference to Figures 7 to 9. It may be used, for example, as a peer-to-peer messaging protocol where one person (Alice) sends data to another person (Bob).

[0118] For transmitting sensitive information such as personal details (name, address, banking information, medical data, etc.), it is desirable to take extra precautions to ensure that the data is securely encrypted to prevent privacy violations. In an embodiment, this may be done using a set of shared keys.

[0119] For example, two shared secret keys S1 and S2 can be securely established between two parties even over an insecure network as two coordinates (x,y)=(S1,S2) of an elliptic curve point. For example, if Alice (A) has a private key V, A and public key P A =V A ·G, and Bob (B) has a private key V B and public key P B =V B Let G be an agreed upon elliptic curve generator point. Alice can use Bob's public key to compute the secret as follows:

number

number

[0120] An example of such a procedure is as follows and is also shown in FIG.

[0121] In step S1, Alice calculates:

number

number

[0122] In step S4, Bob receives Tx. When receiving, B sends S Kx There is no need to use Tx to know

[0123] In step S5, Bob calculates:

number

number

[0124] Note that consumer Bob obtains key K by interacting with blockchain 150 itself (as opposed to the service provider system). That is, provider Alice puts some cryptographic information on-chain that allows Bob (but not anyone else) to derive key K based on a shared secret. However, in other embodiments, Alice can provide the necessary access key to Bob off-chain via side channel 301.

[0125] Note also that the applicability of this procedure is not limited to data transfer: for example, in other applications, the key could grant Bob access to over-the-top (OTT) video or music streaming services, or rental services, etc.

[0126] Below is an exemplary step-by-step procedure for a secure hypertext transfer for consumer party Bob 103b to request data or a file from the blockchain network 106, following the process schematic shown in Figure 8. In this particular example, the computational simplicity allows this to be achieved within a transaction script of a UTXO-based model using the OP_XOR opcode.

[0127] At step T1, Bob requests good data for the hyperlink through his UI 500. In response, the UI layer 401 indicates a request to the smart SPV wallet function 406 on Bob's computing device 102b (e.g., his local computer).

[0128] In step T2, the smart SPV 406 negotiates a session key using a secure secret distribution protocol, such as an XOR-based key agreement protocol, to generate two private keys (S1 and S2). In an embodiment, consumer Bob negotiates the session key by interacting with the blockchain 150 itself (as opposed to a service provider system). For example, this can be done based on a script in a UTXO-based model based on XOR encryption. As another example, it can be done with a smart contract in an account-based model. In a further alternative, however, the negotiation may be performed off-chain via a side channel 301.

[0129] In step T3, the data request from Bob is encoded using S1 and broadcast to the network 106. The request itself may therefore be broadcast on-chain. Alternatively, however, if an existing relationship exists between Alice and Bob, a side channel 301 may be used instead.

[0130] In step T4, the service provider (Alice) encodes and compresses the target data 603 (using S2 derived from S1) and includes it in a transaction addressed to the client's public address (Bob's address). Thus, the transaction carrying the desired data payload 603 is put on-chain for consumer Bob to read from blockchain 150. Because it is addressed to Bob, he can find it on blockchain 150. Optionally, Alice can also signal Bob via side channel 301 to alert him to the existence of the transaction.

[0131] As addressed to Bob, this Tx may contain a UTXO with the payment locked to consumer Bob's address. This may be a dust (negligible) amount, but by locking the output to Bob's address, he is notified of the transaction, in which he knows the TxID he needs. In other cases, Alice and Bob may need a side channel 301 to communicate the TxID.

[0132] At step T5, the SPV 406 in Bob's smart wallet 105b receives the transaction, decrypts it using shared secret S2, and then decrypts the data.

[0133] At step T6, the decrypted data is displayed to Bob through UI 500. In an embodiment, this may be done using blockchain program launcher 405.

[0134] Embodiments may utilize a specially designed SPV wallet 105b as an intermediary between clients and the blockchain network. The use of an SPV wallet allows for secure use across devices without the need for large-scale data storage. In some implementations, received data may be verified locally using only block headers by performing Merkle proofs, allowing smartphones and other mobile devices to connect to the service. This is a key feature of operating a smart wallet at an SPV node.

[0135] In embodiments, SPV wallet 105b may have any or all of three different functions: The first function is key management and monitoring of the blockchain network for related transactions using, for example, a bloom filter. This may include establishing a shared secret session key with sender 103a. The second function is to translate hyperlink clicks into transaction requests via transactions for propagation through the blockchain network 106. The third function is to decrypt and inflate data within transactions.

[0136] The first point is standard in traditional SPV wallets and therefore will not be discussed further here. However, the second point is not standard: converting a hyperlink click into a transaction. As described above, the hyperlink contains an identifying and actionable link for the transaction. Clicking the link triggers the SPV to generate a transaction 152C sufficient to pay the transaction fee and any service fees for the data request service. This transaction can also summon tokens in exchange for the requested data. Using OP_PUSHDATA or OP_RETURN, a "request" signal can be included in the signed transaction along with the desired transaction ID. Using the above protocol, data can be encoded using OP_XOR and a mutually shared key. Similarly, an XOR operation can be used to decode the data, and the data can be decompressed using an LZM dictionary and passed to the blockchain program launcher 405.

[0137] 9 shows an example structure of request and response transactions for establishing a connection between Bob, who is requesting information from a particular transaction, and Alice, who has agreed to provide encrypted data. Following payment, Alice can send encrypted data to Bob using the session key.

[0138] A second exemplary protocol is described below with reference to Figures 10 and 11. This may be used, for example, as a hypertext request and response system, whereby someone (Alice) can post data once and sell access to one or more other people (including Bob).

[0139] As user data requests are broadcast to the blockchain network 106, a system is needed to process the requests, retrieve the data, and then, preferably, compress the data into transactions addressed to the client. The following describes both centralized and decentralized solutions for data distribution. Through decentralization of these processes, any peer can fulfill a request, so such systems no longer rely on a single entity (such as an individual or company) to provide data to the network. This eliminates denial-of-service (DoS) attacks or downtime caused by system updates or technical issues. Furthermore, by including some fee for user-mediated responses, the system can improve response times. This cost reduces the likelihood of DoS attacks, as attackers would need to provide a per-request fee.

[0140] As a data provider 103a, the first stage involves storing encrypted data in the blockchain, which proceeds as follows from the perspective of data provider Alice (A): See Figure 10.

[0141] In step U1, Alice chooses a random string T to be used as a password to access the data.

[0142] In step U2, Alice calculates:

number

[0143] In step U4, Alice composes a transaction to herself with the following stored as the OP_RETURN output: encrypted data 603, a description of the data, the asking price for the data, and a hash-based message authentication code (HMAC) calculated over the hash of the encrypted data and password T. HMACs themselves are known in the art. This transaction is a data storage transaction (destination transaction 152D in the example above where a hyperlink is used, although this protocol is not limited to use with hyperlinks as a means of accessing destination transactions).

[0144] This transaction, when included in the blockchain, can simultaneously serve many functions. First, it is a permanent, immutable record of the encrypted data that can be accessed by the data owner at any time in the future by recording the transaction identifier (TxID). Second, it can act as an advertisement for the data that can be searched by interested buyers. Finally, the inclusion of an HMAC can be used by buyers to verify Alice's honesty and to assist in dispute resolution, as described in more detail below.

[0145] An example of the data exchange procedure between data provider Alice and data purchaser Bob is as follows: See FIG.

[0146] In step V1, Bob sends an offer transaction to Alice over side channel 301 in the form of a template transaction, along with Alice's public address or prefix (listed in the data storage transaction) and the price in OP_RETURN.

[0147] In step V2, Alice maleates the received template transaction to construct a transaction with two inputs: the UTXO sent by Bob and her own UTXO. Bob is the payer in this scenario, but the input pointing to Alice's UTXO alerts her to the transaction. Her wallet detects the transaction if it is addressed to her. Therefore, no side channel is needed for this stage. The UTXO that Alice points to can be for the dust amount.

[0148] In step V3, Alice sends the adapted transaction back to Bob over side channel 301.

[0149] In step V4, Bob verifies that the transaction is properly structured and signs his input if he is compliant.

[0150] In step V5, Bob then sends the partially signed transaction back to Alice over side channel 301.

[0151] In step V6, Alice calculates S1=V A P B Calculate where V A is Alice's private key, and P B is Bob's public key.

[0152] In step V7, Alice signs her input as part of the Input Script, which is made publicly available:

number

[0153] In step V8, Alice broadcasts the now fully signed transaction to the blockchain network 106 to be recorded in the blockchain 150.

[0154] In step V9, Bob calculates S1=V B· P A Calculate where V B is Bob's private key, and P A is Alice's public key.

[0155] In step V10, Bob uses S1 to calculate:

number

number

[0156] The above-described method advantageously integrates payment and data transfer, allowing data to be sent over the blockchain 150 in a way that ensures that Alice gets paid and Bob receives the data.

[0157] If Alice is honest, the HMAC matches the one in the data storage transaction, and the data is as described in the description portion of the data storage transaction. If Alice sent an incorrect key, Bob can prove this using the key she sent and a hash of the encrypted data in the data storage transaction. If Alice sent incorrect data, Bob can detect this by using the key to encrypt the data and comparing it to the one in the data storage transaction. Additionally, a trusted third party, such as a government or company, can keep a record of the data and encrypted data, which can be used to verify that the encrypted data matches the description provided.

[0158] The above method can be summarized more generally as follows: Data is encrypted with S0 (which in this example is not part of the shared secret). Alice includes in the transaction an encrypted version of her password T (encrypted under the shared secret S1), rather than an encrypted version of her key S0. The key S0 needed to decrypt the data is a predetermined function of the password (in this case a hash-based function, which is based on Alice's public key P A (It is also a function of ). Bob decrypts the password and then uses the known function to calculate S0 and uses this to decrypt the data. The HMAC is included in the data store transaction and is a function of the data and the password. Now Bob has the password T and the data from Alice, he can calculate the HMAC and compare it to the version in the data store transaction.

[0159] The advantage of sending Bob an encrypted password and making S0 a function of the password is that it prevents S0 from being transmitted (as opposed to simply sending him an encrypted version of the key directly, as in the previous methods of Figures 7-9). Thus, if the transmission is compromised, it does not directly compromise the data. An attacker might need to know, for example, how to compute S0, which Alice and Bob could share via a secure side channel. The function does not necessarily have to be a function of Alice's public key either, but simply some deterministic piece of information known by both parties. The information could include additional parameters, such as Alice's public key, or simply the form of the transformation (i.e., the function) itself.

[0160] In a variation of the above method, the data may be stored off-chain and then placed on-chain when requested by Bob, i.e., Alice performs the method of Figure 10 in response to a request from Bob for the data, rather than in advance.

[0161] A further case to consider is a centralized data repository service, similar to modern cloud-based systems. In this case, a single organization is responsible for storing, logging, and retrieving data stored on the blockchain or possibly on an external private server. Clients who want to store their data on the blockchain would pay a subscription or per-use fee to a provider who can encrypt and distribute their data and keep records of retrievals. This eliminates the need for individual users to keep records of their encryption or private keys. Similarly, in services with large amounts of shareable data, such as music or video streaming services, subscription or per-use fees could be charged for access to the data.

[0162] In each case, the client initiates a request via a publicly available address provided by the service, with details of their request included in the transaction. The client's identity is verified, any terms such as usage fees are verified, and a session key may then be generated using the protocol disclosed above. Upon receiving the request, the service provider encodes the requested data using a standardized compression algorithm such as the Lempel-Ziv Markov Chain (LZM) algorithm and includes it in a transaction addressed to the client. The data is decrypted and decoded by the client's SPV wallet and then displayed to the user.

[0163] In the context of the above-mentioned peer-to-peer protocols, a repository service can act as a trusted third party to facilitate the exchange of data between data providers and data buyers. The repository service can hold descriptions of data, allowing data buyers to make requests for specific data or purchase batches of related data. The service can also compose transactions, eliminating the need for users to verify or generate transactions or transaction conditions. If the repository service is trusted, it also eliminates the need for HMAC, since the data repository is responsible for checking the validity of the provided data.

[0164] <Conclusion> The ability to efficiently request and retrieve data stored on a blockchain becomes increasingly important as larger amounts of data become involved in transactions. The protocol disclosed herein provides a request-response method for blockchain networks much like the hypertext transfer protocol (HTTP) did for the Internet. Preferably, the method may be standardized. Using a standardized hypertext format, data in the blockchain can be linked and requested with a click in a compatible browser, with the help of an SPV wallet or the like. Both centralized and decentralized data storage can be supported and monetized to compensate service providers and data owners. Previously deployed encryption techniques can be used to secure the request and data transfer steps over public networks.

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

[0166] More generally, according to one aspect disclosed herein, there is provided a method implemented by a computing device of a consumer party, the method comprising: accessing at least a first document that includes one or more hyperlinks, each hyperlink including a respective identifier of a respective piece of anchor content and a respective destination associated with the respective anchor content; rendering content of at least a portion of the first document through a user output device of the computing device of the consumer party, the rendering including rendering anchor content of each of one or more of the hyperlinks; receiving user input via a user input device of the consumer party's computing device selecting one of the hyperlinks by selecting a respective anchor content from among the rendered content; In response to the user input, automatically accessing data from the associated destinations based on respective identifiers included in the first document; Including, A method is provided wherein a destination of at least each of the selected hyperlinks includes a destination transaction in a blockchain maintained across at least some nodes of a blockchain network, and wherein accessing the data includes inspecting the destination transaction in the blockchain via the blockchain network.

[0167] In embodiments, the first document may comprise a hypertext document.

[0168] In embodiments, each piece of anchor content may include text or an image.

[0169] The output devices may include, for example, a display screen or touchscreen pixel array for displaying text and / or images, and / or a speaker for outputting audible content. In the case of images, the images may include still and / or moving images. The input devices may include, for example, a touchscreen sensor matrix, or a mouse, trackpad or trackball, or a keyboard, etc.

[0170] In an embodiment, the first document may be created (written) in a markup language.

[0171] In embodiments, the first document may be an HTML document in which the HTML language is augmented with additional types of tags for generating hyperlinks to blockchain transactions.

[0172] In embodiments, the first document may be accessed via the blockchain network from another source transaction on the blockchain.

[0173] In embodiments, the first document may be stored in an unusable output of the source transaction.

[0174] In embodiments, the blockchain may use an output-based (e.g., UTXO-based) transaction model in which each transaction includes one or more outputs (e.g., UTXOs), each output includes a locking script, and the first document may be stored in an unspent output of the source transaction. In embodiments, the unspent output of the source transaction may be made unspent by a command such as OP_RETURN included in a locking script that, when executed by a node in the blockchain network, terminates the locking script.

[0175] In alternative embodiments, the techniques disclosed herein may be implemented through an account-based mode, for example, the data may be stored in and accessed from the destination transaction's smart contract.

[0176] In embodiments, the first document may be accessed from a website or from local storage on the consumer party's computing device.

[0177] In embodiments, the first document may include a plurality of said hyperlinks, at least some of which may have respective destinations to different respective transactions on the blockchain.

[0178] And / or, the destinations of each of the plurality of hyperlinks may include a combination of one or more destination transactions on the blockchain and one or more web resources.

[0179] In embodiments, rendering the anchor content may include rendering the anchor content in a format that indicates that it operates as a hyperlink. For example, this may include underlining it or rendering it in a particular color.

[0180] In embodiments, the accessed data may include a second document including content in the form of text and / or one or more images, and accessing the second document may include rendering at least a portion of the second document on the consumer user's computing device.

[0181] In embodiments, the second document may itself contain one or more further hyperlinks.

[0182] In embodiments, the one or more further hyperlinks include at least one hyperlink to a further destination transaction on the blockchain.

[0183] In embodiments, the second document comprises a hypertext document. The second document may be written in a markup language. The second document may be an HTML document augmented with at least one additional type of tag for creating links to transactions on the blockchain.

[0184] In embodiments, the data may be stored in an unusable output of the respective destination transaction.

[0185] In embodiments, the blockchain may use an output-based (e.g., UTXO-based) transaction model in which each transaction includes one or more outputs (e.g., UTXOs), each output includes a locking script, and the first document may be stored in an unspendable one of these outputs in the destination transaction. In embodiments, the unspendable output of the destination transaction may be made unspendable by a command such as OP_RETURN included in a locking script that, when executed by a node in the blockchain network, terminates the locking script.

[0186] In embodiments, each hyperlink may further include an output identifier for each individual output in the respective associated destination transaction in which the data is stored, and accessing the data may include accessing the data from the respective output based on the respective transaction and output identifier. Alternatively, the data may be stored in a predetermined output number, or more generally in a predetermined location, of the destination transaction, in which case accessing the data simply involves accessing the data from the predetermined output or location. Another possibility is that accessing the data simply involves searching the respective destination transaction for data or output of a predetermined expected type or format.

[0187] In embodiments, the data may include encrypted data.

[0188] In embodiments, the method may further include sending a client transaction from the computing device of the consumer party to request a provider party to provide access to the encrypted data and / or to pay the provider party for access to the encrypted data, wherein the client transaction may be sent to be recorded on the blockchain network or may be sent to the provider party via a side channel.

[0189] In an embodiment, the same client transaction may implement both functions.

[0190] The payment may be included in a spendable output of the client transaction, the spendable output being addressed to the providing party. The blockchain may use an output-based (e.g., UTXO-based) transaction model in which each transaction includes one or more outputs (e.g., UTXOs), and a spendable output may be one of these outputs of the client transaction.

[0191] The transmitting step may include the consumer party directly broadcasting the client transaction onto the network itself. Alternatively, the consumer party may transmit the client transaction via a side channel to the provider party or third party for broadcasting to the provider party or third party for forwarding onto the network.

[0192] As another alternative, the consumer party may send the client transaction to the provider party via a side channel. The client transaction may be sent in a template format, for example, requesting the provider party to sign it or add inputs before it can be recorded on the blockchain.

[0193] In embodiments, the client transaction may include a request message including an identifier of the destination transaction and a signal requesting access to the encrypted data.

[0194] In embodiments, the request message may be included in an unusable output of the client transaction.

[0195] In embodiments, the blockchain may use an output-based (e.g., UTXO-based) transaction model in which each transaction includes one or more outputs (e.g., UTXOs), each output includes a locking script, and the request message may be stored in an unspent output of the client transaction. In embodiments, the unspent output of the client transaction may be made unspent by a command such as OP_RETURN included in a locking script that, when executed by a node in the blockchain network, terminates the locking script.

[0196] In embodiments, the sending of the client transaction may be triggered by the user input.

[0197] In embodiments, the consumer party may send the client transaction to the provider party via a side channel, which the provider party reads and broadcasts to the blockchain network. Alternatively, the consumer party may broadcast the client transaction to the blockchain network and separately signal the provider party via the side channel that the client transaction was broadcast to the blockchain network. Alternatively, the consumer party may not separately signal the provider party via the side channel at all, but simply broadcast the payment to the blockchain network, allowing the provider party to observe the client transaction on the blockchain. When the client transaction includes a payment addressed to the provider party, he / she / they can find it on-chain.

[0198] In embodiments, in response to the client transaction, the provider party may provide access information that enables the consumer party to determine an access key for decrypting the encrypted data and thereby access the encrypted data, in which case the method may include receiving, by the computing device of the consumer party, the access information, determining therefrom the access key, and using the determined access key to decrypt and thus access the encrypted data.

[0199] In some such embodiments, the access key may be a one-time or temporary key.

[0200] In embodiments, the provider party may provide the access information to the consumer user by including the information in a transaction on the blockchain.

[0201] Alice (the provider party) may broadcast this transaction to the blockchain network and individually signal Bob (the provider party) via the side channel that the transaction has now been broadcast. Alternatively, the provider party may not individually signal the provider party via the side channel at all, but simply broadcast it to the blockchain network, allowing the consumer party to observe this transaction on-chain. The transaction in question may include an output addressed to the consumer party. In this way, the transaction is addressed to the consumer party, and therefore, he / she / they can discover it on-chain in this way. This output may include a dust payment to the consumer party.

[0202] In embodiments, the consumer party may transmit the client transaction to the provider party in the form of a template via a side channel. In some such embodiments, the provider party provides the access information by adapting the template to include the access information and broadcasting the adapted client transaction to the network to be recorded on the blockchain. Alternatively, the access information may be included in a transaction separate from the client transaction.

[0203] As another alternative, the provider party may simply transmit the requested information to the consumer party via a side channel without including the requested information in a transaction or placing it on the blockchain.

[0204] The access information may include the access key itself in plaintext. However, if it is communicated on-chain, this may make the access key available to any other member of the public. Even in the case of the side-channel transmission, it may be vulnerable to, for example, being intercepted or leaked by the intended consumer.

[0205] Thus, in an embodiment, the access information does not include the access key in clear text, but includes information that allows the consumer party to derive the access key based on a shared secret shared between the provider party and the consumer party.

[0206] In such embodiments, the access information may include an encrypted version of the access key, encrypted based on a shared secret shared between the provider party and the consumer party, in which case the method may further include decrypting, by the computing device of the consumer party, the access key based on the shared secret and using the decrypted access key to access the encrypted data.

[0207] In an alternative variation thereof, the access information may include an encrypted password encrypted based on a shared secret shared between the provider party and the consumer party, and the access key is a first predetermined function of the password. In this case, the method may further include the step of: decrypting, by the computing device of the consumer party, the password based on the shared secret, determining the access key by applying the first predetermined function to the decrypted password, and accessing the encrypted data using the determined access key. In some such embodiments, the function may also be a function of the provider party's public key. For example, in an embodiment, the first function comprises:

number

[0208] In embodiments, the data may be included in the destination transaction along with a message authentication code that is a second predetermined function of the password, the second predetermined function also being a function of the data, in which case the method may include calculating, by the consumer party's computing device, the message authentication code by applying the second predetermined function to the decrypted password and the data, and comparing the calculated message authentication code with the message authentication code included in the destination transaction to determine the authenticity of the data.

[0209] For example, in embodiments, the authentication code may be a hash-based message authentication code, and the second predetermined function is a function based on hashes of the data and the password, the hash-based function including at least one hash.

[0210] In embodiments, the accessed data may include a program, and the method further includes executing the program on the computing device of the consumer party. Alternatively or additionally, the method may include an initial step of reading a program from a further transaction on the blockchain and executing the program, by the computing device of the consumer party, the program performing the steps of rendering the Netengu, receiving the user input, and accessing the data from the destination.

[0211] The program may be included in an unspent output of the program-storing transaction, e.g., a UTXO, which may be made unspent by an opcode that terminates the locking script, such as OP_RETURN, included in the locking script.

[0212] In an embodiment, the method may include updating the first and / or second documents with payment transactions using the source and / or destination transactions, respectively.

[0213] In embodiments, the method may include, in response to the user input, automatically querying a transaction set of the blockchain to check any update transactions that use the destination transaction, where accessing the data from the destination transaction may be performed conditional on the check being negative, the method being performed by a function configured to access the data from the update transaction otherwise.

[0214] According to another aspect, a set of transactions for recording in a blockchain, said set embodied on one or more computer-readable data media; a first transaction storing a first document including one or more hyperlinks, each hyperlink including a respective piece of anchor content and a respective identifier linking to a destination associated with the respective anchor content; one or more second transactions, each storing data content, wherein the destination linked by at least one of the hyperlinks in the first transaction includes one of the second transactions; A set including:

[0215] The data content in each of the second transactions may include text and / or image data. The data linked by the at least one hyperlink may include a second document stored in the one of the first transactions. In some such embodiments, the second document may itself include one or more hyperlinks to one or more further destinations, including, for example, one or more further transactions on the blockchain.

[0216] According to another aspect disclosed herein, there is provided a method for a consumer party to access data from a provider party, the data being stored in an encrypted form requiring an access key to decrypt in a first transaction on a blockchain, the method including the steps of: communicating, by a computing device of the consumer party, to the provider party for recording on the blockchain a second transaction, the second transaction specifying a payment for the data and further including an identifier of the first transaction and a signal indicating a request for the data; and, in response, the second party broadcasting a third transaction including an encrypted password for recording on the blockchain. inspecting the blockchain to read the encrypted password from the third transaction, the password being encrypted based on a shared secret between the consumer party and the provider party, and the access key being a first predetermined function of the password; decrypting the received password based on the shared secret, determining the access key by applying the predetermined function to the decrypted password, and decrypting the data based on the determined access key; The data is included in the second transaction along with a message authentication code that is a second predetermined function of the password, the second predetermined function also being a function of the data. The method further includes calculating the message authentication code based on the decrypted data and the determined password, and comparing the calculated message authentication code with the message authentication code included in the first transaction to authenticate the data.

[0217] In embodiments, communicating the second transaction may include communicating the second transaction to the second party via a side channel.

[0218] In embodiments, communicating the second transaction may include communicating the second transaction in a template format for the provider party to complete and broadcast to be recorded on the blockchain.

[0219] In embodiments, a completed version of the second transaction may be the third transaction, the completion including adding the encrypted password.

[0220] In embodiments, the first predetermined function may also be a function of the providing party's public key. For example, in embodiments, the first predetermined function may include the following:

number

[0221] In embodiments, the message authentication code may be a hash-based message authentication code and the second predetermined function is a hash-based function. The hash-based function may include one or more hashes.

[0222] According to another aspect disclosed herein, a set of transactions for recording in a blockchain, the set embodied on one or more computer-readable data media, a data storage transaction including data in an encrypted form that requires an access key to decrypt, said data storage transaction including a message authentication code that is a predetermined function of a password and of said data; one or more further transactions, at least one of which specifies payment for the data and includes an identifier of the first transaction and a signal indicating a request for the data; Including, A set is provided in which at least one of the one or more further transactions includes a password encrypted based on a shared secret shared between a consumer party and a provider party, and the access key is a predetermined function of the password.

[0223] In an embodiment, the set of transactions may be further configured according to any of the above-described embodiments.

[0224] According to another aspect disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to perform a method according to any of the embodiments disclosed herein when executed on a computing device of a consumer party.

[0225] According to another aspect, there is provided a party device, comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, An apparatus is provided, wherein the memory stores code configured to execute on the processing device, the code being configured, when executed, to perform a method according to any embodiment disclosed herein.

[0226] According to another aspect disclosed herein, a method may be provided that includes operation of a consumer party, a provider party, any third parties that may be involved, and / or a network of nodes.

[0227] According to another aspect disclosed herein, a system may be provided that includes a consumer party's computer equipment, a provider party's computer equipment, any third party's computer equipment, and / or a network of nodes.

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

Claims

1. 1. A method for a consumer party to access data from a provider party, the data being stored in an encrypted format requiring an access key to decrypt in a first transaction on a blockchain, the method comprising: communicating to the provider party a second transaction for recording on the blockchain, the second transaction specifying a payment for the data and further including an identifier of the first transaction and a signal indicating a request for the data; and in response to the second party broadcasting a third transaction including an encrypted password for recording on the blockchain, inspecting the blockchain to retrieve the encrypted password from the third transaction, the password being encrypted based on a shared secret between the consumer party and the provider party, and the access key being a first predetermined function of the password; decrypting the received password based on the shared secret, determining the access key by applying the predetermined function to the decrypted password, and decrypting the data based on the determined access key, wherein the data is included in the first transaction together with a message authentication code that is a second predetermined function of the password, and the second predetermined function is also a function of the data; Including, The method further includes calculating the message authentication code based on the decrypted data and the determined password, and comparing the calculated message authentication code with the message authentication code included in the first transaction to authenticate the data.

2. The method of claim 1 , wherein communicating the second transaction comprises communicating the second transaction to the second party via a side channel.

3. 3. The method of claim 2, wherein communicating the second transaction comprises communicating the second transaction in a template format for the provider party to complete and broadcast the second transaction to be recorded on the blockchain.

4. 4. The method of claim 3, wherein a completed version of the second transaction is the third transaction, and the completion includes adding the encrypted password.

5. The method according to any of claims 1 to 4, wherein the first predetermined function is also a function of the public key of the providing party.

6. The method of any of claims 1 to 5, wherein the message authentication code is a hash-based message authentication code and the second predetermined function is a hash-based function.

7. A computer program embodied on a computer readable storage device and adapted to carry out the method according to any of claims 1 to 6 when executed on a consumer party's computing equipment.

8. A consumer party device comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, An apparatus, wherein the memory stores code configured to run on the processing device, the code being configured, when executed, to perform a method according to any one of claims 1 to 6.

Images