Blockchain-based read receipts

Abstract

1. A computer-implemented method for requesting a read receipt for a message using blockchain, where the read receipt constitutes evidence that the message has been opened, the method being executed by a first party and comprising: sending the message and / or an encrypted version of the message to a second party; generating a cryptographic puzzle based on the message; generating a request blockchain transaction, the request blockchain transaction having a first output locked by a first locking script, the first locking script being configured to, when executed together with a first unlocking script of a response blockchain transaction, require that the first unlocking script include a solution to the cryptographic puzzle; and determining that the message has been opened in response to determining that the first output has been unlocked.

Description

[Technical Field]

[0001] The present disclosure relates to a method for requesting and sending read receipts using blockchain. [Background technology]

[0002] A blockchain is a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence that may span one or more blocks and extend back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often referred to as "mining," which involves multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, outstanding transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and publication of a block may be achieved through publication of only the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: moving digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or temporally ordering index pointers. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes for data within transactions. Because there is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, increasingly more complex data can be incorporated. For example, this could be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes (often called "miners") in a blockchain network perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a target block template in an attempt to identify a valid proof-of-work solution for the transaction. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated and are not included in blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of fraudulent transactions is performed by the actions of competing nodes that are incentivized to act on behalf of the network and report and prevent fraud. Widespread publication of information allows users to continuously audit node behavior. The simple publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of a digital asset derivable from the preceding sequence of transactions. A consumable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input, which comprises a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not as a valid transaction, but possibly disseminate it to register a fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored in the blockchain and constantly updated by multiple nodes separately. Summary of the Invention [Problem to be solved by the invention]

[0009] A "read receipt" refers to an acknowledgment that a message has been received. Read receipts are integrated into some messaging systems, e.g., email, text messaging, and social messaging applications. However, existing read receipts only provide evidence that a message has been received, but do not necessarily prove that the message has been read. For example, an email recipient may simply send a read receipt upon receipt of an email without actually opening the email and viewing its contents. Additionally, to date, no read receipts incorporate the ability to make the read receipt immutable, meaning that a party can claim that a previously sent read receipt is inaccurate or that the message content has been changed since the read receipt was sent.

[0010] One exemplary scenario in which a message may need to be certified is the process of serving notice of legal proceedings. Legally, in many jurisdictions, a party initiating legal proceedings against a second party is required to provide notice of the proceedings to the second party. However, some parties have been known to ignore letters and other communications and claim not to have received notice at the time the proceedings were initiated. It is useful to know whether the second party acknowledged receipt or ignored the communication attempts, in which case an alternative method of message delivery can be used.

[0011] In one aspect disclosed herein, a computer-implemented method is provided for requesting a read receipt for a message using blockchain, where the read receipt serves as evidence that the message has been opened, the method being executed by a first party and including the steps of sending the message and / or an encrypted version of the message to a second party; generating a cryptographic puzzle based on the message; generating a request blockchain transaction, the request blockchain transaction having a first output locked by a first locking script, the first locking script being configured such that when executed together with a first unlocking script of a response blockchain transaction, the first unlocking script requires that the first unlocking script include a solution to the cryptographic puzzle; and determining that the message has been opened in response to determining that the first output has been unlocked.

[0012] In another aspect disclosed herein, a computer-implemented method is provided for sending a read receipt for a message using blockchain, where the read receipt is evidence of opening the message, the method being executed by a second party and including the steps of receiving the message and / or an encrypted version of the message; identifying a request blockchain transaction, the request blockchain transaction including a first output locked by a first locking script, the first locking script being configured, when executed with a first unlocking script of a response blockchain transaction, to require the first unlocking script to include a solution to a cryptographic puzzle; and generating a response blockchain transaction, the response blockchain transaction including a first input that references the first output of the request transaction, the first input including the solution to the cryptographic puzzle, the solution being based on the message.

[0013] Advantageously, the present invention provides both parties with tamper-proof evidence that the second party received the message without revealing any information about the message on the chain, and also provides both parties with evidence that the message was read.

[0014] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of a system implementing blockchain-based read receipts between two individuals. [Figure 4] FIG. 1 is a sequential flow diagram illustrating steps that may be used to implement blockchain-based read receipts between two individuals; [Figure 5A] FIG. 2 illustrates a user interface of an exemplary messaging service used to generate a read receipt. [Figure 5B] FIG. 1 is an example diagram of a read receipt generated by a messaging service. [Figure 6] 1 is a flowchart illustrating exemplary steps for implementing blockchain-based read receipts between two individuals. [Figure 7] FIG. 1 is a schematic diagram illustrating the process of generating a blockchain-based read receipt between two individuals. DETAILED DESCRIPTION OF THE INVENTION

[0016] 1. System Overview Example 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be adapted to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0017] Each blockchain node 104 comprises a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0018] A blockchain 150 comprises a chain of blocks of data 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain 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 uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, such as a user 103 to which the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points to the output of a preceding transaction 152, thereby chaining transactions together.

[0019] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0020] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not limited to a particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0021] For a given current transaction 152j, the (or each) input comprises a pointer referencing the output of a previous transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily mean the transfer of a financial asset, although this is certainly a common usage. More generally, consumption can be described as consuming an output or allocating it to one or more outputs in another, subsequent transaction. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily exist at the time the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, as used herein, "preceding" refers to something that precedes in a logical sequence connected by pointers, and not necessarily to a time of creation or transmission in a chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

[0022] The input of the current transaction 152j also comprises the input's authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to provide change). In some cases, the transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0023] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process utilized by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances may not transmit it to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is legitimate according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that the cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction consumes (i.e., "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0024] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "spent") is whether it has not already been validly redeemed by the input of another, earlier transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless flagged as fraudulent and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is no defined order to transactions, an account balance has a single defined state at any given time.

[0025] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is aided by "proof of work." At blockchain nodes 104, new transactions that have not yet appeared in a block 151 recorded in the blockchain 150 are added to an ordered pool 154 of legitimate transactions. Blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool of outstanding transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a defined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0026] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution causes the hash output to satisfy a condition). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, which points to the previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0027] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to spread between the nodes 104. That is, the fork with the longest branch becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0028] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional acceptable amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be named an "initial transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof of work indicates the node constructing the new block's willingness to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, an ordinary (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction is published. This fee is typically called a "transaction fee" and is discussed below.

[0029] Depending on the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0030] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0031] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0032] Some or all of the parties 103 may be connected as part of a different network, for example, a network superimposed on the blockchain network 106. Users of the blockchain network (often referred to as “clients”) are sometimes said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. By way of example only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not intended to be limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

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

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

[0035] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 so that the transactions 152 are disseminated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, the second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0036] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and any client function described herein may instead be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer, at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0037] An instance of client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to inquire about any transactions of which the respective party 103 is the recipient (or, in embodiments, to actually investigate other parties' transactions in the blockchain 150, since the blockchain 150 is a public institution that lends credibility to transactions in part by being publicly visible). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As discussed above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 for dissemination throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol is attached to a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0038] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the transaction 152j according to the blockchain node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity verification may be configurable per transaction via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0039] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., for it to be "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0040] Once admitted to the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each pool 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but whoever solves first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0041] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views about which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

[0042] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored separately on the blockchain and constantly updated by the network's nodes. In such a system, transactions are ordered using the account's transaction execution record (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0043] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0044] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value specifying an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include an indication of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0045] Suppose Alice 103a wishes to create transaction 152j that transfers an amount of a target digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It has the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately following transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0046] By the time Alice creates new transaction Tx1, or at least by the time she submits it to network 106, the currently preceding transaction Tx0 may already have been validated and included in block 151 of blockchain 150. It may already be included in one of the blocks 151 at that time, or it may still be waiting in ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “successor” as used herein in the context of a sequence of transactions refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (e.g., which transaction points to which other transaction). They may be equivalently substituted with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to wait for its parent, depending on the node protocol and / or node behavior.

[0047] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the recipient of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

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

[0049] So, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ], which means that Alice's signature Sig P must exist in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A The Tx1 input 202 comprises a pointer to Tx1 (e.g., pointed to by transaction ID TxID0, where in an embodiment TxID0 is a hash of the entire transaction Tx0). The Tx1 input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. The Tx1 input 202 further comprises an unlock script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or a combination of these.

[0050] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to see if the unlock script meets the conditions defined in the lock script (where the conditions may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' is the functionality the lock script contains (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, these scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature signing the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus, a separate element specifying the signed portion of data in plaintext need not be included, as it is essentially already present).

[0051] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key, the plaintext, and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature with the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing particular data, portions of a transaction, etc., may, in embodiments, mean signing a hash of that data or portion of a transaction.

[0052] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of outstanding transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 is disseminated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 is fraudulent, even if all other conditions are met. Therefore, blockchain node 104 also needs to verify whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0053] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction is not propagated or included in block 151.

