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] This disclosure relates to the use of transactions in a blockchain for recording and communicating additional data content, such as documents or images. [Background technology]

[0002] A blockchain is a form of decentralized data structure where copies of the blockchain are maintained on each of several nodes in a peer-to-peer (P2P) network. A blockchain contains a chain of blocks of data, each containing one or more transactions. Each transaction may refer to a preceding transaction in a sequence that can span one or more blocks. Transactions can be submitted to the network to be included in a new block. New blocks are generated through a process known as "mining." Mining involves multiple mining nodes competing to perform "proof-of-work," that is, solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Each node in the network can have any one, two, or all three roles of 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 copy of the mined blocks on the blockchain. To have a transaction recorded on the blockchain, a party sends the transaction to one of the nodes in the network to propagate it. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to adhere to the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not mined into blocks. Assuming a transaction has been verified and thus accepted into the blockchain, the transaction (including any user data) is therefore stored on 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," which generates a new amount of digital assets. Proof-of-work encourages miners not to cheat the system by including double-spending transactions in their blocks, as mining a block requires a massive amount of computing resources, and blocks containing double-spending 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 available output includes an element that specifies the value of a digital asset, sometimes called a UTXO ("unspent transaction output"). An output may further include a lock 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 unlock script for unlocking the lock script of the pointed output. Thus, when we consider a pair of transactions, we refer to them as the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output that includes a lock script specifying the value of a digital asset and defining one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0006] In this 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 satisfies all of one or more conditions defined in the lock script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. Any node that finds a target transaction invalid due to any of these conditions will not propagate the transaction, nor will it mine it to include it in a block for recording on the blockchain.

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

[0008] Traditionally, transactions within a blockchain have been used to transmit digital assets, i.e., data that functions as a store of value. However, blockchains can also be used to add additional functionality on top of them. For example, blockchain protocols may allow for the storage of additional user data in the output of a transaction. Modern blockchains have increased the maximum data capacity that can be stored within a single transaction, enabling the incorporation of more complex data. For example, this could be used to store electronic documents, or audio or video data, within the blockchain. [Overview of the project]

[0009] As blockchains become more widespread and more resources are stored on-chain, they are becoming a rival to the World Wide Web as a framework for storing, publishing, and securely communicating resources such as text, images, and audio. For example, Metanet is one such framework implemented by blockchain.

[0010] However, as blockchain grows and is increasingly used as a means of storing and transmitting content, finding desired resources on the chain is also becoming increasingly difficult. This could hinder the use of blockchain-based systems as a medium for communicating content.

[0011] To resolve this, according to one aspect disclosed in this specification, a method is provided which is carried out by a consumer party's computer equipment, a) A step of accessing at least a first document that contains one or more hyperlinks, wherein each hyperlink includes a respective piece of anchor content and a respective identifier of the respective destination associated with each piece of anchor content, b) A step of rendering the content of at least a portion of the first document through the user output device of the consumer party's computer equipment, the step of rendering the anchor content of one or more of the hyperlinks, c) The steps of receiving user input through the user input device of the consumer party's computer equipment, by selecting one of the hyperlinks by selecting each anchor content from the rendered content, d) In response to the user input, the step of automatically accessing data from the associated destination based on the respective identifiers contained in the first document, Includes, A method is provided in which at least each destination of the selected hyperlink includes a destination transaction in a blockchain maintained across at least several nodes of the blockchain network, and access to the data includes the step of examining 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 and may be described in a markup language such as HTML, but is reinforced by additional types of tags that link transactions. One or more data items in one or more of the destination transactions may include one or more further documents, such as one or more further hypertext documents that may themselves include one or more further forward hyperlinks.

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

[0014] In an output-based model, documents or other such data content may be stored in their respective unusable outputs, such as outputs made unusable by OP_RETURN.

[0015] For an alternative or additional purpose, it is desirable to provide a mechanism that integrates payment with data transfer in a way that guarantees that the provider party receives payment and the consumer party receives 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 a first transaction on a blockchain in an encrypted form that requires an access key for decryption. The method is performed by the consumer party's computer device, i) communicating a second transaction to the provider party for recording on the blockchain, the second transaction specifying 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 a second party broadcasting a third transaction including an encrypted password for recording on the blockchain ii) 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, 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 together 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 iv) 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.

[0017] This may be used together with or separately from the first aspect. **Brief Description of the Drawings**

[0018] To assist in understanding the embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made, by way of example only, to the following accompanying drawings. [Figure 1] A schematic block diagram of a system for implementing a blockchain. [Figure 2] This provides a schematic overview of some examples of transactions recorded on the blockchain. [Figure 3] This is a schematic block diagram of another system for implementing blockchain. [Figure 4] This is a schematic block diagram of the client application. [Figure 5] This is a schematic representation of an exemplary user interface presented by the client application shown in Figure 4, according to the embodiments disclosed in this specification. [Figure 6A] A schematic representation of an exemplary set of transactions according to the embodiments disclosed in this specification is shown below. [Figure 6B] A schematic representation of an exemplary set of transactions according to the embodiments disclosed in this specification is shown below. [Figure 7] This is a flowchart of a method for providing a session key according to the embodiments disclosed in this specification. [Figure 8] This is a schematic block diagram showing a hypertext transfer protocol according to an embodiment disclosed in this specification. [Figure 9] The structure of an exemplary pair of request and response transactions according to embodiments disclosed in this specification is shown. [Figure 10] This is a flowchart of a method for storing encrypted data on a blockchain according to embodiments disclosed in this specification. [Figure 11] An example of a data exchange procedure according to the embodiments disclosed in this specification is shown in the flowchart. [Modes for carrying out the invention]

[0019] Blockchain offers a decentralized, tamper-resistant alternative to traditional database servers. However, as block capacity increases to accommodate more data storage, a data retrieval system is desired to efficiently access information stored on the blockchain. Traditionally, the only ways to access information used on a blockchain have been to have a specific transaction reference or to search the entire blockchain (currently 168GB on some common blockchains, and this is expected to increase rapidly with the increase in block size). More recently, methods for organizing data on the blockchain have been proposed as part of Metanet. Other solutions that can query data stored on the blockchain have also been proposed, including bitDB and the B: / / bitcoin data protocol. However, it is desirable to have more tools to help find relevant data on the chain.

[0020] Currently, the World Wide Web (WWW) enables us to navigate the internet and efficiently retrieve information through a series of links between documents (web pages). The standard protocol for linking such information, Hypertext Transfer Protocol (HTTP), uses hyperlinks (references to data) to establish connections between pages located in a database or server. Users make requests to the server by clicking on hyperlinks, and the server returns the requested information, which is then displayed to the user as hypertext (text with hyperlinks).

[0021] The following embodiments provide a protocol for reading and displaying encrypted data from organized, linked data stored on a blockchain. Many files may be linked within a series of domain redirects and stored in OP_RETURN data (which may be certified by miners if necessary). A smart wallet can decrypt and decompress the data for presentation to the user. For example, the embodiments may utilize the speed and efficiency of XOR encryption schemes 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 address 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 be used to set peer seed data for P2P file sharing for large files (e.g., multimedia files), streams, or messages.

[0022] <Overview of an example system> Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 includes a packet-switched network 101, which is typically a wide-area internet such as the internet. The packet-switched network 101 includes a plurality of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device having 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 devices in the form of one or more non-temporary 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, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disc drives.

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

[0024] At least some of the nodes 104 assume the role of forwarding nodes 104F, which forward and propagate transaction 152. At least some of the nodes 104 assume the role of miners 104M, which mine block 151. At least some of the nodes 104 assume the role of memory nodes 104S (also called "full-copy" nodes), each node storing its own copy of the same blockchain 150 in its own memory. Each miner node 104M also maintains a pool 154 of transaction 152 waiting to be mined and made into block 151. A given node 104 can be a forwarding node 104, a miner 104M, a memory node 104S, or any combination of two or all of these.

[0025] In a given current transaction 152j, each input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. Generally, a preceding transaction can be any transaction in pool 154 or any block 151. The preceding transaction 152i does not necessarily have to exist when the current transaction 152j is generated or sent to network 106, but it must exist and be verified for the current transaction to be valid. Thus, in this specification, "preceding" refers to something that precedes in a logical sequence linked by pointers, and does not necessarily refer to the time of generation or transmission in a time series. Therefore, it does not necessarily preclude transactions 152i and 152j from being generated or sent out of order (see the following discussion of orphan transactions). The preceding transaction 152i can also be called the antecedent or predecessor transaction.

[0026] The input to the current transaction 152j includes the signature of user 103a, whose output of the preceding transaction 152i is locked. Furthermore, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Therefore, the current transaction 152j can transfer the amount defined by the input of the preceding transaction 152i to the new user 103b defined by the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs, and the input amount may be divided among multiple users (one of whom becomes the original user to make the change). In some cases, a transaction may have multiple inputs, and the amount can be aggregated from multiple outputs of one or more preceding transactions and redistributed to one or more outputs of the current transaction.

[0027] The above is sometimes called an "output-based" transaction protocol, and sometimes also called an "unspent transaction output (UTXO) type protocol" (where the output is called a UTXO). Instead of a user's total balance being defined by a single number stored on the blockchain, the user requires a special "wallet" application 105 to match the values ​​of all of their UTXOs, which are distributed across many different transactions 152 within blockchain 151.

[0028] As part of an account-based transaction model, another type of transaction protocol is sometimes referred to as an "account-based" protocol. In an account-based protocol, each transaction is transferred by referencing the absolute account balance, rather than defining the amount transferred by referencing the UTXO of a preceding transaction in a previous sequence of transactions. The current state of all accounts is stored and constantly updated by miners separate from the blockchain. In such a system, transactions are placed using a continuous transaction record of the account (a 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 arbitrary data field can also sign a transaction. This data field may point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0029] In either type of transaction protocol, if user 103 wants to execute a new transaction 152j, the user sends the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently usually a server or data center, but in principle, it can be any other user terminal). This node 104 checks whether the transaction is valid according to the node protocol applicable 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 they form the overall transaction model. Typically, the node protocol requires node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may involve checking that the 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, the condition typically includes checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i that the input of the new transaction points to. In some transaction protocols, the condition may be defined, at least partially, by a custom script included in the input and / or output. Alternatively, it may be fixed solely by the node protocol, or by a combination of these. In any case, if the new transaction 152j is valid, the current node forwards the new transaction to one or more other nodes of node 104 in the P2P network 106. At least some of these nodes 104 also function as forwarding nodes 104F, such as forwarding the new transaction 152j to one or more further nodes 104, applying the same tests according to the same node protocol.In this way, the new transaction is propagated throughout the entire network of node 104.

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

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

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

[0033] It should be noted that 104M different miners, constantly competing to solve the puzzle, may be solving it based on different snapshots of the unmined transaction pool 154, depending on when they started looking for the solution. Whoever solves the puzzle first defines transaction 152 to be included in the next new block 151n, updating the current unmined transaction pool 154. The 104M miners then continue their competition to create a block from the newly defined unsolved pool 154. There are also protocols to resolve any "forks" that may occur. This happens when two 104M miners solve the puzzle to each other in a very short time, and conflicting views of the blockchain propagate. In short, whenever the branches of a fork grow, the longest one will become the final blockchain 150.

[0034] In most blockchains, the winning miner (104M) is automatically rewarded by a special type of new transaction that creates a new amount of digital assets out of thin air (whereas a normal transaction transfers an amount of digital assets from one user to another). Thus, the winning node can be 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 the new block 151n. This reward incentivizes the miner (104M) to participate in the proof-of-work competition. Often, a normal (non-generation) transaction specifies an additional transaction fee in one of its outputs to further reward the winning miner (104M) who generated the block 151n containing that transaction.

[0035] Due to the computing resources involved in mining, typically each of the miner nodes 104M takes the form of a server or an entire data center, including one or more physical server units. 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 processing unit of node 104 in order to perform one or more roles and process transaction 152 in accordance with the node protocol. It will be understood that any operation belonging to node 104 may be performed by software running on the processing unit of the respective computer device. The node software may be implemented in one or more applications in the application layer, or in lower layers such as the operating system layer or protocol layer, or any combination thereof. Furthermore, 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] Furthermore, the network 101 is also connected to the computer devices 102 of several parties 103, each acting as a consumer user. These play the roles of payer and payee in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute mining protocols. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and several second parties 103b and their respective computer devices 102b. Many more such parties 103 and their respective computer devices 102 can exist and participate in the system, but for convenience, they are not shown. Each party 103 may be an individual or an organization. Purely for illustrative purposes, the first party 103a is referred to herein as Alice, and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that references to Alice or Bob herein can be replaced with "first party" and "second party," respectively.

[0038] Each computer device 102 of Party 103 comprises one or more processors, each processing unit having, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage devices in the form of non-temporary computer-readable media or media. This memory may include one or more memory units using, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disc drives. The memory on each computer device 102 of Party 103 stores software, each containing at least one instance of a client application 105 arranged to run on the processing unit. It will be understood that any operation belonging to a given node 104 can be performed by using software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. A given computer device 102 of party 103 may include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0039] The client application 105 may first be provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage media, such as those downloaded from a server, or on removable storage devices such as removable SSDs, flash memory keys, removable EEPROMs, removable magnetic disk drives, magnetic floppy disks or tapes, optical disks, such as CDs or DVD ROMs, or removable optical drives.

[0040] The client application 105 has at least a “wallet” function, which primarily has two functions. One of these is to enable each user party 103 to create, sign, and send transactions 152 that are propagated across the entire network of nodes 104 and thereby included in blockchain 150. The other is to report the amount of digital assets currently owned to each party. In an output-based system, this second function includes matching the amount defined in the outputs of various transactions 152 scattered throughout blockchain 150 belonging to that party.

[0041] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting. Instead, any client function described in this specification may be implemented in a suit of two or more different applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, or in a lower layer such as an operating system, or any combination thereof. The following description will be from the perspective of client application 105, but this is not to be understood as limiting.