[0054] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined in the UTXO is "left behind" as unspent, while another part is not. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself or pay another party the change in the second output of Tx1.

[0055] In practice, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and therefore may not be propagated or included in the blockchain 150, even if technically valid (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require a unique, separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by inputs 202 of a given transaction 152 and the total amount specified in outputs 203 is automatically given to the blockchain node 104 that issues the transaction. 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 may be allocated by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0056] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103's entire balance. It is the role of the wallet function of the client application 105 to reconcile together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, forward transaction. The wallet function can do this by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0057] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0058] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portions of the outputs that the digital signature signs depend on the SIGHASH flag. The SIGHASH flag is typically a four-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0059] A lock script may be referred to as a "scriptPubKey," which refers to the fact that the lock script typically includes the public key of the party to which the respective transaction is locked. An unlock script may be referred to as a "scriptSig," which refers to the fact that the unlock script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0060] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of the first party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 without the transactions 152 being registered on the blockchain network 106 or entering the chain 150 until either Alice or Bob chooses to broadcast the transaction 152 between Alice and Bob to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

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

[0062] 4. Non-Blockchain Read Receipts This section briefly describes some examples of existing read receipt mechanisms. Taking Outlook as an example, a sender can request a read receipt for a message in two ways: Method 1: File -> Options -> Mail -> Tracking -> Read Receipts to verify that the recipient has viewed the message for every message sent. Method 2: New Mail -> Options -> Check "Request Read Receipt" for one message sent. Please note that if you use this method, you will not be able to track read receipt responses until the read receipt is received.

[0063] When the recipient opens the message, they will see a pop-up like the one shown in Figure 5A. The message recipient decides whether to send a read receipt. If they select "Yes," a read receipt is sent to the message sender. Figure 5B is an example from Outlook.

[0064] This read receipt is sent via email showing a timestamp and other relevant metadata, and from the message sender's perspective, the status of the message they sent changes from "Delivered" to "Read" because the message they sent was opened.

[0065] 5. Cryptography 5.1 Elliptic Curve Digital Signature Algorithm (ECDSA) The ECDSA method is used to create and verify digital signatures using elliptic curves. This section briefly describes the process of generating and verifying digital signatures based on the ECDSA method. Digital signatures are used to prove ownership of UTXOs.

[0066] 5.1.1 Signature Generation To generate a signature, we need a private key V to prove our identity. The corresponding public key PK is calculated by PK=V·G, where "·" denotes elliptic curve scalar multiplication and G is the elliptic curve generation point. Now, given the private key V, we can generate a signature for a message m using the ECDSA method as follows: 1. Double-hash the message m using the SHA-256 hash function: e = SHA-256(SHA-256(m)). 2. Randomly select an integer k∈{1, 2, …, n-1} as a temporary private key. 3. Compute the corresponding ephemeral public key R = k G = (x, y). 4. Get the x-coordinate of the calculated point R: r = [R] x where [R] x denotes the process of obtaining the x-coordinate of the elliptic curve point. Note that if r=0, the signature is independent of V, so we go back to step 2 and choose another k. 5. Modular inverse k of k mod n -1 where n is some prime modulus. 6. s = k -1 Calculate (e + Vr) mod n. If s = 0, go back to step 2 and choose another k. This is to ensure that signature verification is possible, since the opposite is required for s ≠ 0. 7. The signature is given by (r, s).

[0067] It should be noted that k is an ephemeral key and is different for each case, so the same message m may have different signatures.

[0068] 5.1.2 Signature Verification Given a message m, a public key PK, and a signature (r,s), the signature can be verified using the following calculation: R' = SHA-256(SHA-256(m))s -1 G + rs -1 ·PK. [R'] x If =r, then the signature is valid, otherwise the signature is invalid.

[0069] 5.1.3. R Puzzle An R-puzzle is a type of script that allows a spender to sign an input UTXO using any valid elliptic curve key pair. R-puzzles require proof of knowledge of k, which is used to authorize spending of the input UTXO. k is the ephemeral private key in ECDSA signatures. For security reasons, k is not revealed in R-puzzles; instead, r = [k G] x is revealed on the blockchain when solving the puzzle. Note that k is arbitrary knowledge that needs to be proven in the R puzzle.

[0070] 5.1.4. Pay to R Puzzle Hash (P2RPH) A P2RPH transaction is a transaction that pays for the R puzzle challenge. To consume the input UTXO, you must provide an unlock script with a signature that includes the same r as used in the R puzzle challenge. The ScriptPubKey and ScriptSig for a P2RPH transaction are shown below. scriptPubKey: OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 H(r) OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG scriptSig:<sig'> <pk><sig r >

[0071] Signature r is generated on r, and the payer can compute the signature using any private / public key pair. The signature sig' is r This can be done by using a different sighash flag. Note that the signature sig' must use a different ephemeral key to avoid compromising the private key.

[0072] The signature sig' is added to the scriptSig to avoid signature forgeries. Without the signature sig', a malicious actor could intercept a P2RPH transaction and modify it to send funds to themselves, while using the same signature that the transaction sender used in the original transaction.

[0073] 5.1.5. Scripts with Conditional Clauses Conditionals can be implemented in blockchain scripts using the OP_IF statement. OP_IF executes the set of subsequent opcodes up to the next OP_ELSE or OP_ENDIF if the value at the top of the stack is not true or zero. If OP_ELSE is the subsequent conditional clause and the first conditional clause succeeds, the script jumps to OP_ENDIF at the height of the original clause's condition stack. Once the OP_ENDIF is processed, the script execution ends and returns the result.

[0074] 5.1.6. Identity-based Encryption Identity-based encryption (IBE) is a type of public key encryption scheme in which a user's public key can be any string, such as an email address or username. The associated private key can only be generated by a trusted third party called a private key generator (PKG). A user submits their identity (such as an email address) to the PKG and obtains a private key associated with the identity. In the IBE scheme, the sender encrypts a message using the recipient's identity (such as an email address) and public parameters assigned by the PKG. The recipient can then decrypt the message using the private key obtained from the PKG.

[0075] 6. Blockchain-based acknowledgement FIG. 3 illustrates an example system 300 for issuing and responding to read receipts using a blockchain 150. Generally, read receipts can be made for any type of message, such as email, text messages, chatbot messages, or social media messages. As shown, the example system 300 includes a first party (e.g., Alice 103a), a second party (e.g., Bob 103b), and a blockchain network 106. Here, the first and second parties are referred to as Alice 103a and Bob 103b, respectively. Alice 103a and Bob 103b can communicate with each other, as indicated by arrows 112, and can send and receive information to the blockchain 150, for example, via one or more blockchain nodes 104, as shown in FIG. 1. To generate a blockchain-based read receipt for a message, Alice generates a request transaction 108 that includes a cryptographic puzzle based on the message as part of its output. Alice submits the request transaction 108 directly or indirectly to the blockchain network 106. Alice also submits the message to Bob. Bob constructs a response transaction 110 using the output of the request transaction 108 to indicate that he knows the message. That is, Bob's response transaction 110 includes the solution to a cryptographic puzzle based on the message as part of its input, which references the output of the request transaction 108. Alice then checks the existence of the response transaction 110 on the blockchain 150 to determine if Bob correctly received the message. Alice can either check for the existence of the response transaction 110 on the blockchain 150 herself, or she can be notified of the response transaction 110 by Bob and / or the blockchain network 106.

[0076] The read receipt provides evidence that the message was correctly received and opened by Bob. In an embodiment, the read receipt can also provide evidence that the message was read.

[0077] Figure 4 is a sequence flow diagram illustrating an example series of steps that Alice and Bob perform to generate a read receipt. It will be understood that some steps may be performed in a different order.

[0078] In step S1, Alice 103a sends a message M to Bob 103b. This message may be in encrypted form. For example, the message may be sent using asymmetric or symmetric encryption. For example, Alice may encrypt the message using an IBE scheme based on Bob's identity (e.g., email address). Alternatively, the message may be sent unencrypted. The message may contain any type of data. For example, the message may be a text-based message. Alternatively, the message may be an audio or video recording. The latter may be used when proving an oral disclosure.

[0079] Alice also generates a cryptographic puzzle in step S2. The cryptographic puzzle may require that the solution include a signature using a temporary private key, which may be determined only by the recipient of the message. For example, the cryptographic puzzle may use the R-puzzle technique described above. Alternatively or additionally, the cryptographic puzzle may require that the solution include a preimage of a hash included in the cryptographic puzzle. For example, the cryptographic puzzle may utilize the hash puzzle technique described above. The cryptographic puzzle may also require that the solution include a signature using one or more additional private keys.