[0042] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the transfer nodes 104F of the P2P network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transaction to which each party 103 is the recipient (or, in this embodiment, inspect the transactions of other parties within the blockchain 150, as the blockchain 150 is a public facility that provides trust in transactions through its public visibility). The wallet function on each computer device 102 is configured to form and send transaction 152 according to the transaction protocol. Each node 104 runs software configured to verify transaction 152 according to the node protocol, and in the case of a transfer node 104F, it forwards transaction 152 to propagate it 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 within blockchain 150 (however, the transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 within network 106 (however, many nodes may handle different transaction subtypes differently according to rules defined for their subtypes, and different nodes may assume different roles and thus implement different corresponding aspects of the protocol).

[0043] As described above, blockchain 150 contains a chain of blocks 151, each block 151 containing a set of one or more transactions 152 created by the proof-of-work process, as previously stated. Each block 151 also contains a block pointer 155 that points backward to a previously generated block 151 in the chain, defining the sequential order to block 151. Blockchain 150 also contains a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the generating transaction) contains a pointer to a previous transaction to define the order of the sequence of transactions (note: the sequence of transactions 152 is allowed to branch). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than a preceding transaction.

[0044] If a given party 103, for example Alice, wants to send a new transaction 152j to be included in blockchain 150, she will form the new transaction (using the wallet function of her client application 105) according to the relevant transaction protocol. Next, she will send transaction 152 from her client application 105 to one of the one or more transfer nodes 104F to which she is connected. For example, this may be the transfer node 104F closest to or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it will process it according to the node protocol and its respective role. This will first involve checking whether the newly received transaction 152j satisfies certain conditions for being "valid," an example of which will be briefly detailed. In some transaction protocols, the conditions for verification may be configurable on a per-transaction basis by a script included in transaction 152. Alternatively, the conditions may simply be built-in functions of the node protocol, or they may be defined by a combination of scripts and the node protocol.

[0045] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., is "valid"), any storage node 104S that receives transaction 152j adds the newly valid transaction 152 to pool 154 in the copy of blockchain 150 maintained on node 104S. Furthermore, any transport node 104F that receives transaction 152j propagates the verified transaction 152 to one or more other nodes 104 in the P2P network 106. Since each transport node 104F applies the same protocol, assuming transaction 152j is valid, this means it will soon propagate throughout the entire 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 the puzzle for part of the pool 154 that includes Alice's transaction 152j). Once the 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 unmined 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. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments.