[0080] In step S3, Alice generates a request blockchain transaction 108, which refers to a transaction in which Alice requests a read receipt for a message. Alice includes a cryptographic puzzle in the locking script of the transaction's first output. Note that "first" here is used only as a label for a particular output and does not necessarily refer to the output that logically appears first in the transaction. Alice can optionally include other outputs in the transaction. For example, she could include an output that pays funds to Bob's public key. This may cause Bob's wallet to detect the transaction and notify Bob of the request. Alternatively or additionally, Alice can send the transaction identifier (TxID) of the request transaction to Bob via a message channel, notifying Bob of the request. Alice can also include further outputs that request read receipts from other parties. Each output, including read receipts, may be generated in a similar manner.

[0081] A request blockchain transaction can take any number of UTXOs as input. For example, a request transaction can take as input the output of a previous request blockchain transaction. In this case, Alice's request transaction requesting a read acknowledgment from Bob can also serve as a read acknowledgment to Bob for the previous message.

[0082] The first output may lock up only a small (i.e., minimal) amount of funds, in which case it has no significant monetary value to either Alice or Bob. Alternatively, the first output may lock up a larger amount of funds. For example, Alice's message may contain details of a contract between her and Bob, and Bob's read receipt may indicate his agreement to the terms of that contract.

[0083] In step S4, Alice sends the request blockchain transaction to the blockchain network 106.

[0084] Bob receives the message and retrieves the request blockchain transaction, for example, using a notification from his wallet or the TxID he received from Alice. Bob then uses the message to solve the cryptographic puzzle, as shown in step S5. Bob generates a response blockchain transaction and unlocks the first output of the request transaction with the solution to the cryptographic puzzle in step S6. In step S7, Bob submits the response blockchain transaction to the blockchain network 106. Bob can then transfer the funds to his account or use them to pay for other services. For example, Bob can use the funds to create a new read receipt request.

[0085] Bob can create a further output to send funds to Alice. Alternatively or additionally, Bob can send the first output back to Alice. Alternatively or additionally, Bob can inform Alice of the TxID of the response blockchain transaction.

[0086] Alice determines that Bob received and acknowledged the message based on the response blockchain transaction. Bob can prove that he received and acknowledged the message by showing the existence of the response blockchain transaction on the blockchain. At a later date, Alice or Bob can prove the agreed-upon message by finding the request blockchain transaction and / or the response blockchain transaction and proving that the solution to the cryptographic puzzle was based on that message. If either party alters the message, the new message cannot be used as a basis for the solution to the cryptographic puzzle, and tampering becomes evident.

[0087] Note that in this context, a read receipt does not necessarily prove that Bob read and processed the message. A read receipt indicates that the message was received and opened. This is not usually a problem, as read receipts are typically used by the sender to know that the recipient received the information. If the recipient chooses not to read the information, the only person who suffers a penalty is the recipient themselves. For example, if Alice sends an agreement to Bob, and Bob sends a read receipt but does not actually read the message, he has penalized himself for agreeing without checking. Alice knows from the read receipt that Bob was given the opportunity to read the message.

[0088] However, in some cases, the read receipt may prove that Bob read the message. For example, if the cryptographic puzzle is based on only part of the message, Bob may need to read the message to get the correct part. Alternatively, the cryptographic puzzle may be based on the entire message, but the message server may confirm that Bob read the message by other means. For example, the response blockchain transaction may not be generated until Bob has scrolled through the entire message.

[0089] In some cases, the cryptographic puzzle employs a method referred to herein as a "pay-to-have public key hash" scheme. In this method, Alice generates a first hash based on the message. Alice also generates a first value based on the first hash and the first private key. The first hash may be a hash of the entire message or a hash of a portion of the message. Alternatively, the first hash may be a hash generated by concatenating the message or a portion of it with a pseudorandom number. Such hashes are commonly referred to as "salted hashes," and the pseudorandom number included in such hashes is referred to as the "salt." Generally, the hash may be generated using any suitable hash function, such as the SHA256 algorithm or the RIPEMD-160 algorithm. Additional hash algorithms are known to those skilled in the art. The hash may be calculated by running the algorithm once, or the hash algorithm may be run multiple times. For example, the SHA256 algorithm may be applied twice to the hash of the message or the salted hash. Alternatively or additionally, multiple hash algorithms may be used in sequence. For example, the first iteration uses SHA256, and the second iteration uses the RIPEMD-160 hash function, which takes as input the hash resulting from the SHA256 algorithm and produces a final hash that is used as the first hash based on the message.

[0090] In some embodiments, the first value may be generated by adding the first hash and the secret key. In some embodiments, the first value may be generated by adding the first hash, the first secret key, and the additional value together. In other embodiments, the first value may be generated by subtracting the hash from the secret key, or by subtracting the hash and the first secret key from the additional value. Further alternatives will be apparent to those skilled in the art. The first value is then included in the transaction. In some embodiments, the first value is included in the transaction as an OP_RETURN value.

[0091] In some examples, the cryptographic puzzle employs a hash-based method for generating a private key, referred to herein as "R-puzzle hashing." In this method, Alice generates a first hash based on the message and uses this first hash to generate a first private key. As noted above, the first hash can be based on all or part of the message, can be salted, and can be generated by any known hashing algorithm, including by sequentially applying one or more hashing algorithms.

[0092] The first private key may be the first hash or may be generated based on the first hash. For example, the private key may be generated by padding the first hash or by removing some end bits from the first hash.

[0093] In some examples, the cryptographic puzzle is generated using a method (referred to herein as a "hash disclosure method") that requires the recipient to demonstrate knowledge of a hash preimage. In this method, Alice first generates a first hash based on the message. As explained in more detail above, this first hash can be based on all or part of the message, can be salted, and can be generated by any known hash algorithm, including by sequentially applying one or more hash algorithms. Alice then generates a second hash by hashing the first hash. The first hash is therefore a preimage of the second hash. The cryptographic puzzle includes the second hash, and a solution to the cryptographic puzzle must include a preimage of the second hash, i.e., the first hash.

[0094] A cryptographic puzzle generated in any of the above ways may further include a condition requiring a signature generated using a second (different) private key. For example, the second private key is Bob's private key. Thus, a solution to the cryptographic puzzle indicates that Bob, and not some other individual, received and acknowledged the message. Alternatively or additionally, the cryptographic puzzle may be configured to require a signature using the sum of the first private key and the second private key. The first locking script containing the cryptographic puzzle may be configured to perform point addition of the second public key and the first public key based on the first private key to verify that the signature provided in the first unlocking script was generated using the combination of the first and second private keys. The locking script may be configured to perform point addition using techniques disclosed in any of European Patent Applications No. 2200991.4, 2200992.2, and 2200993.0. Other suitable techniques may alternatively be used.

[0095] The first locking script, generated using any of the above methods and incorporating a cryptographic puzzle, can further incorporate a first conditional subscript configured to allow the output to be unlocked if the unlocking script includes a signature with a third private key. For example, this may be Alice's private key. This means that if Bob sends a response transaction and refuses to verify the message, Alice can retrieve the funds locked in the first output. Advantageously, the first conditional subscript can be incorporated with a feature requiring a signature with a second private key, ensuring that Alice can retrieve the funds without knowing the second private key.

[0096] The first locking script can alternatively or additionally incorporate a second conditional subscript. The second conditional subscript can contain two alternative options that Bob can choose from when satisfying the script. Bob's unlocking script contains the solution to the cryptographic puzzle and must also satisfy one of at least two alternative options in the second conditional subscript. Alice and Bob may reach protocol agreement on specific options and their meanings. For example, Alice and Bob may agree that one condition requires Bob to provide a preimage of the hash of the word "YES" and another condition requires Bob to provide a preimage of the hash of the word "NO." In this way, Bob can indicate his agreement or disagreement with the message by choosing either the YES or NO resolution path in a response transaction. Alternatively, a condition may involve a signature based on a portion of the hash. The first condition on the message is a signature using a hash based on another portion of the message, while the second condition is a signature using a hash based on another portion of the message. For example, Alice may present Bob with several options in a message, and Bob may sign a message indicating which option he prefers by generating a signature using a hash of the part of the message that indicates the preferred option.

[0097] Messages can be sent in encrypted form. The encrypted form can be generated from the message using identity-based encryption (IBE) methods. In IBE, a user's public key can be any string, such as an email address or username. The associated private key can only be generated by a trusted third party, a private key generator. The user sends the string they want to use as their identity (e.g., their email address) to the private key generator, which then sends the corresponding private key. The sender encrypts the message using the recipient's ID string and some public parameters assigned by the private key generator. The recipient can decrypt the message using the private key sent.

[0098] The request transaction 108 and / or the response transaction 110 may further include a third hash based on the message. For example, the third hash could be a salted hash using a different salt than the salt used to generate the first hash. This hash could be included in the transaction as OP_RETURN. The use of two different salted hashes protects against a birthday attack, in which Alice generates multiple versions of a message by changing minor features such as the format of the message, and potentially multiple versions of another message that appear to have been signed by Bob. It is computationally infeasible to find a preimage that generates a set target hash. However, if the target hash value is not set, it is much easier to find hash collisions. If Alice creates two message variations for Bob, one decoy and one malicious, and then hashes both the decoy and malicious variations massively, differing in insignificant details that affect the hash without changing the substantive content of the messages, Alice can find a hash collision (i.e., the combination of the decoy and malicious messages hashes to the same value) and use this to trick Bob into signing a read receipt containing the shared hash value. A third approach, salted hashes, is one way to make this attack computationally infeasible: because the preimage unexpectedly modifies the hash, adding the same salt to two different messages with matching hashes will not result in the same hash output.

[0099] In some scenarios, Alice may want to receive read receipts from multiple individuals for the same message. Alice can accomplish this in several ways:

[0100] One method is for Alice to create a separate output for each party and lock it down, requiring both the solution to the cryptographic puzzle and a signature with the party's private key. This method works if Alice knows all of the parties' public keys. However, it is possible that Alice does not know the recipient's public key. In this case, Alice creates each party's cryptographic puzzle based on a salted hash, and each party receives a different salt. This means that each participant can solve their own cryptographic puzzle, but cannot solve the other party's cryptographic puzzle and therefore cannot sign on behalf of the other party without authorization. For example, when sending to two recipients using a pay-to-public-key hash scheme, Alice generates a first hash based on the message and a first pseudorandom number and a second hash based on the message and a second pseudorandom number. Alice then generates a first private key and a second private key. Alice uses her first private key and the first hash to generate a first value, which she can include in the first output of the request blockchain transaction 108, for example, as the OP_RETURN value. Alice can also generate a second value based on the second private key and the second hash and include this value in the second output of the request blockchain transaction 108. The first and second outputs may be outputs of the same blockchain transaction or may be separate transactions. Alice sends a message to two individuals, Bob and Charlie. Alice can also send a first pseudorandom number to Bob and a second pseudorandom number to Charlie. Bob can calculate a first hash using the message and the first pseudorandom number and identify the first private key from the first value and the first hash. This allows Bob to unlock the first output. However, despite knowing the message, Bob cannot unlock the second output because he does not know the second pseudorandom number and therefore cannot calculate the second hash.Charlie can write a script that uses a second pseudorandom number to calculate a second hash, uses this to identify a second secret key from the second value, and then uses this key to unlock the second output.

[0101] As another example, Alice can send to multiple recipients using the R-puzzle hashing method. In this example, Alice generates a first pseudorandom number and a second pseudorandom number, generates a first hash based on the message and the first pseudorandom number, and generates a second hash based on the message and the second pseudorandom number. Next, Alice uses the first hash to generate a first public key and the second hash to generate a second public key. See above for details on generating the first public key from the first hash. Using a corresponding method, she generates a second public key from the second hash. Next, Alice constructs the request blockchain transaction 108 using a first locking script that ensures that the first output can only be unlocked with a signature containing the first private key corresponding to the first public key. Alice also constructs the request blockchain transaction 108 using a second locking script that ensures that the second output can only be unlocked with a signature containing the second private key corresponding to the second public key. The second output and the first output can be included in a single blockchain transaction or in separate blockchain transactions. Alice sends a message to Bob and Charlie, sending the first and second pseudo-random numbers to Bob and Charlie, respectively. This means that Bob can only unlock the first output, and Charlie can only unlock the second output, even though the message is the same in both cases.

[0102] As yet another example, Alice can use hash reveal to send a read receipt request to multiple recipients. In this example, Alice generates a first pseudorandom number and a second pseudorandom number. Alice generates a first hash based on the message and the first pseudorandom number and a second hash based on the message and the second pseudorandom number. Next, Alice generates a third hash based on the first hash and a fourth hash based on the second hash. Alice constructs a request blockchain transaction 108 that includes a first lock script that requires the corresponding unlock script to include a preimage of the third hash. Alice also creates a second lock script that requires the corresponding unlock script to include a preimage of the fourth hash. Alice can use this second lock script to lock the second output of the request blockchain transaction 108. Alternatively, this second lock script can be incorporated into the second transaction. Alice sends a message to Bob and Charlie and sends the first pseudorandom number to Bob. Both Bob and Charlie can prove receipt of the message, but neither can unlock both outputs without exchanging pseudorandom numbers.

[0103] In all examples, the method can be generalized to n recipients, where Alice generates n pseudorandom numbers and uses them as the basis for n different cryptographic puzzles based on the message.

[0104] 7. Example of Blockchain-Based Read Receipt Implementation This section provides further specific examples of the blockchain-based read receipt protocol presented above. Some or all of the features described below can be used in combination with any of the features described above. It should be understood that some features are optional.

[0105] One reason for using blockchain-based read receipts is that, unlike off-chain read receipts, they are tamper-proof for both the recipient and the sender. Another reason is that such a mechanism can not only prove that a sent message or document was opened, but also that the recipient has read its contents, if necessary. Blockchain-based read receipts also make it possible to generate read receipts based on parts of the message, for example, parts that are particularly important to the recipient and therefore should be read. The protocol described here also provides an incentive for recipients to send read receipts.

[0106] A blockchain-based read receipt is defined as a blockchain transaction sent from the receiver to the sender, used to confirm that the message has been read and opened. Because a read receipt is requested by the sender of the message, it is advantageous for the sender and receiver to discuss how the request and response blockchain transactions will be sent before generating the request blockchain transaction.

[0107] Requests may be sent off-chain or on-chain. Off-chain requests may be similar to requests in existing messaging systems (such as Outlook or Gmail) that allow senders to turn on a feature requesting read receipts for all messages sent or for a single message. For example, in Outlook®, read receipts can be requested using the two methods described in Section 6.

[0108] However, in existing systems, when using the off-chain request method, there is not enough incentive for the receiver to return an on-chain read acknowledgment. This is because the receiver needs to pay some funds to publish the on-chain read acknowledgment. Furthermore, when sending a request for a single message using the second method in Section 6, it is difficult for the sender to retrieve the request if the receiver rejects the request. This is because it is difficult for the sender to track whether such a request was sent without receiving the associated read acknowledgment.

[0109] The on-chain request protocol described herein addresses these issues: first, on-chain request transactions can be captured on the blockchain; second, funds can be provided for recipients to send read acknowledgments back, further increasing the incentive for recipients to send read acknowledgments.

[0110] 7.1 Example scenarios for read receipts A sender (e.g., Alice 103a) may send a message to one or more recipients and request a corresponding read receipt. Note that the message may be, for example, a regular email or a smartphone text message. While it does not have to be sent on-chain, the message system allows Alice to send a blockchain transaction for an on-chain request. Furthermore, it does not matter whether Alice knows the recipient's public key. The request can be sent via a customized locking script, and the recipient can send the request transaction TxID. request You can send a read receipt by unlocking the locked bitcoin.

[0111] A sender may request one or more read receipts for the same message. Scenarios requiring multiple read receipts actually occur in the real world. For example, Alice sends an advertisement to an unspecified group and requests read receipts. Those who return a read receipt receive a reward. This helps the sender count the number of people who opened the advertisement. Additionally, the sender can set specific requirements for read receipts, such as proving that the message was read, not just opened.

[0112] 7.2 One Read Receipt A sender (Alice) sends a message M to one recipient (Bob) and requests a read receipt. The hash of the entire message is denoted as k = H(M), and Bob must prove to Alice that he read the message with a read receipt. There are two ways that Alice can construct a request blockchain transaction that Bob will use to send the proof of read receipt in a response blockchain transaction.

[0113] 7.3 Example of paying for a public key hash When Alice creates the request transaction, she may or may not know Bob's public key used in the request.

[0114] 7.3.1 P2PKH-UnknownPK method Alice generates a random secret key sk and stores it as C k = sk + k. Alice creates a P2PKH-UnknownPK request transaction paying for the public key sk·G, where "·" represents elliptic curve scalar multiplication and G represents the elliptic curve generation point. Alice places C as the OP_RETURN data of the lock script. k The hash of the entire message k is the secret value. Therefore, only the user who receives the message can calculate k = H(M) and k The UTXO of the request transaction can be consumed by deriving sk from the P2PKH-UnknownPK request transaction TxID. request becomes: [Table 1]