[0049] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may include an unused transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies the amount of digital asset (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 an indicator of the sizes of the input fields 202 and the output fields 203. The header 201 may also include the ID of the transaction. 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 unprocessed transaction 152 submitted to the miner 104M.

[0050] For example, suppose Alice103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This takes the amount of the digital asset locked in 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 simply arbitrary labels. They do not necessarily mean that Tx0 is the first transaction on blockchain 151, or that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has a locked unused output 203 to Alice.

[0051] The preceding transaction Tx0 may already be validated and included in blockchain 150 by the time Alice creates its new transaction Tx1, or at least by the time she sends it to network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in pool 154, in which case it will be immediately included in the new block 151. Alternatively, Tx0 and Tx1 may be generated and sent to network 102, or Tx0 may be sent after Tx1 if the node protocol allows buffering of "orphan" transactions. The terms “preceding” and “following” as used here in the context of transaction sequences refer to the order of transactions in a sequence defined by transaction pointers specified within the transactions (such as which transaction points to which other transactions). They can be equally replaced by “preceding” and “inheriting” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily mean the order in which they are created, sent to network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (descendant transaction, or "child") that points to a preceding transaction (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. Depending on the node protocol and / or the actions of the miner, it may be discarded or buffered for a certain period of time to wait for its parent.

[0052] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO labeled herein as UTXO0. Each UTXO contains a value specifying the amount of digital asset represented by the UTXO and a lock script defining the conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and therefore for the UTXO to be successfully redeemed. Typically, the lock script locks the amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script typically defines the following unlock conditions: The unlock script in the subsequent transaction's input contains the cryptographic signature of the party to which the preceding transaction was locked.

[0053] The lock script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the Node protocol. A specific example of such a language is called "script" (S capitalized). The lock script specifies the information necessary to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information necessary to satisfy the criteria of the lock script. For example, it may include Bob's signature. The unlock script appears in the transaction input 202.

[0054] In the illustrated example, UTXO0 of output 203 of Tx0 is the lock script [ChecksigP A This includes Alice's signature SigP, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid). A[ChecksigPA] contains the public key PA from Alice's public and private key pair. Input 202 of Tx1 contains a pointer to Tx1 (e.g., by its transaction ID, by TxID0 which is the hash of the entire transaction Tx0 in an embodiment). Input 202 of Tx1 contains an index that identifies the UTXO0 in Tx0 in order to identify it among any other possible outputs of Tx0. Input 202 of Tx1 further contains an unlock script containing Alice's cryptographic signature, which is created by Alice applying Alice's private key from the key pair to a given portion of the data (sometimes called a "message" in cryptography). <sigpa>This includes the data (or "message") that Alice needs to sign in order to provide a valid signature, which may be defined by the lock script, the node protocol, or a combination thereof.

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

number

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

[0057] Node 104 considers Tx1 valid 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). If it is a mining node 104M, this means adding it to the pool of transactions 154 awaiting proof-of-work. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in network 106, thereby propagating it throughout the network. Once Tx1 is validated and included in blockchain 150, it is defined as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unused transaction output 203. If Tx1 attempts to consume an output already consumed by another transaction 152, it 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 used (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important that blockchain 150 imposes a defined order on transaction 152. In practice, a given node 104 could maintain a separate database marking the UTXO 203 that transaction 152 has consumed, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction within 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 is not propagated and is not mined into block 151.

[0059] In a UTXO-based transaction model, it's important to note that a given UTXO must be used as a whole. You cannot "reserve" a portion of the amount defined in a UTXO while another portion is being consumed. However, the amount from a UTXO can be split across multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split across multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to either give herself change in a second output of Tx1 or pay another party.

[0060] In practice, Alice usually needs to include a fee for the winning miner, because nowadays, the reward for generated transactions alone is usually not enough to incentivize mining. If Alice does not include a fee for the miner, Tx0 is likely to be rejected by the miner node 104M, and therefore, although technically valid, it will still not propagate and will not be included in blockchain 150 (the miner protocol does not force 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 output 203 of a given transaction 152 is automatically given 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 digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference is automatically given to the winning miner, 104M. However, this does not necessarily preclude the option to explicitly specify a miner fee in one of the UTXO203 of transaction 152, either as an alternative or additional measure.

[0061] Alice and Bob's digital assets consist of unused UTXOs locked to them in any transaction 152 within blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout blockchain 150. Nowhere within blockchain 150 is there a single number that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to aggregate the values ​​of all the various UTXOs locked to each party that have not yet been consumed in another future (onward) transaction. This can be done by querying a copy of blockchain 150 stored in one of the storage nodes 104S, for example, the storage node 104S closest to or best connected to each party's computer equipment 02.

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

[0063] A signature PA is a digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. A digital signature signs specific data. In embodiments, for a given transaction, the signature signs a portion of the transaction input and all or part of the transaction output. The specific portion of the output to be signed depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature that selects which output is signed (and is therefore fixed at the time of signing).

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

[0065] <Optional side channel> Figure 3 shows a further system 100 for implementing blockchain 150. System 100 is substantially the same as that described in relation to Figure 1, except that it includes additional communication functionality. The client applications present on Alice and Bob's computer devices 102a and 102b, respectively, each include additional communication functionality. That is, it allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the invitation of either party or a third party). The side channel 301 allows for the exchange of data separately from the P2P network. Such communication is sometimes called "off-chain". For example, it may be used to exchange transaction 152 between Alice and Bob without the transaction being issued to the network P2P 106 (yet) or being done so on chain 150, until one of the parties chooses to broadcast the transaction to network 106. Alternatively or additionally, the side channel 301 may be used to exchange data related to any other transaction, e.g., keys, amounts or terms to be negotiated, data content, etc.

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

[0067] <Client Software> Figure 4 shows an exemplary implementation of a client application 105 for implementing an embodiment of the scheme of the present disclosure. The client application 105 includes a transaction engine 404 and a user interface (UI) layer 401. The transaction engine 404 is configured to implement transaction-related functions underlying the client 105, such as receiving and / or transmitting transaction and / or other data via a side channel 301 and / or transmitting the transaction so that it is propagated through a P2P network 106, in accordance with the scheme described above and as will be 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 in this specification as a hypertext SPV wallet. The functions of these various modules will be discussed in more detail shortly.

[0068] The UI layer 401 is configured to render a user interface, including outputting information to each user 103 via the user input / output (I / O) means of each user computer device 102 and receiving input from each user 103 via the user input means of each user computer device 102. For example, the user output means may include one or more display screens (touch or non-touchscreens) that provide visual output, one or more speakers that provide audio output, and / or one or more haptic output devices that provide haptic output, etc. The user input means may include, for example, one or more touchscreen input arrays (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 conversation or speech recognition algorithms that receive conversation or voice input, one or more gesture-based input devices that receive input in the form of manual or body gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0069] Note: While various functions may be described in this specification as being integrated into the same client application 105, this is not necessarily limiting. Instead, they may be implemented in a suit of two or more different applications, for example, one being a plug-in to the other, or interfaced via an API (application programming interface). For example, any function of modules 401, 402, 403, 404, and 405 may be implemented in any combination in two or more separate applications. Furthermore, no exclusion is made from the possibility that some or all of the described functions may be implemented, for example, at the operating system layer. Wherever this specification refers to a single or given application 105, etc., it should be understood that this is merely an example, and more generally, that the described functions may be implemented in any form of software.

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

[0071] In embodiments, UI 500 may include a hyperdocument rendered by the hypertext engine 403 through the UI layer 401. The term “hyperdocument” as used in this specification refers to any document that includes one or more hyperlinks anchored by any piece of anchor content 502, such as text or still images or videos. A document may be called a hypertext document if at least one of the links is anchored by a piece of text.

[0072] Each hyperlink includes a user-selectable UI element 502 called anchor content. 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, the UI layer 401 signals the selection to the hyperdocument engine 402, which in turn triggers the respective link to the respective destination.

[0073] It is understood that the specific means of rendering various UI elements and selecting hyperlinks are not important. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that UI 500 shown in Figure 5 is merely a schematic representation, and in reality, it may include one or more additional UI elements that are not shown for brevity. Hyperdocument 501 may be of a different format and may contain a different number 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. Built from existing hypertext protocols, the following discloses a blockchain-based hypertext protocol that uses a novel hypertext SPV wallet to read data embedded in transactions. In embodiments, the wallet may incorporate a blockchain program launcher to decrypt and display data embedded in transactions. Furthermore, embodiments may incorporate a secure end-to-end cryptographic scheme into the system to enable the transfer of sensitive data.

[0075] This disclosure provides a hypertext document 500 or other such hyperdocument for use in blockchain storage functionality. In embodiments, this operates in a manner similar to conventional 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 recipient. Of course, it is understood that the same or similar techniques can be applied with necessary modifications by reversing the roles of the Consumer Party and the Provider Party, or between other combinations of parties as Consumer Party and Provider Party. As stated above, each party may be an individual or an organization such as a company, academic research institute, government body, or charitable organization. Provider Party 103a may also be referred to as the "Service Provider" in this specification, but this does not necessarily mean a company or an organization of more than one person.

[0076] The following various operations may be described as being performed by consumer party 103b and service provider 103a. It is understood that this may be used as an abbreviation meaning that the operations are performed by the respective software 105a and 105b running on the respective computer equipment 102a and 102b of each party 103a and 103b.

[0077] As described above, consumer party 103b reads the hyperdocument 501 from storage and renders it through the UI layer 401 of their client software 105b. In some embodiments, the hyperdocument 501 may be read from storage on the consumer party's own computer 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 the blockchain network 106, for example, the Internet, or via another network such as consumer party 103b's private local area network. In other embodiments, the hyperdocument 501 may be read from a website on the World Wide Web. If the packet-switched network 101 is the Internet, the document 501 may again be accessed via the same physical network as the blockchain network 106.

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

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

[0080] As shown in Figure 6A, in an output-based model, source transaction 152S includes at least one input 202S that reverses some other preceding transaction (not shown). For example, the preceding transaction could be another transaction from the same service provider Alice, and / or a dust amount (a negligible amount). Thus, the service provider only needs to pay a mining fee to actually place source transaction 152S on blockchain 150. Source transaction 152S also includes at least one output 203S1, which in embodiment takes the form of an unavailable output. For example, using a scripting language, this may be implemented by including an OP_RETURN opcode in the lock script of output 203S1 that, when executed on node 104 of blockchain network 150, terminates the script. This makes the output available instead of carrying arbitrary payload data. In embodiment, this is used to store source hyperdocument 501. Most transaction protocols also require that a transaction have at least one available output 203S0. This can specify a refund to the service provider and / or a dust payment. In this embodiment, the output may be called a UTXO. The source transaction 152S is here a TxID. S It also includes header field 201S, which contains the source transaction ID labeled as such.

[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, such as enabling payload data in unusable output 203S0 or not requiring all transactions to have usable outputs. Other scripting languages ​​may have other opcodes for generating unusable outputs. Alternatively, hyperdocument 501 may be included in the smart contract field of a transaction in an account-based model.

[0082] The following description assumes that source hyperdocument 501 is stored in and accessed from the unavailable output 203S1 of source transaction 152 in an output-based model, but this is not an limitation. More generally, the same technology regarding the content and functionality of hyperdocument 501 can be applied even if it is stored in a different type of transaction or off-chain.

[0083] A hyperdocument 501 is a document that contains one or more hyperlinks. As shown in Figure 6A, a hyperlink includes at least three parts: a piece of anchor content 502 (sometimes simply called an "anchor"), a destination identifier 601 where the linked data content item 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 written in a markup language such as HTML, the code elements take the form of one or more tags, which tag each anchor content 502 with its respective identifier 601, allowing it to act as the front end of the link. The anchor content 502 is the user-visible part of the link and also acts as user control through which the user can access the link. If the anchor content of at least one hyperlink contains text, the hyperdocument 501 may be called a hypertext document. However, this does not preclude the fact that the anchor content of one or more hyperlinks may, as an alternative or additional, contain other forms of content, such as still images or videos.

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

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

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

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

[0088] HTML is a standard language for designing web pages and includes instructions for displaying content (e.g., headings, fonts, images, etc.) and hyperlinks (links to other web pages in the format expected by HTTP, such as "http: / / www.DOMAIN / PAGE"). The blockchain hypertext document 501 disclosed in this specification may include the same HTML commands for display:

number

number

[0089] FIG. 6A shows an example of one destination transaction 152D1 according to an embodiment. In an embodiment that utilizes an output-based model, the destination transaction 152D1 includes at least one input 202D that points back to some other preceding transaction (not shown). For example, the preceding transaction of the destination transaction 152D1 can be another transaction of the same service provider Alice and / or a dust amount (negligible amount). Note that the input 202D1 of the destination transaction 152D does not have to use the output 203S0 of the source transaction 162S (source in the sense of the source of the hyperdocument 501). However, it is not excluded either. The source transaction 152D1 also includes at least one output 203D11 that takes the form of an unusable output in an embodiment. For example, using a Script language, this can also be implemented here by including an OP_RETURN opcode in the lock script of the output 203S1. In an embodiment, this unusable output 203D,11 is used to store the destination data 603. In most transaction protocols, a transaction is also required to have at least one usable output 203D10. This can also specify a refund to the service provider and / or a dust payment here. In an embodiment, the output can also be referred to as a UTXO here. The destination transaction 152D1 includes a header field 201D1 that includes each D of the destination transaction I labeled with D1 TxID

[0090] Other formats, transaction protocols, or transaction models for 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, such as enabling payload data in unusable output 203D10 or not requiring all transactions to have usable outputs. Other scripting languages ​​may have other opcodes for generating unusable outputs. Alternatively, destination data 603 may be included in the smart contract field of the transaction in an account-based model.

[0091] The following is explained in terms of the fact that destination data 603 is contained in an unavailable output 203D1 of at least one destination transaction 152D on the blockchain in an output-based model, but this is not limited and it is understood that more generally, the same technique regarding data 603 can be applied when the data is stored in different types of transactions on other types of blockchains.

[0092] In an embodiment, the source hyperdocument 501 may contain multiple hyperlinks. One or more of these may be links to destination transaction 152D on blockchain 150. In an embodiment, one or more others may be conventional links to URLs. In an embodiment, the source hyperdocument 501 may contain multiple hyperlinks to different destination transactions 152D1, 152D2 on blockchain 150. Two are shown in Figure 6A for illustrative purposes, but it is understood that other numbers may exist. Thus, the hyperdocument 501 can function as a kind of index to resources stored in multiple other transactions 152D1, 152D2, etc.

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

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

[0095] The destination data 603 can be substantially any type of content, i.e., payload data or user content (as opposed to elements of transaction 152D that relate to how they function as a transaction on the blockchain network 106). For example, destination data 603 may include text, one or more still images or videos, and / or audio content. It may take the form of another document or file. In embodiments, the destination data in at least one of the destination transactions 152D may include another hyperdocument, e.g., a hypertext document, which includes one or more further hyperlinks and / or URLs leading to one or more further transactions 152. Different data 603 may be included in different transactions of the destination transactions 152D.

[0096] When consumer user 103b selects one of the hyperlinks anchor 502 that links to a destination transaction 152D on blockchain 152 (for example, by clicking or touching it), the hyperdocument engine 402 triggers the data transfer engine 403 to execute a set of actions to read destination payload data 603 from the relevant fields (e.g., unavailable output 203D11) of each destination transaction 152D (e.g., 152D1) based on the respective transaction ID 601 as a read from the hyperlink. This includes accessing each destination transaction 152D1 from one of the storage nodes 104S on blockchain network 106 via the physical network 101 (e.g., the internet) on which blockchain network 106 is implemented.

[0097] In embodiments, in an output-based model, the hyperlink may also include an identifier for the specific output in which the data is stored. For example, the hyperlink may include the transaction TxID. D1 Output 1 (203D11) may be specified. In this case, the output identifier is read from the hyperlink and is also used to identify the data. However, this is not mandatory. Alternatively, the data transfer engine 403 may be configured to always read data from the same predetermined output number of the destination transaction (for example, assumed to always be stored in output #1). Or, more generally, in other models, the data may be stored in a specific predetermined location within the data structure of destination transaction 152D. Another alternative is that the data transfer engine 403 may be configured to search the data structure of destination transaction 152D for outputs or for data marked in a predetermined form or format, for example for any output 203 containing OP_RETURN, or for some other predetermined marker.

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

[0099] Alternatively or additionally, the hyperdocument engine 402 itself, or a part thereof, may take the form of a module of program code already pre-downloaded from another transaction 152 (not shown) on blockchain 150 (for example, from an unusable output such as a UTXO containing OP_RETURN). In this case, the code in question is accessed by some other means other than selecting a hyperlink, and the program launcher 405 is configured to execute this part of the code in order to implement the aforementioned functions of the hyperdocument engine 402.

[0100] In some embodiments, the destination data 603 may be unencrypted and freely available. In this case, the data transfer engine 403 can simply read the data 603 from each destination transaction 152D. The data may also be compressed using, for example, 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 to be rendered to user 103b, such as text or image data, the data transfer engine 403 then has it rendered through UI layers 401 and UI 500. If the destination data 603 includes a hyperdocument, such as a hypertext document, this may include rendering it by 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 as an access key in this specification. In such embodiments, in response to the activation of each hyperlink, the data transfer engine 403 then decrypts each destination data 603 using the access key before decompressing or rendering each destination data 603 to the consumer user 103b.

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

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

[0104] Client transaction 152C serves one or both of two functions: firstly, to pay provider party 103a for data 603, and / or secondly, to signal a request to provider party 103a.

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

[0106] When consumer user 103b selects a hyperlink, in response, the data transfer engine 403 automatically generates a corresponding client transaction 152C and sends it to be received by service provider 103a.

[0107] In some 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 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 further broadcasts client transaction 152C to blockchain network 106 to be recorded on blockchain 150 in order 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 lacking one or more parts necessary to be recorded on chain 150, for example, service provider 103a's signature. In this case, the service provider 103a takes the necessary steps to add the missing parts, for example, by signing the transaction (for example, by signing a portion that includes one or more of the outputs 203C), before broadcasting it to the network 106. In the embodiment, the service provider 103a sends the access key to the consumer party 103a by, for example, malleating the client transaction to include the access key in the unavailable outputs, and broadcasting the malleated client transaction to be recorded on the 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 itself, so that client transaction 152C may be 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. Since the available output 203C0 of client transaction 152C is addressable to service provider 103a, this means she can find it on chain 150. Furthermore, since the transaction unlock script contains a cryptographic name which would require knowledge of Bob's public address and Bob's private key, it is identifiable that it originates from consumer Bob.

[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 via side channel 301 or by placing yet another transaction 152 on blockchain 150 (see below).

[0110] As described above, one way for service provider 103a (Alice) to provide consumer 103b with an access key is to publicly place it in yet another transaction (not illustrated) on blockchain 150. For example, here again, this can be done by placing it in an unusable output (e.g., a UTXO containing OP_RETURN) in an output-based model. The access key itself can here be stored in plaintext. However, this could make it impossible for anyone in the public to access data 603, even if a particular consumer 103b (Bob) meets the conditions for access (e.g., making a payment and / or meeting any other verification criteria such as his identity). To solve this, in an embodiment, 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 a selected group including at least 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 enable Bob to derive the access key. For example, Alice may place an encrypted password encrypted based on a shared secret on blockchain 150. The destination data 603 itself may be encrypted based on an access key, which is a function of the password (e.g., a function containing one or more hashes). In this case, once Alice verifies that she will receive Bob's payment and / or any other conditions for access, she makes the encrypted password available on blockchain 150. Bob accesses this, decrypts it based on the shared secret, then calculates an access key using the decrypted password, and decrypts the data using the access key.

[0112] Several exemplary implementations of the protocol described above will be explained in more detail shortly.

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

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

[0115] To implement this, existing transactions (that have been updated) may include at least available outputs (and potentially unavailable outputs under OP_RETURN, etc., if data is included). Once validated, available outputs are included in a set of UTXOs maintained by some or all of the memory and / or mining nodes 104S, 104M (e.g., typically stored by all miners and some memory nodes). To update, the available UTXOs of an existing transaction may be used, and the updated data may be included in a new transaction (e.g., again, in the new unavailable output of the new transaction using the OP_RETURN opcode, etc.). Once validated, this new transaction is now included in the set of UTXOs. Thus, the latest information is always available within the set of UTXOs maintained by each memory and / or mining node 104S / M. For example, one of the destination transactions 152D1 is updated by using that destination transaction 152D1 to generate a new destination transaction 152D1' (not shown) containing the updated data. The pre-existing source document 501 is still linked to the TxID under the destination transaction 152D1 below. However, when the hyperdocument engine 402 follows that link, in the embodiment it automatically retrieves it from one of the storage or mining nodes 104S / M via the UTXO set, regardless of whether there are any subsequent transactions using the linked destination transaction 152D1. If so, it automatically retrieves the data from the subsequent transaction instead.

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

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

[0118] When transmitting sensitive information such as personal details (name, address, banking information, medical data, etc.), it is desirable that further care be taken to ensure that the data is securely encrypted to prevent privacy breaches. In embodiments, 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, Alice(A) has secret key V A and public key P A =V A · G possesses private key V B and public key P B =V B Let G be a set of agreed-upon elliptic curve generator points. Alice can use Bob's public key to compute the secret as follows:

number

number

[0120] An example of such a procedure is shown below, and is also illustrated in Figure 7.

[0121] In step S1, Alice calculates the following:

number

number

[0122] In step S4, Bob receives Tx. When he receives it, B sends S Kx You don't need to use Tx to find out.

[0123] In step S5, Bob calculates the following:

number

number

[0124] Consumer Bob should note that he obtains key K by interacting with blockchain 150 itself (as opposed to the service provider system). That is, provider Alice places some cryptographic information on the chain that enables 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 a side channel 301.

[0125] It should also be noted 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] The following is an exemplary step-by-step procedure for a secure hypertext transfer to consumer party Bob103b to request data or files from blockchain network 106, following the schematic diagram of the process shown in Figure 8. In this particular example, the simplicity of computation allows this to be achieved within a transaction script of a UTXO-based model using the OP_XOR opcode.

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

[0128] In step T2, smart SPV406 negotiates a session key using a secure secret distribution protocol, such as an XOR-based key sharing protocol, to generate two private keys (S1 and S2). In one embodiment, consumer Bob negotiates the session key by interacting with blockchain 150 itself (as opposed to the 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 in 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 network 106. Thus, the request itself may be broadcast on-chain. Alternatively, however, if an existing relationship exists between Alice and Bob, side channel 301 may be used instead.

[0130] In step T4, the service provider (Alice) encodes the target data 603, compresses it (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 placed on-chain so that consumer Bob can read it from blockchain 150. Since it is addressed to Bob, he can find it on blockchain 150. Optionally, Alice can also signal to Bob via side channel 301 to alert him to the existence of the transaction.

[0131] To be addressed to Bob, this transaction may include a UTXO with a locked payment to the consumer Bob's address. This may be a dusty (negligible) amount, but by locking the output to Bob's address, he is notified of the transaction and in that transaction he knows the TxID he needs. Otherwise, Alice and Bob may need side channel 301 to communicate the TxID.

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

[0133] In step T6, the decrypted data is displayed to Bob via UI500. In this embodiment, this may be done using the blockchain program launcher 405.

[0134] The embodiment may utilize an SPV wallet 105b specifically designed as an intermediary between the client and the blockchain network. The use of the SPV wallet does not require large-scale data storage and enables secure use across devices. In some implementations, by performing Merkle proofs, the received data may be verified locally using only the block header, allowing smartphones and other mobile devices to connect to the service. This is a key feature of operating a smart wallet on an SPV node.

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

[0136] The first point is standard in conventional SPV wallets and therefore will not be discussed further here. However, the second point is that converting a hyperlink click into a transaction is not standard. As mentioned above, the hyperlink contains the transaction identifier and an actionable link. Clicking the link triggers the SPV to generate 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, the "request" signal, along with the desired transaction ID, can be included in the signed transaction. Using the protocol described above, the data can be encoded using OP_XOR and a mutually shared key. Similarly, the XOR operation can be used to decrypt the data, which can then be decompressed using an LZM dictionary and passed to the blockchain program launcher 405.

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

[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, where 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 blockchain network 106, a system is needed to process the requests, read the data, and then, preferably, compress the data within a transaction addressed to the client. The following discloses both centralized and decentralized solutions for data distribution. Through the decentralization of these processes, any peer can satisfy the requests, so such a system no longer relies 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 problems. Furthermore, by including some fee for responses via the user, this system can improve response times. This cost reduces the possibility of DoS attacks, as attackers would need to pay a fee per request.

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

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

[0142] In step U2, Alice calculates the following:

number

[0143] In step U4, Alice constructs a transaction to herself with the following stored as the OP_RETURN output: encrypted data 603, a description of the data, a asking price for the data, and a hash-based message authentication code (HMAC) calculated in terms of hashes of the encrypted data and password T. The HMAC itself is conventionally known. This transaction is a data storage transaction (destination transaction 152D in the example above where a hyperlink is used, but this protocol is not limited to being used with a hyperlink as a means of accessing a destination transaction).

[0144] This transaction, when included in the blockchain, can simultaneously provide several functionalities. Firstly, it is a permanent and immutable record of encrypted data accessible by the data owner at any point in the future by recording a transaction identifier (TxID). Secondly, it can function as an advertisement for data searchable by interested buyers. Finally, the inclusion of HMAC can be used by buyers to verify Alice's honesty and to assist in dispute resolution, as will be discussed in more detail later.

[0145] An example of the data exchange procedure between data provider Alice and data buyer Bob is as follows. See Figure 11.

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

[0147] In step V2, Alice adapts (maleates) the received template transaction to construct a transaction with two inputs: a 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 channels are needed for this stage. Alice's UTXO could be for dust.

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

[0149] In step V4, Bob verifies that the transaction is properly configured and signs his inputs if he finds them to be correct.

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

[0151] In step V6, Alice has S1=V A ·P B We calculate V. A This is Alice's private key, and P B This is Bob's public key.

[0152] In step V7, Alice signs her input as part of the input script using the following formula, which is then made public:

number

[0153] In step V8, Alice broadcasts the now fully signed transaction to blockchain network 106 so that it will be recorded on blockchain 150.

[0154] In step V9, Bob has S1=V B· P A We calculate V. B This is Bob's private key, and P A This is Alice's public key.

[0155] In step V10, Bob calculates the following using S1:

number

number

[0156] The method described above is advantageous in that it enables the transmission of data via Blockchain 150 in a way that integrates payments and data transfers, ensuring that Alice receives payment and Bob receives the data.

[0157] If Alice is honest, the HMAC will match what is in the data storage transaction, and the data is as described in the description portion of the data storage transaction. If Alice sends a fraudulent key, Bob can prove this using the key he sent and the hash of the encrypted data in the data storage transaction. If Alice sends fraudulent data, Bob can detect this by using the key used to encrypt the data and comparing it to what is in the data storage transaction. Furthermore, a trusted third-party organization, such as a government or corporation, can maintain records of the data and encrypted data, which can be used to verify that the encrypted data matches the description provided.

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

[0159] The advantage of sending the encrypted password to Bob and making S0 a function of the password is that it prevents S0 from being sent (in contrast to simply sending him the encrypted version of the key directly, as in the aforementioned method in Figures 7-9). Therefore, even if the transmission is compromised, it does not directly compromise the data. An attacker may need to know how to compute S0, for example, which Alice and Bob could share over a secure side channel. The function does not necessarily have to be a function of Alice's public key, but simply any deterministic piece of information known to both parties. This information may 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 method described above, the data may be stored off-chain and then placed on-chain when requested by Bob. In other words, Alice performs the method shown in Figure 10 in response to Bob's request 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, recording, and retrieving data stored on the blockchain or, if possible, on external private servers. Clients who wish to store their data on the blockchain would pay a registration or per-use fee to a provider that can encrypt, distribute, and maintain records of their data retrieval. This eliminates the need for individual users to maintain records of their encryption or private keys. Similarly, for services with large amounts of shareable data, such as music or video streaming services, a registration or per-use fee could be charged for access to the data.

[0162] In each case, the client initiates the request via a publicly available address provided by the service, along with the details of their request included in the transaction. The client's identity is verified, any conditions such as usage fees are verified, and then a session key may be generated using the previously disclosed protocol. 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 the transaction addressed to the client. The data is decrypted and then displayed to the user by the client's SPV wallet.

[0163] In the peer-to-peer protocol scenario described above, a repository service can act as a trusted third party to facilitate data exchange between data providers and data buyers. The repository service can maintain a description of the data, enabling data buyers to request specific data or purchase batches of related data. The service can also configure transactions, eliminating the need for users to validate or generate transactions or transaction conditions. If the repository service is trusted, the need for HMAC is also eliminated, as 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 is becoming increasingly important as larger amounts of data are included in transactions. The protocol disclosed in this specification provides a request-response method for blockchain networks that is very similar to how the hypertext transfer protocol (HTTP) did for the internet. Preferably, the method may be standardized. Using a standardized hypertext format, data within the blockchain can be linked and requested using clicks in a compatible browser with the help of an SPV wallet, etc. Both centralized and decentralized data storage can be monetized to compensate service providers and data owners. It is possible to secure the request and data transfer steps over public networks using previously deployed cryptographic technologies.

[0165] It should be understood that the above embodiments are described merely as examples.

[0166] More generally, according to one aspect disclosed in this specification, a method implemented by a consumer party's computer equipment, A step of accessing at least a first document that contains one or more hyperlinks, wherein each hyperlink includes a corresponding piece of anchor content and a corresponding identifier of the corresponding destination associated with each piece of anchor content, A step of rendering the content of at least a portion of the first document through the user output device of the consumer party's computer equipment, the step of rendering the anchor content of one or more of the hyperlinks, The steps include receiving user input through the user input device of the consumer party's computer equipment, by selecting one of the hyperlinks by selecting each anchor content from the rendered content, In response to the user input, the steps include automatically accessing data from the associated destination based on each identifier contained in the first document, Includes, A method is provided in which at least each destination of the selected hyperlink includes a destination transaction in a blockchain maintained across at least several nodes of the blockchain network, and access to the data includes the step of examining the destination transaction in the blockchain via the blockchain network.

[0167] In one embodiment, the first document may include a hypertext document.

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

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

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

[0171] In the embodiment, the first document may be an HTML document enhanced with additional types of tags for the HTML language to generate hyperlinks to blockchain transactions.

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

[0173] In this embodiment, the first document may be stored in the unavailable output of the source transaction.

[0174] In an embodiment, 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 lock script, and the first document may be stored in an unavailable output of these outputs of the source transaction. In an embodiment, the unavailable output of the source transaction may be made unavailable by a command such as OP_RETURN contained in the lock script, which terminates the lock script when executed by a node of the blockchain network.

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

[0176] In the embodiment, the first document may be accessed from a website or from the local storage device of the consumer party's computer equipment.

[0177] In an embodiment, the first document may include a plurality of hyperlinks, the destination of at least some of these hyperlinks may be different transactions on the blockchain.

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

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

[0180] In the embodiment, the accessed data may include a second document containing content in the form of text and / or one or more images, and access to the second document may include rendering at least a portion of the second document on a consumer user's computer device.

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

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

[0183] In the embodiment, the second document includes a hypertext document. The second document may be written in a markup language. The second document may be an HTML document reinforced with at least one additional type of tag for creating a link to the transaction on the blockchain.

[0184] In this embodiment, the data may be stored in the unavailable output of each destination transaction.

[0185] In an embodiment, 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 lock script, and the first document may be stored in an unavailable output of these outputs of the destination transaction. In an embodiment, the unavailable output of the destination transaction may be made unavailable by a command such as OP_RETURN contained in the lock script, which terminates the lock script when executed by a node of the blockchain network.

[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 access to the data may include accessing the data from the respective output based on the respective transaction identifier and output identifier. Alternatively, the data may be stored in a predetermined output number of the destination transaction, or more generally, in a predetermined location. In this case, access to the data may simply include accessing the data from the predetermined output or location. Another possibility is that access to the data may simply include searching the respective destination transaction for the data or an output of a predetermined expected type or format.

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

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

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

[0190] The payment may be included in the available output of the client transaction, which is addressed to the provider 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 the available output may be one of these outputs of the client transaction.

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

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

[0193] In the embodiment, the client transaction may include a request message that includes an identifier for the destination transaction and a signal requesting access to the encrypted data.

[0194] In this embodiment, the request message may be included in the unavailable output of the client transaction.

[0195] In an embodiment, 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 lock script, and the request message may be stored in an unavailable output of these outputs of the client transaction. In an embodiment, the unavailable output of the client transaction may be made unavailable by a command such as OP_RETURN contained in the lock script, which terminates the lock script when executed by a node of the blockchain network.

[0196] In this embodiment, the transmission of the client transaction may be triggered by the user input.

[0197] In one embodiment, the consumer party may send the client transaction to the provider party via a side channel, which then reads it and broadcasts it to the blockchain network. Alternatively, the consumer party may broadcast the client transaction to the blockchain network and individually signal to the provider party via the side channel that the client transaction has been broadcast to the blockchain network. Alternatively, the consumer party may simply broadcast the payment to the blockchain network without individually signaling to the provider party via the side channel, 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 the chain.

[0198] In one embodiment, 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 this case, the method may include the steps of the consumer party's computer equipment receiving the access information, determining the access key, and using the determined access key to decrypt and access the encrypted data.

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

[0200] In one embodiment, 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 to Bob (the provider party) via the side channel that the transaction is now being broadcast. Alternatively, the provider party may simply broadcast it to the blockchain network without individually signaling to the provider party via the side channel, allowing the consumer party to observe this transaction on the chain. The transaction in question may include an output addressed to the consumer party. Thus, the transaction is addressed to the consumer party, and they can therefore discover it on the chain in this way. This output may include a dust payment to the consumer party.

[0202] In some embodiments, the consumer party may send the client transaction to the provider party in template form 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 so that it is recorded on the blockchain. Alternatively, the access information may be included in a transaction separate from the client transaction.

[0203] Alternatively, 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 plain text. However, if it is communicated on-chain, this could make the access key available to any other member of the public. Even in the case of transmission via the side channel, it may be vulnerable to interception or disclosure by an intended consumer, for example.

[0205] Accordingly, in this embodiment, the access information does not include the access key in plain 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, which is encrypted based on a shared secret shared between the provider party and the consumer party. In this case, the method may further include the step of decrypting the access key based on the shared secret using the consumer party's computer equipment and accessing the encrypted data using the decrypted access key.

[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 steps of: decrypting the password based on the shared secret using the consumer party's computer equipment; 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 includes:

number

[0208] In the embodiment, the data may be included in the destination transaction together with a message authentication code, which is a second predetermined function of the password, and the second predetermined function is also a function of the data. In this case, the method may include the steps of: calculating the message authentication code by applying the second predetermined function to the decrypted password and the data using the consumer party's computer equipment; and comparing the calculated message authentication code with a message authentication code included in the destination transaction to determine the authenticity of the data.

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

[0210] In the embodiment, the accessed data may include a program, and the method further includes the step of executing the program on the consumer party's computer equipment. Alternatively or additionally, the method may include an initial step of the consumer party's computer equipment reading the program from yet another transaction on the blockchain and executing the program, the program performing the steps of rendering the root tengu, receiving the user input, and accessing the data from the destination.

[0211] The aforementioned program may be included in the unusable output of a program-stored transaction, such as a UTXO. This output may be made unusable by an opcode that terminates the lock script, such as OP_RETURN, which is included in the lock script.

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

[0213] In an embodiment, the method may include the step of automatically querying the set of transactions on the blockchain to check for any update transactions that use the destination transaction in response to the user input. In this case, access to the data from the destination transaction may be performed on the condition that the check is negative, and the method is performed by a function configured to access the data from the update transaction otherwise.

[0214] In another embodiment, a set of transactions to be recorded on a blockchain, the set being embodied on one or more computer-readable data media, A first transaction that stores a first document containing one or more hyperlinks, wherein each hyperlink includes a piece of anchor content and a corresponding identifier that links to a destination associated with the respective anchor content, A second transaction comprising 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 this is provided.

[0215] The data content within 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 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, for example, one or more further transactions on the blockchain.

[0216] Another aspect disclosed in this specification provides a method by which a consumer party accesses data from a provider party, wherein the data is stored in a first transaction on a blockchain in an encrypted form requiring an access key for decryption. The method includes the steps of: communicating a second transaction to the provider party, via the consumer party's computer equipment, to be recorded on the blockchain, the second transaction specifying payment for the data and further including an identifier for 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 to be recorded on the blockchain. A step of inspecting the blockchain in order to read the encrypted password from the third transaction, wherein the password is encrypted based on a shared secret between the consumer party and the provider party, and the access key is a first predetermined function of the password, The steps include: 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 method further includes the following: The data is included in the second transaction together with a message authentication code which is a second predetermined function of the password, and the second predetermined function is also a function of the data. The further step 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 in order to authenticate the data.

[0217] In this embodiment, the communication of the second transaction may include the step of communicating the second transaction to the second party via a side channel.

[0218] In one embodiment, the communication of the second transaction may include the step of communicating the second transaction in a template format so that the provider party can complete and broadcast the second transaction so that it is recorded on the blockchain.

[0219] In this embodiment, the completed version of the second transaction may be the third transaction, and the completion includes the step of adding the encrypted password.

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

number

[0221] In the embodiment, 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 in this specification, a set of transactions for recording on a blockchain, the set being embodied on one or more computer-readable data media, A data storage transaction that includes data in an encrypted format requiring an access key for decryption, wherein the data storage transaction includes a password and a message authentication code which is a predetermined function of the data, One or more further transactions, at least one of which specifies payment for the data, and includes an identifier for the first transaction and a signal indicating a request for the data, Includes, At least one of the one or more further transactions provided includes a set of passwords encrypted based on a shared secret shared between the consumer party and the provider party, wherein the access key is a predetermined function of the password.

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

[0224] In another aspect disclosed in this specification, a computer program is provided which is embodied on a computer-readable storage device and configured to perform a method according to any embodiment disclosed in this specification when executed on a computer device of a consumer party.

[0225] In another aspect, the party equipment is Memory containing one or more memory units, A processing device including one or more processing units, Includes, The provided device includes a memory which stores code configured to be executed on the processing device, and the code which, when executed, is configured to perform a method according to any embodiment disclosed herein.

[0226] In other embodiments disclosed herein, a method may be provided which includes the operation of a network of consumer parties, provider parties, any related third parties, and / or nodes.

[0227] In other embodiments disclosed herein, a system may be provided comprising computer equipment of a consumer party, computer equipment of a provider party, computer equipment of any third party, and / or a network of nodes.

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

Claims

1. A method by which a consumer party accesses data from a provider party, wherein the data is stored in a first transaction on a blockchain in an encrypted format requiring an access key for decryption, and the method is performed by the consumer party's computer equipment. A step of communicating a second transaction to the provider party for recording on the blockchain, wherein the second transaction specifies payment for the data and further includes an identifier for the first transaction and a signal indicating a request for the data. In response to the second party broadcasting a third transaction containing an encrypted password, which is an encrypted version of the password, to be recorded on the blockchain, A step of examining the blockchain in order to read the encrypted password from the third transaction, wherein the encrypted password is encrypted based on a shared secret between the consumer party and the provider party, and the access key is a first predetermined function of the password, A step of decrypting the encrypted password read from the third transaction based on the shared secret in order to generate a corresponding decrypted password, wherein the decrypted password is equal to the password, The steps include determining the access key by applying the first predetermined function to the decrypted password, and decrypting the data based on the determined access key, The data includes, and the data is included in the first transaction together with a message authentication code which is a second predetermined function of the password, and the second predetermined function is also a function of the data. The method further comprises the steps of calculating the message authentication code based on the decrypted data and the decrypted password, and comparing the calculated message authentication code with the message authentication code included in the first transaction in order to authenticate the data.

2. The method according to claim 1, wherein the communication of the second transaction includes the step of communicating the second transaction to the second party via a side channel.

3. The method according to claim 2, wherein the communication of the second transaction includes the step of communicating the second transaction in a template format so that the provider party can complete and broadcast the second transaction so that it is recorded on the blockchain.

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

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

6. The method according to any one 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 that is implemented on a computer-readable storage device and is configured to perform the method described in any one of claims 1 to 6 when executed on a consumer party's computer device.

8. It is a consumer party device, Memory containing one or more memory units, A processing device including one or more processing units, Includes, The memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to any one of claims 1 to 6 when executed.

Images