[0115] When this method is adopted in a messaging system, C k Note that the construction of k = sk + k can be automated, i.e., the sender and receiver do not need to communicate any additional time for this construction. When Alice issues a request transaction, the outpoint <TxID request Send Bob an acknowledgement template containing ||0>, which allows Bob to spend the UTXO. So the acknowledgement looks like this: [Table 2]

[0116] Security rationale: The only way to recover sk should be through knowledge of k, e.g., a message. This holds true in the random oracle model because k and H(sk G) are indistinguishable from random. Therefore, the lock script cannot learn anything from sk, proving the zero-knowledge nature of the method.

[0117] The lock script can be summarized as follows: P2PKH-UnknownPK Method a - Lock Script: OP_DUP OP_HASH160<H(sk·G)> OP_EQUALVERIFY OP_CHECKSIG OP_RETURN <C k > P2PKH-UnknownPK Method A - Unlock Script: <SIG sk > <(sk·G)>

[0118] P2PKH-UnknownPK method a can verify that a read receipt was sent, but it cannot prove that it was sent by Bob. Because the read receipt does not contain any identity-related information, anyone who knows the contents of message M can claim to have sent the read receipt. To solve this problem, we construct the lock and unlock scripts as follows: P2PKH-UnknownPK Method B - Lock Script: OP_OVER OP_HASH160<H(sk·G)> OP_EQUALVERIFY [Point Addition] OP_CHECKSIG OP_RETURN <C k > P2PKH-UnknownPK Method B - Unlock Script:

number

number

[0119] By constructing the lock script in P2PKH-UnknownPK method b, Bob can obtain his public key PK B to her unlock script to prove to Alice that it is she who is sending the read receipt. This structure is useful for Alice to send a request transaction without knowing Bob's public key, allowing Bob to authenticate himself. It also provides flexibility for Alice to redeem the locked funds if Bob does not send a read receipt. Alice can redeem the funds using the following unlock script:

number

number

[0120] However, this means that this structure is also vulnerable to someone who knows the message and can send a read receipt by adding an arbitrary public key to the unlock script. Therefore, if Alice does not require additional identity authentication for the read receipt and assumes that the message will not be opened / read by anyone other than Bob, P2PKH-UknownPK scheme a, which has a smaller script size, is more suitable than b.

[0121] 7.3.2 P2PKH-KnownPK method Alice has Bob's public key, PK B If you know this, you can create a lock script like this: P2PKH-KnownPK Method c - Lock Script: OP_HASH160<H(sk·G)> OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK B )> OP_EQUALVERIFY OP_CHECKSIG OP_RETURN <C k >

[0122] Bob is the unlock script

number

number

[0123] To address the issue of Alice being unable to redeem her locked funds in P2PKH-KnownPK scheme c, we add Alice's public key to a multisig-based locking script, as shown below. P2PKH-KnownPK method - Lock script: OP_HASH160<H(sk·G)> OP_EQUALVERIFY OP_1 <PK A > <PK B > OP_2 OP_CHECKMULTISIG OP_RETURN <C k >

[0124] The corresponding unlock script is

number

number

[0125] Note that P2PKH-KnownPK schemes c and d tend not to embed the message hash value in Bob's public key. There are two reasons for not embedding it. First, it may be consistent with the construction of locking scripts in previous P2PKH schemes. Second, a third party (such as an auditor) may be able to verify the integrity of the message for some reason, knowing the message itself.

[0126] 7.4 Example of payment hashing to R puzzle The P2RPH technique is another way to include the hash value of a message in the lock script. The details of the P2RPH method when Bob's public key is known / unknown are described below.

[0127] 7.4.1 P2RPH-KnownPK The R puzzle is r=[k·G] x It can be used to prove knowledge of k by revealing the message. P2RPH-UnknownPK scheme a has the same feature as P2PKH-UnknownPK scheme a in that anyone who knows the message can use the UTXO of the request transaction. Furthermore, this P2RPH-UnknownPK scheme a allows the recipient to prove that the read receipt was sent by the recipient themselves. The lock script for P2RPH-UnknownPK scheme a is constructed as follows: P2RPH-UnknownPK Method a - Lock Script: OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160<H(r)> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG The script to unlock the read receipt looks like this: P2RPH-UnknownPK Method A - Unlock Script: <sig> <pk><SIG r >

[0128] Also, if Alice wants to redeem a request transaction that has not been redeemed by Bob, the SIG

number

number

[0129] Alice has Bob's public key, PK B If we know the locking script for the request transaction, we can construct it as follows: P2RPH-KnownPK method b - Lock script: OP_HASH160 <H(PK B )> OP_EQUALVERIFY OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160<H(r)> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG The corresponding unlock script in the read receipt message can be constructed as follows: P2RPH-KnownPK Method b - Unlock Script: <sig> <pk><SIG r > <PK B >

[0130] A penalty kick is a penalty kick B In that case, the corresponding SIG may be B from

number

[0131] An alternative configuration for the lock and unlock scripts is shown below. P2RPH-KnownPK Method c - Lock Script: OP_OVER OP_HASH160 <H(PK B )> OP_EQUALVERIFY OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160<H(r)> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG P2RPH-KnownPK Method c - Unlock Script:

number

[0132] remarks: The lock script in P2RPH-KnownPK method b allows Alice (or anyone who knows the message) to redeem the locked output if Bob does not send a read receipt. Furthermore, if a read receipt is sent by Bob, Bob can prove the transmission if Alice asks Bob to authenticate the read receipt. However, the vulnerability of this method is that the message and Bob's public key PK B Anyone with knowledge of the scheme can claim the funds. The locking script in P2RPH-KnownPK method c locks the bitcoins so that only Bob can use them.

[0133] The locking script in P2RPH-UnknownPK scheme a allows us to prove that Bob sent a read receipt. If Bob does not send a read receipt, Alice can redeem the funds. However, it suffers from the same flaw as P2PKH-UnknownPK scheme b and P2RPH-KnownPK scheme b: anyone who knows M can spend the UTXO. Therefore, how we construct the locking script for the request transaction depends on Alice's needs.

[0134] As can be seen, in P2RPH-KnownPK schemes b and c, Bob uses the public key PK in the unlock script. B can prove that the read receipt was sent by him. Bob can achieve this in several ways, for example, by using PK B is linked to Bob's ID. Alternatively, Bob can use the PK B Demonstrate control of the private key associated with the PK B For example, you can pay a certain amount of Bitcoin to unlock it.

[0135] To allow Bob to send such a receipt, Alice must have a TxID request The outpoint of the request transaction must be sent to Bob, which is used to input the read receipt. This is because the request transaction does not pay directly to Bob's public key, so Bob must consume that UTXO of the request transaction and then pay himself to get the funds. Bob inputs the unlock script and lock script that correspond to the read receipt transaction template, and the TxID read to the blockchain. The messaging system (e.g. Outlook or Gmail) may be linked to a wallet service that allows for signatures and transaction generation. That way, Bob can authorize the messaging system to automatically send a read receipt after opening the message, simply by utilizing the hash value of the entire message.

[0136] This can be done via a popup that appears on Bob's screen, which offers the option to directly use the hash value of the entire message. Once this option is confirmed (by Bob), the messaging system will calculate Bob's sk and r and generate the corresponding signature. The process of sending the request from Alice and returning the read confirmation from Bob is explained in Figure 7.

[0137] Figure 7 shows the process of sending a read receipt from Alice 103a to Bob 103b. Alice creates a message and places it in the message send box 615. The message send box 615 sends message M to Bob 103b in step 605 and calculates a cryptographic puzzle based on the message in step 620. The message send box constructs a request blockchain transaction, Tx_request 625, and sends this draft transaction to the wallet manager. The wallet manager completes transaction Tx_request 625 and sends the completed transaction to the blockchain 640. Bob's wallet manager receives Tx_request 625 from the blockchain 640 and sends the cryptographic puzzle to Bob's message manager in step 645. The message manager 660 calculates the solution to the cryptographic puzzle. Bob chooses to send a response by accepting the message manager's proposed response transaction, Tx_response 655, which the message manager sends to the blockchain 640. Alice monitors this response transaction 655 on the blockchain and confirms that Bob received message M.

[0138] Note that with this option, Bob only needs to check the read receipt option for the message, authorize the messaging system to generate a signature, and send the read receipt. Such a read receipt is called an open read receipt because Bob can send it without reading the message details. In this case, it is difficult to prevent others from sending such "open" read receipts on Bob's behalf. For example, if Bob leaves his desk without locking his laptop, someone could check Bob's email, click the read receipt, and send it. This has the same drawback as the read receipt method in existing email systems described in Section 6. However, the protocol method described here can provide Bob with immutable evidence on the blockchain that such a read receipt was sent. When such an unexpected read receipt is sent, Bob may receive a notification from his wallet that the funds have been received.

[0139] So far, P2PKH and P2RPH schemes offer the simplest case without complex requirements for a single read receipt. The sender may not only want confirmation that the message was opened, but also that its contents were read. For example, the message contains an annual yield report, and Alice asks Bob to confirm some information M', which may be important data in the report. The hash value of such information is denoted as k' = H(M'). In this case, in a P2PKH solution, Alice can access the message using another private key sk. k Generate C k’ =sk k’ + k'. Bob reads the report and calculates C k’ =sk k’ + You may need to calculate k' = H(M'), which is used to calculate k'. For the P2RPH solution, k' = [k' G] x is.

[0140] To confirm M', the messaging system may offer a second option in a popup. This second option requires Bob to confirm that he has read a specific part of the information M'. After Bob has obtained the necessary information from the message, he can enter k' = H(M') into the system. Once k' is entered, C k’ =sk k’ + k' or k'=[ k' G] x is triggered. The message system then generates a corresponding signature and sends a read receipt.

[0141] The concern here is that instead of reading the message himself, Bob may use some technical tool to obtain the content specified by Alice. If Bob does this, his behavior is called fraud and the message will be considered opened but not read. Bob enters the obtained information into the messaging system. The entered information is then passed to SIG via r'. r’ In the message system,

number

[0142] 7.5 Read and agree or read but do not agree Alice might ask Bob to verify the accuracy of something in the message, such as the proposed bid price for a project. Bob does not agree with the bid price, but wants to send a read receipt confirming that he has read it and does not agree. To accomplish this, Alice needs to know Bob's public key, PK B Assuming you know, you can add a conditional clause to the lock script of the request transaction as follows: P2PKH-KnownPK method c' - Lock script: OP_DUP OP_HASH160<H(sk·G)> OP_EQUALVERIFY OP_IF OP_DROP OP_DUP OP_HASH160 <H(PK B )> OP_EQUALVERIFY OP_CHECKSIG OP_RETURN <C k > OP_ELSE OP_HASH160 <H(sk k' ·G)> OP_EQUALVERIFY OP_IF OP_DUP OP_HASH160 <H(PK B )> OP_EQUALVERIFY OP_CHECKSIG OP_RETURN <C k' > OP_ELSE OP_FALSE OP_ENDIF OP_ENDIF or P2PKH-KnownPK method c' - Lock script: OP_OVER OP_HASH160 <H(PK B )> OP_EQUALVERIFY OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_DUP OP_HASH160<H(r')> OP_EQUALVERIFY OP_IF OP_DROP OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG OP_ELSE OP_HASH160<H(r)> OP_EQUALVERIFY OP_IF OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG OP_ELSE OP_FALSE OP_ENDIF OP_ENDIF

[0143] Bob is SIG sk’ or SIG r’ By unlocking the funds, Bob is agreeing to the terms specified in the message. In addition, Bob is also agreeing to the terms specified in the SIG sk or SIG r to unlock the output and confirm that you have read the message but do not agree with information M'.

[0144] Note that each opcode in the lock script is calculated as one byte, and the size of the other inputs is calculated as follows: <>: 1 byte, which represents the opcode used to push data onto the stack. Compressed public key: 33 bytes HASH160 address: 20 bytes C k (same size as private key): 32 bytes SIG: 73 bytes Add points: 100 bytes or more Table 1 lists the characteristics of all exemplary approaches. [Table 3] Among all the example methods, P2RPH-UnknownPK method a has the smallest locking script and the second smallest overall script size. This method allows Alice the flexibility to redeem funds and allows Bob to authenticate himself. Furthermore, if Bob's public key is associated with his identity, this method protects Bob's privacy by not including his public key in the locking script. However, this method may not provide all of these benefits in situations with multiple read receipts. More details are provided in the next section.

[0145] 7.6 Multiple Read Receipts Alice may request multiple read receipts from multiple recipients. Similar to the single read receipt scenario, request transactions are also generated based on different contexts. For example, Alice may or may not know the recipient's public key used to unlock the funds in the request transaction.

[0146] Suppose Alice has no special requirements for read receipts and creates an n-request transaction with n outputs. For simplicity, we only consider the case where the locking script for each output is constructed using the same method, e.g., P2PKH-KnownPK method c. However, there are cases where the locking script for each output is constructed in a different way. For example, the first output uses P2PKH-KnownPK method c, and the second output uses P2PKH-KnownPK method d.

[0147] 7.6.1 Recipient's public key is known Alice may send the same message to multiple recipients and request corresponding read receipts. The locking script for each output can be constructed according to P2PKH-KnownPK methods c and d and P2RPH-KnownPK methods b and c. However, P2RPH-KnownPK method b is vulnerable to Alice because she may receive multiple read receipts from the same recipient who knows message M. P2PKH-KnownPK methods c and c only allow recipients to spend the locked funds. In these two methods, if the recipient does not send a read receipt, the sender of the request cannot redeem the funds. However, we introduce P2RPH-KnownPK method c as an example of a P2RPH-KnownPK method with multiple read receipts. P2PKH-KnownPK method d allows either the recipient or the sender to lock spent funds. Therefore, this section describes P2PKH-KnownPK methods d and c.

[0148] 7.6.1.1 P2PKH-KnownPK method d Alice sends the same message M to different recipients, and each recipient B i C k = sk + k. An n-request transaction based on the P2PKH-KnownPK scheme d is as follows: [Table 4] Recipient B i can spend the UTXO using the following unlock script for read receipts: P2PKH-KnownPK method c - Unlock script:

number

[0149] TxID n-request1 The parameters for and read receipts are described below.

number

[0150] sk·G and C k is the same for all recipients, but funds b i Only B can use i Note that only Alice and B are affected. This example is useful if Alice wants to send the same message to multiple recipients and receive distinct read receipts from each recipient. The important thing is that if the sender does not redeem the funds, B i Even if the secret sk of b is leaked to other recipients, i Only B can use i That is the only thing.

[0151] Alice sends different messages M to different recipients i When sending k i = H(M i ) for each recipient B i C against k The construction of

number

number

number

[0152] 7.6.1.2 P2RPH-KnownPK method c An n-request transaction based on P2RPH-KnownPK scheme c is as follows: [Table 5] Recipient B i The unlock script for the i-th read receipt message sent by is as follows: P2RPH-KnownPK Method c - Unlock Script:

number

number

number

[0153] In a multiple-request scenario, the locking script is constructed using either P2PKH-KnownPK method d or P2RPH-KnownPK method c. This helps Alice send the same / different messages to different recipients and lock the funds individually. Furthermore, recipients can only spend the corresponding UTXO, regardless of whether they received the same or different messages. Although the size of the locking script in P2RPH-KnownPK method d is large at (128 × n) bytes, it provides Alice with more flexibility in redeeming funds.

[0154] 7.6.2 Recipient Public Key Unknown The above request transaction is executed when Alice uses the public key

number

[0155] However, these examples are not directly applicable to multiple read receipt scenarios when the same message is sent to multiple recipients, as a sender sending the same message to multiple recipients may not receive distinguishable read receipts, or one recipient may send a read receipt that was meant to be sent by another user.

[0156] Taking P2RPH-Unknown scheme a as an example, in a single read receipt scenario, Alice can use a single r value to generate a request transaction that only Bob can use. This means that only Bob will receive the message, and r = [k G]. x This works because Alice knows how to calculate r. If there are multiple read receipts, each output will contain the same r value only, so the same recipient could use each output. This is not what Alice wants to achieve with multiple read receipts. To solve this problem, Alice needs to be able to distinguish between each output, even if they have the same r value.

[0157] One proposed method is to use a random nonce z i Concatenates to message M and sends it to recipient B i If the hash value of H(M||z i ) z i can be generated with a pseudorandom number generator, making it unpredictable. i+1 Note that we do not use a sequence nonce, as its value may be easy to guess. i It is assumed that the can be securely sent to each recipient individually and directly identified by the recipient's messaging system. How this is achieved is outside the scope of this paper.

[0158] z i The details of how to embed z into P2PKH-UnknownPK method b and P2RPH-Unknown method a are described below. Note that we will only discuss this in the context of sending the same message to different recipients, since sending different messages to different recipients naturally makes each output distinct. In other words, P2PKH-UnknownPK method b or P2RPH-Unknown method a can be directly applied when sending different messages. Furthermore, z i is merely a value that helps Alice allocate requests to multiple recipients, and is not the information Alice wants to see, as described in Section 3.1.

[0159] 7.6.2.1 P2PKH-UnknownPK method a z i is generated by Alice and sent to each recipient B i where:

number

number

number

number

[0160] 7.6.2.2 P2PKH-UnknownPK method b P2PKH-UnknownPK Method b - Lock Script:

number

number

[0161] P2PKH-UnknownPK method b has a very large script size including [Add point], especially TxID n-request Note that there is a cost in

[0162] If Alice wants to verify the information in message M, she simply replaces M with the verified information M' using P2PKH-UnknownPK methods a and b.

[0163] 7.6.2.3P2RPH - Unknown PK methoda z i Concatenating with a message M gives

number

number

number

[0164] If Alice wants to check the message information, she simply adds a conditional clause to her lock script: P2RPH-UnknownPKMethoda' - Lock script:

number

[0165] The read receipt unlock script for this lock script would look like this: P2RPH-UnknownPK Method a' - Unlock Script:

number

[0166] 7.7 Discussion Existing read receipt methods using traditional methods are known only to the sender. If someone other than the message recipient (Bob) sends a read receipt, Bob will detect it. With a blockchain-based read receipt protocol, Bob can detect it by receiving a notification, such as that funds have been received, from his wallet. Furthermore, Bob can obtain immutable proof of the unexpected read receipt from the blockchain.

[0167] It also provides senders with tamper-proof request and read receipts. By publishing a request transaction, senders can prove to recipients that they sent a message and requested a corresponding read receipt. Senders can choose the appropriate method based on their needs.

[0168] 7.8 Sending encrypted messages using the IBE method In some examples, Alice may send Bob an encrypted message and request a read receipt for the associated decrypted content. One way to encrypt a message is to use identity-based encryption, where the user's public key can be any string, such as an email address or username. This means that using identity-based encryption in a messaging system eliminates the issue of the sender not knowing the recipient's public key in all scenarios. By encrypting the message using the IBE method, only the recipient can decrypt the message and only the recipient can send the read receipt. This means that the sender does not need to request any additional identifying information from the recipient for the read receipt.

[0169] This section describes how request and response blockchain transactions are generated when identity-based encryption methods are used in a message system.

[0170] Here, we will only explain P2PKH-UnknownPK scheme a and P2RPH-UnknownPK scheme a, which do not include the recipient's public key in the lock script, with some modifications, but in general, any of the methods described here can be used. These methods adopted in this section are called modified methods. The functions that can be realized by the modified P2PKH-UnknownPK scheme a and P2RPH-UnknownPK scheme a include the following: Lock scripts are different for each recipient. · Locking scripts give senders the flexibility to redeem locked funds if the recipient does not send a read receipt. The locking script hides the recipient's public key, protecting their privacy.

[0171] Here, we present P2PKH-UnknownPK scheme a and P2RPH-UnknownPK scheme a modified in the context of multiple read receipts, since the i-th lock script can be considered as an individual lock script in the scenario of one read receipt.

[0172] In the IBE method, Alice receives a ciphertext instead of a message M.

number

number

number

number

number

number

[0173] 7.8.1 Modified P2PKH-UknownPK methoda P2PKH-UnknownPK method a is C k = sk + k. Alice receives a message M and an associated random value z i Using

number

number

[0174] In the IBE method, Alice receives the ciphertext

number

number

[0175] To send receipts and receive payments, B i You need to perform the following steps: 1. Obtain the private key associated with the recipient's ID (email address, etc.) from the PKG. 2. Encrypt the text using the assigned private key

number

number

number

number

[0176] The unlock script in the read receipt message is shown below. Modified P2PKH-UnknownPK Method a - Unlock Script:

number

[0177] 7.8.2 Modified P2RPH - Unknown Method a In the IBE method, Alice sends each recipient a

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0178] Fix P2RPH-UnknownPK Method a - Lock Script:

number

number

[0179] remarks: By using the modified P2PKH-UnknownPK method a and the modified P2RPH-UnknownPK method a, Alice i by

number

[0180] 8. Appendix Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is limited only by the appended claims, not by the described embodiments.

[0181] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0182] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of disseminating and / or storing blocks without creating and publishing them (as noted above, these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0183] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or disseminate those blocks 151 to other nodes.

[0184] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, publishing, disseminating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0185] Some embodiments are described for blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and general embodiments may use any type of suitable consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes can lock tokens for a certain period of time to earn the chance to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0186] It will be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0187] Statement 1. A computer-implemented method for requesting a read receipt for a message using blockchain, where the read receipt is evidence that the message was opened, the method being performed by a first party; sending the message and / or an encrypted version of the message to a second party; generating a cryptographic puzzle based on the message; generating a request blockchain transaction, the request blockchain transaction having a first output locked by a first locking script, the first locking script configured to, when executed with a first unlocking script of a response blockchain transaction, require the first unlocking script to include a solution to a cryptographic puzzle; determining that the message has been opened in response to determining that the first output has been unlocked.

[0188] Statement 2. The method of statement 1, wherein the cryptographic puzzle is based only in part on the first message.

[0189] Statement 3. The method of statements 1 or 2, wherein the step of generating a cryptographic puzzle includes generating a first hash based on the message and generating a first value based on the first hash and a first private key, the request transaction having the first value, and the solution including a signature generated using the first private key.

[0190] Statement 4. The method of statement 3, wherein the first output includes a first value.

[0191] Statement 5. The method further generating a first hash based on the message and a first pseudo-random number; generating a second hash based on the message and a second pseudorandom number; sending the first random number and / or an encrypted version of the random number to a second party; sending the message and the second random number and / or an encrypted version of said random number to a third party; The method of statement 3 or statement 4, comprising generating a second private key and a second value, wherein the second value is based on the second private key and the second hash, the request blockchain transaction having a second output locked by a second locking script, the second output including the second value, and the second locking script requiring that the second unlocking script include a signature with the second private key.

[0192] Statement 6. The method of Statement 1 or Statement 2, wherein the step of generating a cryptographic puzzle includes generating a first hash based on the message, generating a first public key based on the first hash, and generating a second value based on an x-coordinate of the first public key, the request transaction includes a hash based on the first public key, and the solution has a signature including the second value.

[0193] Statement 7. The method further generating a first hash based on the message and a first pseudo-random number; generating a second hash based on the message and a second pseudorandom number; sending the first random number and / or an encrypted version of the random number to a second party; 9. The method of claim 6, further comprising: sending the message and a second pseudo-random number and / or an encrypted version of the random number to a third party; wherein the request blockchain transaction has a second output locked by a second locking script, and the second locking script requires that the second unlocking script include a signature with a key based on the second hash.

[0194] Statement 8. The method of statement 1 or 2, wherein the step of generating a cryptographic puzzle includes generating a first hash based on the message and generating a third hash based on the first hash, and the lock script requires that the first unlock script include a preimage of the third hash.

[0195] Statement 9. The method of any one of statements 1-8, wherein the first locking script requires that the first unlocking script include a signature generated using a second private key, the second private key corresponding to a second public key associated with the second party.

[0196] Statement 10. The method of any one of statements 2-8, wherein the first hash is based on only a portion of the first message.

[0197] Statement 11. The method of any one of statements 1 to 10, wherein the lock script is configured to perform point addition of at least a first public key and a second public key.

[0198] Statement 12. The method of any one of statements 1-11, wherein the lock script includes a first conditional clause sub-script, the first conditional clause sub-script configured to enable unlocking of the first output upon execution of a second unlock script of the return transaction, and the second unlock script includes a signature generated using a third private key.

[0199] Statement 13. The method of any one of statements 1 to 13, wherein the locking script includes a second conditional clause subscript, the second conditional clause subscript being configured to require that the first unlocking script of the response transaction further includes either i) a signature generated based on the first hash, or ii) a signature generated using a private key corresponding to a public key associated with the second party.

[0200] Statement 14. The method of any one of statements 1 to 13, wherein the message is sent in encrypted form.

[0201] Statement 15. The method of statement 14, including encrypting the message using an identity-based encryption scheme, the encrypting being based on a public key associated with a second party.

[0202] Statement 16. The method of any one of statements 1 to 15, wherein the first party further sends a transaction outpoint of the request blockchain transaction to the second party.

[0203] Statement 17. A computer-implemented method for sending a read receipt for a message using blockchain, wherein the read receipt is evidence that the message was opened, the method being performed by a second party; receiving a message and / or an encrypted version of the message; identifying a request blockchain transaction, the request blockchain transaction including a first output locked by a first locking script, the first locking script configured such that when executed with a first unlocking script of a response blockchain transaction, the first unlocking script requires that the first unlocking script include a solution to a cryptographic puzzle; generating a response blockchain transaction, the response blockchain transaction including a first input that references a first output of the request transaction, the first input including a solution to a cryptographic puzzle, the solution being based on the message.

[0204] Statement 18. The method of statement 17, wherein the cryptographic puzzle is based only in part on the first message.

[0205] Statement 19. The method of statement 17 or statement 18, wherein the cryptographic puzzle requires knowledge of a first hash based on the message.

[0206] Statement 20. The method of statement 17, wherein the request transaction includes a first value based on a first hash and a first private key, and the solution includes a signature generated using the first private key.

[0207] Statement 21. The method of statement 17, wherein the responding blockchain transaction includes a signature generated using a second private key, the second private key being based on the first hash.

[0208] Statement 22. The method of statement 17, wherein the first locking script requires that the first unlocking script include a preimage of a third hash, the preimage of the third hash being based on the first hash, and the first unlocking script includes a preimage of the third hash.

[0209] Statement 23. The method of any one of statements 17-22, wherein the first locking script is configured to require that the first unlocking script include a signature generated using a second private key, the second private key corresponding to a second public key associated with the second party, and the first unlocking script includes the signature.

[0210] Statement 24. The method of any one of statements 19-23, wherein the first hash is based on only a portion of the message.

[0211] Statement 25. The method of any one of statements 17 to 24, wherein the lock script includes a conditional clause, the conditional clause being configured to require that the first unlock script of the response transaction further includes either i) a signature generated based on the first hash, or ii) a signature not generated based on the first hash, and the first unlock script includes either signature.

[0212] Statement 26. The method of any one of statements 17 to 25, wherein the message is received in encrypted form.

[0213] Statement 27. The method of statement 26, wherein the encrypted form of the message is the result of encrypting the message using an identity-based encryption scheme, the encryption being based on a public key associated with a second party, and the method including the step of decrypting the encrypted message using a private key corresponding to the public key.

[0214] Statement 28. A memory including one or more memory units; a processing unit including one or more processing units, A computing device, the memory storing code configured to execute on a processing unit, the code configured, when executed on the processing unit, to perform the method of any one of statements 1 to 27.

[0215] Statement 29. A computer program embodied on computer-readable storage, the computer program being configured to, when executed on one or more processors, perform the method of any one of statements 1 to 27. [Explanation of symbols]

[0216] 101 Internet, packet-switched networks 102 Computer terminals and equipment 103 users 104 blockchain nodes 105 Client Applications 106 P2P networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output< / pk> < / sig> < / pk> < / sig> < / pk>

Claims

1. 1. A computer-implemented method for requesting a read receipt for a message using blockchain, wherein the read receipt provides evidence that the message was opened, the method being performed by a first party; sending the message and / or an encrypted version of the message to a second party; generating a cryptographic puzzle based on the message; generating a request blockchain transaction, the request blockchain transaction having a first output locked by a first locking script, the first locking script configured, when executed with a first unlocking script of a response blockchain transaction, to require the first unlocking script to include a solution to the cryptographic puzzle; determining that the message has been opened in response to determining that the first output has been unlocked; A method comprising:

2. The method of claim 1 , wherein the cryptographic puzzle is based on only a portion of the first message.

3. 3. The method of claim 1, wherein generating the cryptographic puzzle includes generating a first hash based on the message and generating a first value based on the first hash and a first private key, the request transaction having the first value, and the solution including a signature generated using the first private key.

4. The method of claim 3 , wherein the first output comprises the first value.

5. The method further comprises: generating the first hash based on the message and a first pseudo-random number; generating a second hash based on the message and a second pseudo-random number; transmitting the first pseudo-random number and / or an encrypted version of the pseudo-random number to the second party; sending the message and the second pseudo-random number and / or an encrypted version of the pseudo-random number to a third party; 5. The method of claim 3 or claim 4, further comprising generating a second private key and a second value, the second value being based on the second private key and the second hash, the request blockchain transaction having a second output locked by a second locking script, the second output including the second value, and the second locking script requiring a second unlocking script to include a signature with the second private key.

6. 3. The method of claim 1, wherein generating the cryptographic puzzle includes generating a first hash based on the message, generating a first public key based on the first hash, and generating a second value based on an x-coordinate of the first public key, wherein the request transaction includes a hash based on the first public key, and the solution has a signature including the second value.

7. The method further comprises: generating the first hash based on the message and a first pseudo-random number; generating a second hash based on the message and a second pseudo-random number; transmitting the first pseudo-random number and / or an encrypted version of the pseudo-random number to the second party; 7. The method of claim 6, further comprising: sending the message and the second pseudo-random number and / or an encrypted version of the pseudo-random number to a third party; and wherein the request blockchain transaction has a second output locked by a second locking script, the second locking script requiring a second unlocking script to include a signature by a key based on the second hash.

8. 3. The method of claim 1, wherein generating the cryptographic puzzle includes generating a first hash based on the message and generating a third hash based on the first hash, and wherein the locking script requires that a first unlocking script include a preimage of the third hash.

9. 9. The method of claim 1, wherein the first locking script requires that the first unlocking script include a signature generated using a second private key, the second private key corresponding to a second public key associated with the second party.

10. The method of any one of claims 2 to 8, wherein the first hash is based on only a portion of the first message.

11. The method according to any one of claims 1 to 10, wherein the lock script is configured to perform point addition of at least a first public key and a second public key.

12. 12. The method of any one of claims 1 to 11, wherein the locking script includes a first conditional sub-script configured to enable unlocking of the first output upon execution of a second unlocking script of a return transaction, the second unlocking script including a signature generated using a third private key.

13. 14. The method of claim 1, wherein the locking script includes a second conditional clause sub-script configured to require that the first unlocking script of the response transaction further includes either i) a signature generated based on the first hash, or ii) a signature generated using a private key corresponding to a public key associated with the second party.

14. The method of any one of claims 1 to 13, wherein the message is sent in encrypted form.

15. 15. The method of claim 14, further comprising encrypting the message using identity-based encryption, the encrypting being based on a public key associated with the second party.

16. 16. The method of claim 1, wherein the first party further sends a transaction outpoint of the request blockchain transaction to the second party.

17. 1. A computer-implemented method for sending a read receipt for a message using blockchain, wherein the read receipt provides evidence that the message was opened, the method being performed by a second party; receiving a message and / or an encrypted version of the message; identifying a request blockchain transaction, the request blockchain transaction including a first output locked by a first locking script, the first locking script configured to, when executed with a first unlocking script of a response blockchain transaction, require the first unlocking script to include a solution to a cryptographic puzzle; generating a response blockchain transaction, the response blockchain transaction including a first input that references the first output of the request blockchain transaction, the first input including a solution to the cryptographic puzzle, the solution being based on the message; A method comprising:

18. 18. The method of claim 17, wherein the cryptographic puzzle is based on only a portion of the first message.

19. 19. A method according to claim 17 or claim 18, wherein the cryptographic puzzle requires knowledge of a first hash based on the message.

20. 18. The method of claim 17, wherein the request transaction includes a first value based on the first hash and a first private key, and the solution includes a signature generated using the first private key.

21. 18. The method of claim 17, wherein the response blockchain transaction includes a signature generated using a second private key, the second private key being based on the first hash.

22. 18. The method of claim 17, wherein the first locking script requires that the first unlocking script include a preimage of a third hash, the preimage of the third hash being based on the first hash, and the first unlocking script includes the preimage of the third hash.

23. 23. The method of any one of claims 17 to 22, wherein the first locking script is configured to require that the first unlocking script include a signature generated using a second private key, the second private key corresponding to a second public key associated with the second party, and the first unlocking script includes the signature.

24. 24. The method of any one of claims 19 to 23, wherein the first hash is based on only a portion of the message.

25. 25. The method of claim 17, wherein the lock script includes a conditional clause configured to require that the first unlock script of the response transaction further includes either i) a signature generated based on the first hash or ii) a signature not generated based on the first hash, and wherein the first unlock script includes either signature.

26. The method of any one of claims 17 to 25, wherein the message is received in encrypted form.

27. 27. The method of claim 26, wherein the encrypted form of the message is the result of encrypting the message using an identity-based encryption scheme, the encryption being based on a public key associated with the second party, the method including decrypting the encrypted message using a private key corresponding to the public key.

28. a memory including one or more memory units; 28. A computing device comprising: a processing device including one or more processing units; wherein the memory stores code configured to run on the processing device, the code being configured, when executed on the processing device, to perform the method of any one of claims 1 to 27.

29. A computer program embodied on a computer readable storage, the computer program being configured to perform the method of any one of claims 1 to 27 when executed on one or more processors.

Images