Proof of ownership

Abstract

A computer-implemented method for proving ownership and / or possession of data m. A data commitment value is generated based on a secret value r and data m. A challenge solution π related to a designated verifier is generated, and the challenge solution π is a zero-knowledge proof that proves knowledge of the secret value r. The data m, the challenge solution π, and the data commitment value are made available to the designated verifier. The secret value r is not known by or made available to the designated verifier.

Description

Technical Field

[0001] The present disclosure relates to a computer-implemented method for proving data ownership and / or possession, and a computer-implemented method for verifying data ownership and / or possession by a designated verifier.

Background Art

[0002] A blockchain refers to a form of distributed data structure, and copies of the blockchain are maintained and widely published at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of data blocks, each block comprising one or more transactions. Each transaction other than a so-called "coinbase transaction" points back to a preceding transaction in a series that can spread over one or more blocks, up to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often created by a process called "mining", which involves multiple nodes competing to perform cryptographic puzzles based on a defined set of ordered and validated queued transactions waiting to be included in a new block of the blockchain, i.e., "proof of work". Note that in some nodes, the blockchain may be pruned, and the disclosure of blocks may be achieved through the disclosure of just the block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes, namely, to carry digital assets (i.e., some digital tokens), to order a set of entries in a virtual ledger or registry, to receive and process timestamp entries, and / or to order index pointers in time. The blockchain may also be utilized to layer additional functionality on top of the blockchain. For example, the blockchain protocol may allow for the recording of additional user data, or an index to data, within a transaction. There is no pre-specified limit on the maximum data capacity that may be recorded within a single transaction, and thus, increasingly complex data may be incorporated. For example, this may be used to record electronic documents, or audio or video data, within the blockchain.

[0004] (Often referred to as "miners"), the nodes of a blockchain network perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, during this process, the nodes attempt to validate transactions and insert the transactions into the block templates that the nodes try to identify a valid proof-of-work solution for. When a valid solution is found, a new block is propagated to other nodes in the network, thus enabling each node to record the new block on the blockchain. To record a transaction on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network that should be propagated. A node receiving the transaction may compete to find a proof-of-work solution that incorporates the validated transaction into a new block. Each node is configured to execute the same node protocol that includes one or more conditions for the transaction to be valid. Invalid transactions are neither propagated nor incorporated into the block. Assuming that a transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) then remains registered and indexed as such at each of the nodes in the blockchain network as an immutable public record.

[0005] The node that successfully solves the proof-of-work puzzle to create the latest block is usually given a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., some tokens. The detection and rejection of invalid transactions are performed by the actions of competing nodes that act as agents of the network and are incentivized to report and block improper behavior. The widespread public disclosure of information enables users to continuously audit the actions of the nodes. The mere disclosure of the block headers enables participants to ensure the continued validity of the blockchain.

[0006] In the "output-based" model, sometimes called the UTXO (unspent transaction output) model, the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element that specifies an amount of digital assets derivable from a progressing series of transactions. A spendable output may sometimes be called a UTXO (Unspent Transaction Output). The output may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or digital assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the indicated output. Thus, consider a pair of transactions, called the first transaction and the second transaction (or the "target" transaction). The first transaction comprises at least one output that specifies an amount of digital assets and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input that comprises a pointer to the output of the first transaction and an unlocking 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 propagated and recorded within the blockchain, one of the criteria for validity applied at each node is that the unlocking script satisfy all of one or more conditions specified within the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another previous valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, although in some cases, to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model. In this case, each transaction specifies the amount to be transferred by reference to an absolute account balance, rather than by reference to the UTXOs of previous transactions in a sequence of past transactions. The current state of all accounts is recorded by a node separate from the blockchain and is continuously updated. Summary of the Invention Problems to be Solved by the Invention

[0009] Users may wish to share data, such as identification data, with verifiers. Users can prove to verifiers that the data they are sharing is appropriate by providing a prover copy of the data. However, upon receiving a proven copy of the data, the verifier can provide this data to any other third party without the user's consent.

[0010] The present disclosure relates to a method for providing a data owner with control such that a party can be convinced through it that the data is appropriate. That is, the data owner can control who can verify the data.

Means for Solving the Problem

[0011] According to one aspect disclosed herein, a computer-implemented method for proving ownership and / or possession of data m is provided. The method includes generating a data commitment value based on a secret value r and the data m, generating a challenge solution π related to a designated verifier, where the challenge solution π is a zero-knowledge proof proving knowledge of the secret value r, and making the data m, the challenge solution π, and the data commitment value available to the designated verifier, and the secret value r is not known by the designated verifier or not made available to the designated verifier.

[0012] The aspects disclosed herein may be used, for example, in the following scenarios. Alice (the data owner) enters a nightclub, and Bob, i.e., the security guard at the door, asks Alice to prove that she is over 18 years old. Alice hands her passport to Bob. After checking the passport, Bob asks Alice if he can take a photo copy of the passport photo in case the police come to check that everyone inside the nightclub is not underage. Since Alice does not want Bob to have her personal data (the authenticated proof), Alice refuses. Instead, it is possible for the police to come to Alice, and Alice will talk if she can easily prove to the police that she is over 18 years old. Therefore, Alice wants to control who can be convinced of the fact that she is old enough.

[0013] Using the method described in this specification, Alice can prove to Bob (the designated verifier) that her data is encrypted (committed and hashed) without giving Bob (a third party) Charlie enough information to prove this to Charlie. Alice can control the link between the data m and the encryption by holding the secret random value r that she used to commit to m. If Alice destroys r, the link between the encryption and the data is also permanently destroyed. The method disclosed in this specification involves a non-interactive zero-knowledge (nizk) proof of knowledge for the designated verifier to prove knowledge of the data owner's private value r. The proof π Bob is specifically crafted for Bob (the designated verifier) and he cannot convince anyone else using π Bob either.

[0014] Furthermore, in contrast to general-purpose proof systems, the system disclosed here requires no trusted setup and is fast and easy to implement.

[0015] This embodiment is mainly described with respect to the data owner (the party) proving ownership of some data, but it should be noted that this embodiment can equally be used to prove possession of some data. In some examples, the data does not necessarily belong to the data owner and the data owner only possesses the data. That is, possession of data does not necessarily imply ownership of the data, and vice versa. In these examples, the data owner may alternatively be called the data possessor. It should be understood that the term "data owner" is only used as an identifying label. In some examples, the data owner may both own and possess the data.

[0016] As an illustrative example, in the context of blockchain, for instance, some entities (commonly referred to as "wallet providers") control the private keys (i.e., the data) on behalf of their users. The user owns the keys, but the wallet provider possesses or controls the keys. As another example, Alice could be a service provider of medical records and wants to show the patient records to Bob, i.e., a doctor, on behalf of her patient (giving her authorization to do so). Alice does not own the data, which is owned by the patient, but she may still prove possession of her patient's data using the embodiments described.

[0017] For the purpose of assisting in the understanding of the embodiments of the present disclosure and for showing how such embodiments may be implemented, by way of example only, the accompanying drawings are referred to.

Brief Description of the Drawings

[0018]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5a

Figure 5b

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0019] 1. Exemplary System Overview FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet - switched network 101, i.e., a wide - area internetwork such as the Internet in general. The packet - switched network 101 includes a plurality of blockchain nodes 104 that may be configured 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 quasi - complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0020] Each blockchain node 104 comprises a peer's computer device, and different nodes 104 among the nodes 104 belong to different peers. Each blockchain node 104 comprises a processing device having one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application - specific processors, and / or field - programmable gate arrays (FPGAs), and other devices such as application - specific integrated circuits (ASICs). Each node also comprises a memory, i.e., a computer - readable storage in the form of one or more non - transitory computer - readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid - state drives (SSDs), flash memories, or EEPROMs, and / or optical media such as optical disk drives.

[0021] The blockchain 150 comprises a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed network or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean recording the entire blockchain 150. Instead, the blockchain 150 may be a pruned one as long as each blockchain node 150 records the block headers (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, and a transaction in this context refers to a certain type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or transaction method. A given blockchain uses one specific transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of digital assets as a characteristic, and an example of the characteristic is the user 103 to whom the output is cryptographically locked (which requires the signature or other solution of that user to be unlocked and thereby redeemed or consumed). Each input points backward to an output of a preceding transaction 152, thereby linking the transactions.

[0022] Each block 151 also includes a block pointer 155 that points backward to previously created blocks 151 in the chain so as to define a sequential order to the blocks 151. Each transaction 152 (other than the coinbase transaction) includes a pointer back to a previous transaction so as to define an order to the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 extends far backward to the genesis block (Gb) 153 that was the first block in the chain. One or more of the original transactions 152 early in the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0023] Each of the blockchain nodes 104 is configured to forward a transaction 152 to other blockchain nodes 104, thereby propagating the transaction 152 across the network 106. Each blockchain node 104 is configured to create a block 151 and record a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 that are waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as the "memory pool (mempool)". This term as used herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 is obligated to accept as valid and not accept any other transaction from attempting to consume the same output.

[0024] In a given current transaction 152j, each input comprises a pointer to an output of a preceding transaction 152i in a series of transactions that specifies that this output is to be redeemed or "consumed" within the current transaction 152j. To consume or redeem does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, to consume can be described as consuming the output, i.e., allocating it to one or more outputs in a subsequent transaction forward. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created and further sent to the network 106, but the preceding transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" as used herein does not necessarily refer to the time of creation or sending in a temporal series, but rather refers to the predecessor in a logical series linked by a pointer, and thus does not necessarily exclude the possibility that transactions 152i, 152j are created or sent out of order (see the following explanation for orphan transactions). The preceding transaction 152i may be equivalently referred to as an antecedent transaction or a previous transaction.

[0025] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of user 103a to whom the output of the preceding transaction 152i is locked. Next, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input of the preceding transaction 152i to a new user or entity 103b as specified in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of whom may be the original user or entity 103a for providing change). In some cases, a transaction can also have multiple inputs to gather the amount together from multiple outputs of one or more preceding transactions and redistribute it to one or more outputs of the current transaction.

[0026] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or organization, desires to create a new transaction 152j (either manually or by an automated process adopted by the party), the party creating it sends the new transaction from its computer terminal 102 to the recipient. The party creating or the recipient of the transaction ultimately sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which today is typically a server or data center, but in principle could be another user terminal). It is not excluded that in some instances, the party 103 creating the new transaction 152j may send the transaction directly to one or more of the blockchain nodes 104 instead of the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature that depends on the previous transaction 152i in the ordered series of transactions 152. In such an output-based transaction protocol, this may involve checking that the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the conditions specified in the output of the preceding transaction 152i that the new transaction consumes (or "allocates"), which typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be at least partially specified by a script included in the output of the preceding transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone or may result from a combination of these.In either case, if the new transaction 152j is valid, the blockchain node 104 transfers it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and thus transfer the new transaction 152j to one or more additional nodes 104, etc. In this way, the new transaction is propagated across the entire network of blockchain nodes 104.

[0027] In the output-based model, the rule for whether a given output (e.g., UTXO) is allocated (or "consumed") is whether it has already been validly redeemed by an input of another transaction 152j going forward 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 not valid, the transaction 152j is not propagated (unless flagged as invalid and warned about) or recorded in the blockchain 150. This protects against double spending, whereby a transactor attempts to allocate the output of the same transaction more than once. On the other hand, the account-based model protects against double spending by maintaining account balances. Again, because there is a defined order to transactions, the account balance always has a defined single state.

[0028] In addition to validating transactions, blockchain node 104 also competes to be the first to create a block of transactions in a process commonly called mining, which is supported by "proof of work." At the blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in the blocks 151 recorded on the blockchain 150. The blockchain node then competes to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with and hashed with the representation of the ordered pool of pending transactions 154, the output of the hash meets a certain condition. For example, the certain condition may be that the output of the hash has a certain number of leading zeros. It should be noted that this is only one particular type of proof-of-work puzzle and other types are not excluded. The characteristic of a hash function is that the hash has an output that is unpredictable with respect to its input. Therefore, this search can only be performed by brute force and thus consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0029] The first blockchain node 104 that solves the puzzle notifies the network 106 of this and provides a solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (it is easy to check that the solution satisfies the conditions for the output of the hash when given the solution to the hash). The first blockchain node 104 accepts the block and thus propagates the block until a threshold consensus of other nodes that enforce the protocol rules is reached. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 that points back to the previously created block 151n-1 in the chain is also assigned to the new block 151n. A significant amount of effort, for example in the form of a hash, required to create the proof-of-work solution signals the intention of the first node 104 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, otherwise known as double spending. Once created, the block 151 cannot be modified after being recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointer 155 also imposes a sequential order on the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each of the blockchain nodes 104 in the network 106, this thus provides an immutable public ledger of the transactions.

[0030] Note that various blockchain nodes 104 competing to solve a puzzle at any given time may do so based on various snapshots of a pool 154 of transactions not yet issued at any given time, depending on when they began searching for a solution or the order in which transactions were received. Whichever of them first solves their respective puzzle defines which transactions 152 are included in the next new block 151n and in what order, and the current pool 154 of unissued transactions is updated. The blockchain nodes 104 then continue competing to create a block from the newly defined ordered pool 154 of unissued transactions, and so on. The protocol also exists to resolve any possible "forks", which is the case when two blockchain nodes 104 solve their puzzles in very close succession to each other such that conflicting appearances of the blockchain are propagated among the nodes 104. In short, whichever fork grows the longest becomes the final blockchain 150. Note that this should not affect the network's users or agents when the same transactions appear in both forks.

[0031] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to newly allocate an additional amount of digital assets committed to be received in a new special type of transaction that distributes a specified additional amount of digital assets (not in agent - to - agent or user - to - user transactions where a certain amount of digital assets are transferred from one agent or user to another agent or user). This special type of transaction is usually called a "coinbase transaction", but may also be called an "initial transaction" or a "generation transaction". It typically forms the first transaction of a new block 151n. Proof - of - work signals the intention of the node constructing the new block to follow the protocol rules that allow this special transaction to be redeemed later. The blockchain protocol rules may require a maturity period, for example, 100 blocks, before this special transaction can be redeemed. Often, normal (non - generation) transactions 152 also specify an additional transaction fee in one of their outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was issued. This fee is usually called a "transaction fee" and is explained below.

[0032] Due to the resources involved in transaction validation and publication, typically, at least each of the blockchain nodes 104 comprises a server with one or more physical server units, and even takes the form of an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal, or a group of networked user terminals together.

[0033] The memory of each blockchain node 104 stores software configured to execute on the processing device of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action taken by the blockchain node 104 herein may be performed by software executed on the processing device of each respective computer device. The node software may be implemented within one or more applications in the application layer, or in lower layers such as the operating system layer or protocol layer or any combination thereof.

[0034] Also, each computer device 102 of a plurality of parties 103 acting as consuming users is connected to the network 101. These users may interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in a transaction. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as recording entities that record a copy of the blockchain (e.g., obtaining a copy of the blockchain from a blockchain node 104).

[0035] Part or all of the parties 103 may be connected as part of a network that is overlaid on top of a different network, such as the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be 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 required roles 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) the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for purposes of illustration, namely, a first party 103a and that person's respective computer device 102a, and a second party 103b and that person's respective computer device 102b. It will be understood that there may be far more such parties 103 and their respective computer devices 102 and that they may participate in the system 100, but they are not shown for purposes of simplicity. Each party 103 may be an individual or an organization. By way of pure example, in this specification, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and any reference in this specification to Alice or Bob may be replaced, respectively, with "the first party" and "the second party".

[0036] The computer device 102 of each party 103 includes respective processing devices that include one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 further includes a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units that employ one or more memory media, such as magnetic media like hard disks, SSDs, flash memory, or electronic media like EEPROM, and / or optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software that includes respective instances of at least one client application 105 configured to execute on the processing device. It will be understood that any action taken on behalf of a given party 103 can be performed using software executed on the processing device of the respective computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device like a smartwatch. The computer device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, accessible via the user terminal.

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

[0038] The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable a transaction 152 to be created, authorized (e.g., signed) by each respective party 103 and sent to one or more Bitcoin nodes 104, and then propagated across the network of Bitcoin nodes 104, thereby enabling it to be included in the blockchain 150. The other is to report back to each party the amount of digital assets that the party currently owns. In an output-based system, this second functionality comprises reconciling the amounts defined in the outputs of various transactions 152 scattered across the entire blockchain 150 that belong to the respective party.

[0039] Note: Although various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting, and instead any of the client functionalities described herein may instead be implemented in a set of two or more separate applications that interface, for example, via an API, or one may be plugged into the other. More generally, client functionality may be implemented in the application layer, or in a lower layer such as the operating system, or any combination thereof. The following is described with respect to the client application 105, but it will be understood that this is not limiting.

[0040] Instances of the client application or software 105 on each computer device 102 are operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send the transaction 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transaction for which each party 103 is the recipient (or, in an embodiment, because the blockchain 150 is a public facility that provides trust among transactions through its partial public visibility, to actually inspect the transactions of other parties in the blockchain 150). The wallet function on each computer device 102 is configured to compose and send the transaction 152 according to the transaction protocol. As described above, each blockchain node 104 executes software configured to validate the transaction 152 according to the blockchain node protocol and transfer the transaction 152 to propagate it across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to implement a given transaction model together. 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.

[0041] When a given party 103, e.g., Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice composes the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 that is best connected to Alice's computer 102. Any given blockchain node 104, upon receiving the new transaction 152j, processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets several conditions for it to be "valid", examples of which will be briefly described in more detail. In some transaction protocols, the conditions for validation may be configurable per transaction by the script included in the transaction 152. Alternatively, the conditions may simply be built-in functions of the node protocol or may be defined by a combination of the script and the node protocol.

[0042] In the condition where the test for a newly received transaction 152j to pass in order to be considered valid (i.e., in the condition where it is "validated"), any blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set 154 of transactions maintained at that blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 forward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, then assuming the transaction 152j is valid, this means that the transaction 152j will soon be propagated across the entire network 106 as a whole.

[0043] Once approved to the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins to compete to solve the proof-of-work puzzle in the latest version of each of those pools of 154 that includes the new transaction 152. (Although other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, recall that whoever gets there first gets to define the set of transactions to be included in the latest block 151. Eventually, the blockchain node 104 attempts to solve the puzzle for a portion of the ordered pool 154 that includes Alice's transaction 152j.) When proof-of-work is being done on the pool 154 that includes the new transaction 152j, the new transaction 152j invariably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 has a pointer back to a more previous transaction, so the order of the transactions is also invariably recorded.

[0044] Different blockchain nodes 104 may first receive different instances of a given transaction, and thus, there may be competing appearances as to which instance is "valid" before one instance is issued in the new block 151. In that regard, all blockchain nodes 104 agree that the issued instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance is recorded in the blockchain 150, that blockchain node 104 shall accept this and discard (i.e., treat as invalid) the instance it first accepted (i.e., the instance not issued in block 151).

[0045] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by reference to an absolute account balance, rather than by reference to the UTXOs of prior transactions in a series of past transactions. The current state of all accounts is recorded and constantly updated by nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the transaction execution account ledger (also called a "position") of the account. This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be signed with the transaction. This data field may point to prior transactions, for example, if it contains a prior transaction ID in the data field.

[0046] 2. UTXO-based Model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following is described by reference to an output-based or "UTXO" - based protocol. However, this does not necessarily limit all possible embodiments. An exemplary UTXO-based protocol is described with reference to Bitcoin, but note that it can be equally implemented in other exemplary blockchain networks.

[0047] In the UTXO-based model, each transaction ("Tx") 152 has a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) that can be used as a source for an input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO includes a value that specifies the amount of the digital asset. This represents the set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also include a header 201, which may include an indicator of the sizes of the input field 202 and the output field 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and is recorded in the header 201 of the raw transaction 152 submitted to the node 104.

[0048] For example, Alice 103a desires to create a transaction 152j that transfers a certain amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes a certain amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the series and transfers at least some of this to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 nor that Tx1 is the very next transaction in the pool 154. Tx1 can point back to any preceding (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0049] The preceding transaction Tx0 may already be validated and included in block 151 of the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in a new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or Tx0 may even be sent after Tx1 if the node protocol allows "orphan" transactions to be buffered. The terms "preceding" and "subsequent" as used herein in the context of a series of transactions refer to the order of the transactions in the series as defined by the transaction pointers specified within the transactions (such as which transaction points to which other transaction backwards). They may be equivalently replaced with "former" and "successor", or "ancestor" and "descendant", "parent" and "child", or the like. 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. That said, a subsequent transaction (descendant transaction or "child") that refers to a preceding transaction (ancestor transaction or "parent") is not validated until the parent transaction is validated, and is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, an orphan may be discarded or buffered for some period of time while waiting for the parent.

[0050] One of one or more outputs 203 of a preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of digital assets represented by the UTXO, and a locking script that specifies conditions that must be satisfied by an unlocking script in an input 202 of a subsequent transaction in order for the subsequent transaction to be validated and thus for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script typically specifies an unlocking condition that an unlocking script in an input of a subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction was locked.

[0051] (Also called scriptPubKey) The locking script is a fragment of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (with a capital S) used by the blockchain network. The locking script specifies what information is required to consume the transaction output 203, for example, specifying the requirements for Alice's signature. The unlocking script appears in the output of the transaction. (Also called scriptSig) The unlocking script is a fragment of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it may include Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0052] Thus, in the illustrated example, the UTXO0 in the output 203 of Tx0 requires Alice's signature Sig P A for the locking script [Checksig P AComprises [[Checksig P A is the public key P from Alice's public - private key pair A including the notation (i.e., hash) of. The input 202 of Tx1 comprises a pointer that points backward to Tx1 (e.g., in an embodiment, the transaction ID of that transaction, i.e., TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. The input 202 of Tx1 comprises an unlocking script <Sig P A > further comprising Alice's cryptographic signature created by applying her private key from the key pair to a predefined portion of the data (which may sometimes be 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 the locking script, or by the node protocol, or by a combination of these.

[0053] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This comprises executing the locking script and the unlocking script together to check whether the unlocking script meets the conditions defined in the locking script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A ><P A >||[Checksig P A ​However, "||" represents concatenation, "<...>" means a location within the data on the stack, and "[...]" is a function provided by the locking script (in this example, a stack - based language). Equivalently, the scripts may be executed one after another using a common stack rather than concatenating the scripts. In either case, when executed together, the scripts use the public key P of Alice as contained within the locking script in the output of Tx0 A to authenticate that the unlocking script in the input of Tx1 contains the signature of Alice that signs the expected part of the data. The expected part of the data itself (the "message") also needs to be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (so that, since it already essentially exists, no separate element specifying the signed part of the data needs to be included in plain text).

[0054] Details of authentication by public - key cryptography are well known to those skilled in the art. Basically, when Alice signs a message using her secret key, given Alice's public key and the message in plain text, 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 on the message, thus enabling any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or a part of a transaction or the like can, in an embodiment, mean signing the hash of that piece of data or part of the transaction.

[0055] If one or more conditions specified in the locking script of Tx0 are satisfied by the unlocking script in Tx1 (so, in the illustrated example, if 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 the ordered pool 154 of pending transactions. The blockchain node 104 also transfers the transaction Tx1 to one or more other blockchain nodes 104 in the network 106, and as a result, the transaction Tx1 is propagated across the network 106. If Tx1 is validated and included in the blockchain 150, this defines that UTXO0 from Tx0 has been consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 is invalid even if all other conditions are met. Thus, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been consumed (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important that the blockchain 150 imposes a defined order on the transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking which UTXO203 in which transaction 152 has been consumed, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction in the blockchain 150.

[0056] If the total amount specified among all the outputs 203 of a given transaction 152 is greater than the total amount indicated by all of its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction is not propagated and is not included in the block 151 either.

[0057] Note that in the UTXO-based transaction model, a given UTXO needs to be consumed in its entirety. It is not possible to "leave behind" the fractional part of the amount defined within the UTXO as the consumed amount while consuming another fractional part. However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined within UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not wish to give the entire amount defined within UTXO0 to Bob, she can use the remainder to give herself change in the second output of Tx1 or make a payment to another party.

[0058] In practice, Alice also typically needs to include a fee for Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and thus, although technically valid, may not be propagated and may not be included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if the person does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount indicated by input 202 and the total amount specified in the outputs 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, the pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that, alternatively or in addition, the transaction fee may be explicitly specified within its own UTXO among the UTXO203 of transaction 152.

[0059] The digital assets of Alice and Bob consist of UTXOs locked to them in some transaction 152 somewhere in blockchain 150. Thus, typically, the assets of a given party 103 are spread across all the UTXOs of various transactions 152 across the entire blockchain 150. There is no single number recorded anywhere in blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in client application 105 to collate together the values of all the various UTXOs that are locked to each party and have not yet been spent in a subsequent transaction forward. The wallet function can do this by querying a copy of blockchain 150 as recorded in any of the Bitcoin nodes 104.

[0060] Note that script code is often represented schematically (i.e., without using exact language). For example, opcode (operation code) may be used to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that, when preceded by OP_FALSE at the start of a locking script, can record data within a transaction, thereby creating a non-consumable output of the transaction that can record data immutably in blockchain 150. For example, the data may comprise a document that it is desired to record in the blockchain.

[0061] Normally, the input of a transaction is the public key P AIt includes a digital signature corresponding thereto. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs part of the transaction input and part or all of the transaction output. The specific part of the output it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of the signature to select which output is signed (and thus fixed at the time of signing).

[0062] The locking script may sometimes be referred to as "scriptPubKey" with reference to the fact that the locking script contains the public key of the party to whom each transaction is locked. The unlocking script may sometimes be referred to as "scriptSig" with reference to the fact that the unlocking script supplies the corresponding signature. However, more generally, the condition for a UTXO to be redeemed, which includes authenticating the signature, is not necessarily required in all applications of the blockchain 150. More generally, a scripting language may be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may sometimes be preferred.

[0063] 3. Side Channel As shown in FIG. 1, the client applications in each of the computer devices 102a and 102b of Alice and Bob, respectively, may have additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (upon the inducement of either party or a third party). The side channel 107 enables 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 a transaction 152 between Alice and Bob without the transaction being (yet) registered on the blockchain network 106 or entering the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way may be referred to as sharing a "transaction template". A transaction template may not have 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, agreed-upon amounts or conditions, data content, etc.

[0064] Side channel 107 may be established via the same packet - switched network 101 as blockchain network 106. Alternatively or additionally, side channel 107 may be established via various networks 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. Generally, side channel 107, as referred to anywhere in this specification, may comprise one or more links via one or more networking technologies or communication media for exchanging data "off - chain", i.e., separately from blockchain network 106. When two or more links are used, the entire bundle or set of off - chain links may sometimes be referred to as side channel 107. Thus, when it is said that Alice and Bob exchange some pieces or such of information or data via side channel 107, it should be noted that this does not necessarily imply that all of these pieces of data must be sent via exactly the same link or even the same type of network.

[0065] 4. Zero - Knowledge Proof

Number

Number

Number

Number

Number

Math

Math

Math

[0066] The symbol “+” is, in this specification,

Math

Math

Math

[0067] 4.1 Sigma Protocol Let R be an NP relation. That is, a subset of {0,1} * ×{0,1} * such that (st, w) ∈ R can be checked within polynomial time in the length of st, and w of that length is also a polynomial in the length of st.

[0068] The first element of that tuple is called the statement and is public information. The second element is called the witness (to the statement) and is private. There may be two or more witnesses for a given statement. The induced NP language LR is a set of statements. L R ={st: ∃w such that (st, w) ∈ R}

[0069] The Sigma protocol is a 3-round protocol between a prover and a verifier. Both parties receive the statement st as input. Additionally, the prover receives the witness w as auxiliary input, and the verifier may receive any arbitrary auxiliary input. The prover proves the knowledge of the witness w by providing the challenge solution π, also called the public transcript herein, to the verifier, and the verifier verifies the challenge solution π based on the protocol.

[0070] The Sigma protocol may be implemented using the following steps. 1. The prover calculates the commitment A using the randomness a. The prover then sends A to the verifier while keeping a secret. 2. The verifier randomly samples the challenge e and sends it to the prover. 3. The prover calculates the response z (using w and a) and sends it to the verifier. 4. The verifier accepts the statement st as valid or not based on the public transcript π := (A, e, z).

[0071] The Sigma protocol has the following properties.

[0072] Completeness. If (st, w) ∈ R, the verifier accepts with probability 1.

[0073] Special soundness. For any pair of accepting transcripts π = (A, e, z), π' = (A, e', z') with the same commitment A (the prover's first message) and distinct challenges e ≠ e', it is possible to calculate a witness w such that (st, w) ∈ R.

[0074] Special Honest Verifier Zero-Knowledge (SHVZK). Given input st ∈ L R and a polynomial-time algorithm Sim exists for random e, which outputs an accepting transcript π = (A, e, z) that is indistinguishable from the transcripts of the protocol.

[0075] Special soundness implies a stronger property, and the sigma protocol is also a proof of knowledge (of the witness).

[0076] Also, SHVZK implies the standard notion of (honest verifier) zero-knowledge, where the simulator is tasked with simulating the transcript only when receiving the statement as input. In other words, SHVZK guarantees that no information about the witness leaks from the exchanged messages, assuming that the verifier behaves as specified.

[0077] 4.1.1 Example: Schnorr Protocol Given two group elements G,

Number

Number

Number

Number

[0078] It is easy to understand that the Schnorr protocol is complete and SHVZK. To understand why it has special soundness, note that from two accepting transcripts (A, e, z), (A, e', z') with different challenges e ≠ e', we can write z·G = A + e·H and z'·G = A + e'·H. Subtracting the second equation from the first (note that the same A is used in both), we get (z - z')·G = (e - e')·H. Thus,

Mathematics

Mathematics

[0079] 4.1.2 Interaction Removal - Fiat-Shamir Heuristic The sigma protocol is an example of a public-coin interactive proof system. That is, the message (challenge) sent by the verifier is random and independent of the prover's message. Leveraging this feature, the interactive sigma protocol can become non-interactive (only one message from the prover to the verifier) by emulating the verifier's entropy used to sample the challenge e using a cryptographic hash function. This is known as the Fiat-Shamir heuristic.

[0080] The Fiat-Shamir heuristic operates in a stronger security model. In this specification, a cryptographic hash function is modeled as a function that outputs a uniformly distributed bit string for the latest input bit string. In this security model, a "random oracle" function RO: {0,1} * →C that maps an arbitrary bit string to the space of challenges C can be constructed using a well-known hash function such as SHA256. Next, the prover simply [Number] can set [Number] and calculate e without the help of the verifier. [Number] Note that [Number] is the (public) transcript that occurs immediately after the verifier generates the challenge e in the interactive sigma protocol. Here, ctxt indicates (public) context information such as a session identifier or a party identifier that is known in advance to both parties.

[0081] The assumptions about the RO function guarantee two things. First, the challenge e is randomly distributed, so the interactive protocol only needs to satisfy zero knowledge (i.e., SHVZK) for honest verifiers. Second, the prover cannot calculate the challenge before calculating the commitment [Number] (and the statement st about that matter), so the execution order of the protocol cannot be reversed.

[0082] Different commitments [Number] Trying using it will never hit the (unique) challenge that enables the simulation, provided that the challenge space C is large enough. By medium / conservative choices we mean using challenges of size 80 or 128 bits respectively, although it should be understood that other challenge bit sizes may be used.

[0083] 4.2 Pedersen Commitment A vector Pedersen commitment or batch Pedersen commitment is a generalization of the Pedersen scheme for committing to a vector

Number

Number

[0084] This scheme has two algorithms. The description of the group

Number

Number

Number

Number

Number

Number

Number

Number

[0085] Each G1...G n , H are points on the elliptic curve such that the commitment key for n = 1 is a pair of points on the elliptic curve. Pedersen commitment gives a way in which n different messages can be committed by a single elliptic curve.

[0086] 4.2.1 Verifiable generation of commitment key The group element H is generated in a secure way such that the relationship between the exponent of the point G i and H is not known. Appropriate generation can be publicly verified.

[0087] 4.2.2 Trapdoor commitment key Exponents x1,...,x n are picked up and H := x1·G1 +...+ x n ·G n is set to generate the group element H. x := (x1,...,x nNote that the Pedersen commitment becomes non - binding in light of the knowledge of (). For example, in the case of n = 1, consider H = x·G and C = m·G + r·H. Let r':= r + x -1 By setting (m - m') mod p, it is possible to open the commitment C to an arbitrary value m'≠m. The value x may sometimes be referred to as a trapdoor or trapdoor value in this specification.

[0088] 4.3 Zero - knowledge argument with a designated verifier L R be an NP language that admits a sigma protocol. There is a framework in which the prover Alice 130a can prove a statement st∈L R only to the designated verifier Bob 103b (who holds the secret or trapdoor x) and no one else. The argument is non - interactive and the conviction is non - transferable. The latter means that even if Charlie 103c is given the secret x, Bob 103b cannot convince the third (hidden) verifier Charlie 103c of the truth of the statement.

[0089] Alice 103a generates a proof π V to prove the following statement. st∈L R , that is, "I know the secret x"

[0090] The proof π V is specifically crafted for Bob 103b. If Bob is convinced that his secret x has not been compromised, π V is indeed a proof that he can believe for himself. However, since the exact same proof may sometimes be generated by Bob 103b (proving that he knows x), Bob cannot convince Charlie 103c that st∈L R using π V or x.

[0091] If the trapdoor x is known to the designated verifier (Bob 103b), (Pedersen's etc. using a non-verifiable commitment key - see Section 4.1) a trapdoor commitment scheme may be used. The prover (Alice 103a) commits to a random value w within the commitment C, and uses C (along with the statement, and the first message A of the Sigma protocol) to generate "half" of the challenge using a hash function. The non-interactive challenge is defined as follows. e := h + w, where h := Hash(st||C||A)

[0092] The designated verifier Bob checks, in addition to the Sigma protocol check, that C opens to w. Next, since Bob can open C to any value he likes (using the trapdoor x - see Section 5.1), he runs the simulator Sim for a random challenge e to obtain the proof π := (A, e, z) and thus forge the proof π V and then can open the commitment C to w * := -Hash(st||c||A).

[0093] 5. Proof System This section specifies a proof scheme that enables the data owner to control who can be convinced of the link between their data and the hashed commitment of that data. This embodiment comprises a non-interactive proof system used by Alice (the prover) to convince Bob (the designated verifier) of the knowledge of the non-public value r used to commit to the data m.

[0094] 5.1 Statement The data owner commits to their data m in a concealing manner using a Pedersen commitment key CK DO := (G DO , H DO ). The public statement (known to at least the data owner and the designated verifier) is the following tuple.

Number

[0095] The data is encoded as an element

Number

Number

[0096] 5.2 Generation and Recording of Commitment Key The commitment key CK DO can be shared across multiple data owners, but

Number

[0097] 5.3 Prover and Designated Verifier Algorithms For a given statement st as defined above, the data owner generates a nizk argument π DV to prove that the data owner knows an opening r ∈ ZKP(st) without revealing r to the verifier. In other words, the data owner proves

Number

[0098] The designated verifier has a random secret trapdoor

Number

[0099] The algorithm given below uses the cryptographic hash function Hash [Number] to generate non-interactive challenges [Table 1]

[0100] 5.4 Forgery of Proofs The designated verifier can generate a "forged proof" that is valid for a forged statement with a forged data value m'. A third party receiving the forged proof will find that the forged proof satisfies the verification algorithm, but it may not satisfy the fact that the data owner, rather than the designated verifier, was the source of the data

[0101] Let the tuple st:=(m,C,CK DO ,obf) where obf = SHA256(C). A designated verifier equipped with knowledge of the trapdoor x can generate a valid proof for any data m even if they do not know the opening r ∈ ZKP(st). Since the designated verifier can open the commitment under their key CK DV to any value they like, and thus can pre-select the challenge of the Schnorr proof (intentionally proving knowledge of [Number] ), this is possible. The algorithm for forging proofs is detailed below

Table 2

[0102] Therefore, a third party receiving the proof π from the designated verifier cannot verify the source of the data, and more specifically, the data owner cannot prove that the data owner is the source of the data.

[0103] 6. Private Timestamp The first application example of the proof system described in Section 5 is to timestamp data in a private manner. The data owner obfuscates the data m, and the obfuscated obfDat is uploaded to the blockchain. That is, the data owner uploads the obfuscated data commitment obfDat := SHA256(C) to the blockchain while keeping the randomness r private, where C = Com(m, r, CK DO )). More generally, the obfuscation obfDat can be any hash of the data commitment value C. That is, obfDat := Hash'(C), where Hash' is a cryptographic hash function and is not necessarily SHA256 or the hash function used to generate the challenge e.

[0104] Later, without revealing the private value r, she proves to the designated verifier (only) the link between obfDat and the data m. The proof guarantees a timestamp for m to the designated verifier, and the obfuscation and non-transferability of the proof guarantee privacy to everyone other than the designated verifier.

[0105] The data is logged in the blockchain to guarantee its immutability and existence at a given time. However, due to the hidden properties of Pedersen commitments, no one can guess which data has been timestamped.

[0106] It should be understood that recording obfuscation on the blockchain results in the data being implicitly logged. That is, the data m need not be recorded on the blockchain.

[0107] 6.1 Proof of Appropriate Timestamping Whenever obfData appears in the blockchain, anyone wishing to verify the link to the data can act as a designated verifier. They are certain that m matches obfDat.

[0108] The steps for proving and verifying appropriate timestamping are as follows. 1. The designated verifier generates a trapdoor commitment key

number

number

[0109] Figure 3 shows an exemplary method for implementing the prover and verifier algorithms described above. In this example, Alice 103a is the prover and data owner, and Bob 103b is the designated verifier.

[0110] In step 1, Alice 103a generates a data commitment value C using data m, where C = Com(m, r, CK DO ), r is a secret value known only to Alice 103a, and CK DO is the data owner commitment key, i.e., Alice's commitment key. Alice 103a hashes the data commitment value to generate an obfuscated data value obfData.

[0111] In step 2, Alice 103a records the obfuscated data value obfData on the blockchain 150, i.e., a proof - of - block - chain transaction. An OP_RETURN script is used to make these values available to Bob 103b and other users. In some embodiments, the commitment value C is also recorded on the blockchain 150.

[0112] In step 3, Bob 103b retrieves the obfuscated data value obfData from the blockchain. Bob selects a trapdoor value x and uses it to generate a designated verifier commitment key CK DV , where CK DV := (G DV , H DV := xG DV ) (step 4). In step 5, Bob 103b sends his designated verifier commitment key CK DV to Alice 103a along with the obfuscated data value obfData. This message serves or includes a request for a proof π to prove the ownership and / or possession of data m.

[0113] Upon receiving the designated verifier commitment key CK DV , Alice 103a uses the designated verifier commitment key CK DV to generate a verifier commitment value D such that D = w·G DV +s·H DV (step 6). In this step, Alice 103a uses CKDV is committing to a random value w. This random value w will be used later to form the challenge e = h + w, but the commitment D is used to generate h to ensure that Alice 103a commits to m first, i.e., Alice 103a commits to w first, so w cannot be chosen based on h.

[0114] In step 7, Alice 103a generates a proof π to prove knowledge of the secret value r. Alice 103a uses the obfuscated data value obfData received from Bob 103b to identify which data m Bob 103b is requesting proof of ownership and / or possession for, and thus which secret value r to use when generating the proof π. Alice 103a may maintain a lookup table with entries (m, r, C, obfData) for performing this step.

[0115] Alice 103a then, in step 8, sends the proof π including the verifier commitment value D to Bob 103b, thereby decommitting from the random value w. Alice 103a also sends the commitment value C and the data m to Bob 103b.

[0116] Bob 103b, in step 9, generates a target verifier commitment value using DV w·G DV + s·H DV and compares it with the verifier commitment value D. If these values match, Bob 103b verifies the data commitment value C based on the proof π by performing steps 2 - 4 of the Verify algorithm described in 5.2 above. In this step, Bob checks that the decommitment (w, s) is appropriate for the commitment D, where w is the committed message and s is the opening. Bob uses his commitment key CK

[0117] In step 11, Bob 103b generates a candidate obfuscated data value by hashing the data commitment value C, and compares it with the retrieved, i.e., "target" obfuscated data value obfData. The obfuscated data value obfData retrieved from the blockchain may be referred to as the target obfuscated data value obfData.

[0118] If Bob 103b is satisfied by the comparisons performed in steps 9, 10, and 11, Bob 103b can be confident that Alice 103a is the owner of data m.

[0119] 6.2 Privacy of Timestamps via Non-Transferable Proofs After receiving (m, C, π DV ) with obfDat = SHA256(C) from the data owner (Alice 103a), the designated verifier (Bob 103b) executes the algorithm Fake proof described in section 5.4 above to generate a believable proof π * for any data m DV * ≠ m, i.e., a proof that passes the verification algorithm. Using such an ability, a third party (Charlie 103c) cannot be at all confident whether the data transferred by Bob 103b comes from the data owner or from the designated verifier himself.

[0120] In other words, Charlie 103c cannot tell whether the data was created before (by Alice 103a) uploading obfDat to the blockchain or afterwards (when Bob 103b looks at the commitment C). This means that any data coming from Bob 103b is not restricted to the timestamp obfDat and maintains the privacy of m for anyone other than Bob 103b.

[0121] FIG. 4 provides an example of information that may be provided to Charlie 103c that may pass the validation algorithm.

[0122] 7. Self-Sovereignty of Data The Proof and Verify algorithms described above may be used in a method for providing notarized data.

[0123] In a self-sovereign data notarization implementation, the data owner takes an active role in the notarization process (whereby the data is signed by a notary) and uploading the signed data to the blockchain.

[0124] The notary receives the data m but signs it obfuscated obfDat. The data owner is empowered with (a) strong privacy: no one can link the signature (recorded on-chain) back to the actual data, and (b) control over who verifies the signature: only designated verifiers (who are convinced of the existence of such a link by their attestation) can conclude, by verifying the signature, that the notary (implicitly) signed the data.

[0125] A two-phase protocol is carried out between the data owner, the designated verifier, and the notary. The parameters of the scheme, params, are pre-configured and already recorded in the blockchain. They are the notary's verification key PK for signing, and the data owner's commitment key CK. DO is located.

[0126] Phase 1: Data Notarization. In the first phase, the data owner commits to their data m and sends it along with a commitment C to the notary, who signs a hash of the commitment. The data owner then sends the obfuscated and signed data Data * :=(obfDat, σ) in the blockchain, where obfDat=SHA256(C).

[0127] Step 2: Verification of the data to be notarized. In the second step, the designated verifier retrieves Data from the blockchain * and requests the data owner for the data m and the commitment C together with the non-interactive zero-knowledge proof π of the knowledge of the opening r used to generate C from m DV . The designated verifier checks the proof using the Proof and the signature σ and also that obfDat is the hash of C

[0128] Figures 5a and 5b show the two-step method described above

[0129] Figure 5a shows the notarization phase of the data. The data owner (Alice 103a) sends a request to retrieve data from the blockchain 150. The request includes the "get_data" command and the session ID (sid). For example, if the key is shared across multiple data owners, parameters that may include the data owner commitment key CK DO are returned to Alice 103a. If not shared, the data owner does not need to retrieve any data from the blockchain

[0130] Using the retrieved data owner commitment key CK DO , the data m, and the secret value r, Alice 103a generates the data commitment value C

[0131] Alice 103a requests the notary 502 to notarize the data m. To do so, Alice 103a sends the method ID, data owner ID (id), "notarise" command, data commitment value C, and data m to the notary 502. In response to receiving the request, the notary 502 checks the received data and, conditional on the data being valid, generates an obfuscated data value by hashing the data commitment value, and generates a data signature σ, where σ = Sign(sid|id|obfData;SK). The checks performed by the notary 502 may depend on the business logic associated with the data, and the data is found to be valid if it complies with the requirements specified by that logic. The commitment value C is the commitment of the data m that the notary 502 is receiving and checking, and thus the notary 502 only signs the data if it complies. Alice 103a proves knowledge of a secret value r in zero knowledge. The notary 502 executes the verification algorithm described in Section 5.3 to check that Alice 103a indeed has knowledge of the secret value r.

[0132] The notary 502 returns the signed data Data * :=(obfDat, σ) to Alice 103a. Alice 103a generates a blockchain transaction for recording the signed data, including the method ID and data owner ID, to the blockchain 150 and sends that blockchain transaction using the "store_data" command to be recorded on the blockchain 150.

[0133] Figure 5b shows the verification stage of the notarized data. The designated verifier (Bob 103b) sends a request to retrieve the data from the blockchain 150. The request includes the "get_data" command, the method ID, and the data owner ID that identifies Alice 103a. The parameters and the signed data are returned to Bob 103b along with the method ID and data owner ID.

[0134] Bob 103b generates the Bob's commitment key CK DV and sends it to Alice 103a in a data request together with the obfuscated data value and the "request_data" command.

[0135] Based on the received data request, Alice 103a generates a proof π to prove the knowledge of the secret value r and sends it to Bob 103b together with the data m and the data commitment value C. Bob 103b executes the Verify algorithm to verify the proof for m and also checks the data signature σ. If the proof is verified and the signature is valid, Bob 103b can be confident that the data m is appropriate and owned by Alice 103a.

[0136] The notary 502 receives the data m and can thus enforce data compliance before signing. The notary 502 does not know the private value r and thus cannot prove the link between m and C. The data owner 103a can prove such a link in zero knowledge, and thus the notary 502 acts as a designated verifier.

[0137] 8. Data Notarization as a Service Unlike in the previous use case described in Section 7, the data owners trust the notary using their private value r. Instead, the notary generates the nizk proof π DV and interacts with the blockchain on behalf of the data owners. Further, the notary registers the parties as designated verifiers and proves to them the proper notarization of the requested data recorded in the blockchain. These two services may be provided in exchange for a fee.

[0138] In this use case, the notary executes the Verify algorithm described in Section 5 on behalf of the data owners. This is possible because the data owners trust the notary using their secret value r.

[0139] Figure 6 shows the interaction between the parties. The data owner (Alice 103a) sends her data m and the secret value r to the notary 502, and the notary 502 checks and notarizes (signs) the data. The notary 502 then records the signed data on the blockchain 150.

[0140] The designated verifier (Bob 103b) registers with the notary 502 by sending his commitment key CK DO to the notary 502. When registering, Bob 103b proves to the notary 502 that he knows the trapdoor value x corresponding to his commitment key CK DO . Alternatively, Bob 103b may outsource the commitment key generation to a trusted third party to reveal the trapdoor value x to the designated verifier. Registration is explained in more detail below.

[0141] When Bob 103b wishes to verify the data, he retrieves the notarized data from the blockchain 150 and sends it to the notary 502 together with a verification request. The notary 502 also retrieves the notarized data from the blockchain 150 and uses the corresponding secret value r and Bob's commitment key to perform the Proof algorithm described above to generate a proof for Bob 103b. The proof is provided to Bob 103b, and as a result, he can confirm the source of the data by performing the Verify algorithm.

[0142] In this implementation, the data owner interacts with the notary 502 only once to send only their data. Thereafter, they remain completely unconcerned with the notarization process, i.e., uploading the obfuscated data to the blockchain (step 1 of the sovereignty protocol in section 7) and verification (generating a nizk proof for the designated verifier - step 2 of section 7).

[0143] 8.1 Signing of Data The signature placed on the data can be done in two ways.

[0144] Explicit signature: The notary 502 signs the data commitment C and sets the obfuscated data to obfDat = SHA256(C||σ), that is, to the concatenation of the commitment and the signature. It is assumed that the designated verifier has the appropriate verification key PK of the notary 502. The designated verifier receives the signed commitment, checks that the signature is appropriate, and hashes it to obfDat (which he retrieves from the blockchain).

[0145] Implicit signature: The notary 502 embeds the obfuscated data commitment obfDat as the OP_RETURN data of the transaction that consumes the P2PKH UTXO. The designated verifier receives the P2PKH address known to belong to the notary and the commitment C, and checks that the hash is embedded in the transaction that consumes from the Kensei P2PKH address. This has the effect of delegating the signature verification to the miners of the blockchain.

[0146] 8.2 Protection of the Notary against Malicious Verifiers Collaboration of designated verifiers who do not trust each other may interact to pay the notary's fee only once and may reuse the same proof for all of them.

[0147] Attack: A malicious verifier can generate the commitment key CK (a trapdoor) in a way that the secret is shared, where each colluding verifier V DV generates an additive share i of the trapdoor x [Number] and then sets CK i without disclosing x DV :=(G,H := x1·G +... + x n ·G). Since none of the verifiers know the trapdoor x := x1 +... + x n , the same proof π DVIt will be believed by all of them.

[0148] In such an attack, one of the malicious verifiers may obtain the proof π from the notary, and may pass the proof to other malicious verifiers who will similarly be convinced of the validity of the underlying data. Thus, if one of the malicious verifiers can convince the notary that they are not malicious, and as a result the notary provides the malicious verifier with the proof π DV the data to be verified can be shared among all of the malicious verifiers. DV The notary can be protected against this type of collusion of verifiers in two ways.

[0149] 8.2.1 Outsourcing the Generation of the Trapdoor

[0150] An easy solution to avoid malicious collusion of verifiers is to outsource the generation of the trapdoor commitment key (x, CK (x, CK DV ) to a party, called the trapdoor generator herein. This party is trusted not to collude with the notary to share the trapdoor x and not to generate simulated proofs. Upon receiving a generation request from a designated verifier, the generation request issues the signed pair (x, CK DV ) to the designated verifier. Note that it explicitly includes the trapdoor x.

[0151] Any party can register the commitment key CK DV with the notary, and the notary will check that such a key is signed by the trapdoor generator. If that is the case, the notary will be convinced that the knowledge of the trapdoor x of CK DV is known by at least one party - the de facto designated verifier - i.e., the party that requested the generation of the key from the trapdoor generator. This will make the proof π believable only to such a designated verifier (and the trapdoor generator), and not to the other members of the collusion.

[0152] 8.2.2 Proof of Knowledge of Trapdoor in Zero Knowledge The solution described in Section 8.2.1 introduces a new party with a strong degree of credibility, which may not be desirable. Instead, the designated verifier can prove (in zero knowledge) to the notary that he knows the trapdoor x of a given commitment key CK DV to the notary.

[0153] There are difficulties in proving explicit knowledge of the trapdoor x. For example, the standard Schnorr protocol (see Section 4.1.1) for proving knowledge of the logarithm of H with a low G is not sufficient here. Assuming that each of them only knows the additive share x i of x, the cooperation of verifiers as above can cooperate to prove the combined knowledge of x.

[0154] 8.2.2.1 Underlying Idea commitment key CK DV To register the commitment key CK with the notary 502, the designated verifier (Bob 103b) acts as the prover and the notary 502 acts as the verifier. As will be understood later, on the condition that the proof is successfully verified, the verifier is convinced with overwhelming probability that the prover is explicitly using the trapdoor x in the generation of the proof.

[0155] The protocol involves the following modifications, namely, the verifier issues a bit challenge e ∈ {0, 1}, and the prover pre-commits to two possible answers z0 = a and z1 := a + x, for the common input CK DV =(G, H := x · G) to the standard Schnorr protocol. They commit to z i by hashing it. Therefore, it is

Number

[0156] This modified Schnorr protocol gives a soundness error [Number] To amplify the soundness to p = 2 -s the protocol can be repeated s times continuously.

[0157] 8.2.2.2 Reduction of the Number of Repetitions The size of the challenge can be increased up to d bits. Each execution of the protocol with a d-bit challenge gives a soundness error 2 -d If s is a fixed security parameter, to achieve a soundness error 2 -s the protocol is repeated a total of [Number] times.

[0158] According to this, the prover needs to commit 2 d different responses z i = r + e i to x. This can be done efficiently using a Merkle tree of depth d where the i-th leaf is set to z i . The prover sends the root c of the Merkle tree before the verifier issues the challenge e * , and in response the verifier checks the Merkle proof [Number] together with z * = r + e * Answer using x. A Merkle tree commits to n values assigned to leaf nodes, along with one element, namely the Merkle root, and is sometimes referred to in this specification as a succinct commitment.

[0159] 8.2.2.3 Security Analysis - Why does the prover explicitly know the trapdoor? The protocol outlined above has special soundness (see Section 4.1). This means that there exists a polynomial-time extractor algorithm E, i.e., an algorithm that can extract the trapdoor x from two different accepting transcripts (where the first message is fixed). More specifically, from two different challenges e ≠ e' and two answers z, z', E extracts [Number] by calculating

[0160] Next, assume that the prover knows all possible answers. Specifically, they can generate two accepting transcripts and run the extractor E on them to output the trapdoor x. In other words, the prover explicitly knows the trapdoor x if they know all possible answers. If they do not know the answers but [Number] provides a valid Merkle proof for [Number] is at most dε, where ε is the probability of finding a collision in the hash function used in a Merkle tree of depth d. Therefore, a believable prover knows x with probability at least 1 - dε. Finally, assuming the collision hardness of the hash function used in the Merkle tree, [Number] It should be noted that ε can be ignored in terms of size.

[0161] 8.2.2.4 Implementation of the actual protocol The non-interactive version of the protocol (using Fiat-Shamir transformation) outlined above may be implemented in the following manner. [Table 3]

[0162] This zero-knowledge proof system proves knowledge of the trapdoor x. It is parameterized using the bit size d of the challenge and the number of repetitions r. The hash function outputs a bit string of length k.

[0163] To maintain zero-knowledge (of the trapdoor), the prover (the designated verifier, i.e., Bob 103b) executes all rounds sequentially. This affects how the challenge is derived from the transcript. Specifically, [Number] Let be the transcript generated in the i-th round. The (i + 1)-th challenge is [Number] is the hash of. Also, the prover generates the challenge, for example, using rejection sampling, so as not to introduce bias when reducing the remainder of 2 d for arbitrary d.

[0164] In this way, Bob 103b proves explicit knowledge of the trapdoor x, which proves knowledge of all possible answers to all possible challenges and commits to them.

[0165] Figure 7 shows a method for registering with a notary 502 as a designated verifier. In this example, Bob 103b is requesting to register with the notary 502.

[0166] Bob 103b generates his designated verifier commitment key CK DV such that CK DV = (G, H = x·G).

[0167] Bob 103b then executes the proof algorithm described above. First, he sets π0 using context information that includes the designated verifier commitment key CK DV = (G, H). Then, for each 1 ≤ i ≤ r, Bob 103b iteratively calculates π i-1 using π i . Each π i may be referred to as a challenge proof part.

[0168] To calculate each π i , Bob 103b generates a Merkle tree. Bob calculates one response value for each of j = 0 to 2 d - 1. These values are assigned to the leaf nodes at levels 0 to 2 d - 1 of the Merkle tree such that there are 2 d leaf nodes in each Merkle tree related to the response values. d - 1.

[0169] Using the 2 d response values, Bob 103b generates a Merkle root. Bob 103b generates a challenge using the Merkle root, a randomly selected value a i and a commitment A i calculated using the first of the commitment key components G, and the previous challenge proof part π i-1 . The challenge comprises a challenge value e i which is also referred to as a target challenge value.

[0170] The challenge value e iis used to select one of the response values. Specifically, the response value corresponding to j = e i is selected. This selected response value is used as the preimage for the Merkle proof.

[0171] Bob 103b proves that its root

Number

Number

Number

[0172] For 1 ≤ i ≤ r, Bob 103b generates a proof π with each π i as the Merkle proof (authentication path)

Number

[0173] To improve the communication complexity, the commitment A i from the proof part π i is removed. Later, the verifier recomputes these values. It should be understood that the commitment A i may be included in the proof π and may be sent from the prover to the verifier.

[0174] Bob 103b sends the proof π and his commitment key CK DVProvide it to the notary 502. In a manner similar to Bob 103b, the notary 502 sets π0 using the context information.

[0175] For each 1 ≦ i ≦ r, the notary 502 uses the proof π provided by Bob 103b to calculate the candidate challenge value e i * and compares the candidate challenge value with the corresponding target challenge value e i provided in the challenge proof π, which is also called the target challenge value.

[0176] The notary 502 also checks the Merkle proof for each 1 ≦ i ≦ r provided in the challenge proof π.

[0177] If each candidate challenge value is found to match its corresponding target challenge value and each of the Merkle proofs is valid, the proof is verified and the notary 502 registers Bob's commitment key CK DV to register.

[0178] If Bob 103b has registered his commitment key CK DV with the notary 502, Bob 103b can request verification of the data by the notary 502 using the proof and can verify the algorithm described in Section 5.

[0179] 8.2.2.5 Parameter Complexity and Selection Pedersen commitments are initiated via an arbitrary elliptic curve with a degree p of 256 bits and a hash function used to derive the challenge and construct the Merkle tree using SHA - 256. These selections produce a proof of approximately r(512 + 257d) bits in size

Number

[0180] The prover needs to perform r scalar multiplications, and the verifier needs to perform twice as many. Therefore, we seek to minimize the number of iterations r as much as possible. This is to minimize both the computational complexity and the communication complexity. However, this would result in a Merkle tree that is overly large to compute on the prover's side (e.g., 2 s leaves), so r cannot be set too small (e.g., r = 1). For example, there may be 5, 8, or 16 repetitions (i.e., r = 5, 8, 16), but it should be understood that the parameters s, d, r can be configured and chosen based on the computing power of the designated verifier's device.

[0181] The specific values of r and d should be

Number

[0182] 9. Alternative Forms In the example described above, the data m, the data commitment value C, and the obfuscated data value obfData are taken from the blockchain 150. It should be understood that some or all of these values can be transferred off-chain between the data owner, i.e., the notary and the designated verifier in the implementation described in section 8. This is also true for the data to be signed. It should be understood that the use of a blockchain to record and transfer these values brings an additional level of trust when the value is immutably recorded thereon.

[0183] The data commitment value in the above example is C = m·G DO + r·H DOIt is understood that the term data commitment value may be used to refer to any other value that requires the user to commit to the data value m. For example, the data commitment value may be a hash (of data m, of data commitment value C, or of any other suitable value), or it may be a public key.

[0184] 10. DID and VC The World Wide Web Consortium (W3C) provides guidance and standards in Decentralised Identifiers (DIDs), which enable distributed and verifiable digital identification, and Verifiable Credentials (VCs), which enable claims, i.e., statements about an object, to be verified by a legitimate verifier. The W3C data model can be accessed at https: / / www.w3.org / TR / vc-data-model / .

[0185] While DIDs are decentralised, VCs can be issued by trusted entities with cryptographically verifiable credentials. The W3C has also introduced the concept of verifiable presentations (VPs) of VCs, which can enable selective disclosure and other features to maximise the privacy of VC holders.

[0186] A ZKP with a designated verifier can be a VP that cannot be passed on to convince another verifier. As mentioned above, Alice does not want Bob to be able to convince others that she is over 18 years old. To protect her privacy, Alice can generate a ZKP with Bob as the designated verifier.

[0187] For example, assume that the statement "Alice is over 18 years old" is attested in the form of a public key certificate, i.e., in X509 format. This implies that she is over 18 years old if she can generate a digital signature with respect to the proven public key. However, instead of generating a valid digital signature that can be reused to convince others, Alice can generate a zero-knowledge proof (ZKP) of her private key for the designated verifier Bob. As a result, Bob is convinced that she knows the private key without using her digital signature, and Bob cannot convince anyone else.

[0188] This approach can be generalized to any verifiable credential that is cryptographically secured by a secret known to the VC holder.

[0189] Another approach is for the VC issuer to prove a commitment to the claim. The holder can present the claim to the designated verifier, who verifies the ZKP proof against the commitment and the issuer's certificate.

[0190] In the above example, the VC, here the status of being Alice's age or over 18 years old, may be regarded as the data m, where it is understood that Alice is the VC holder. The challenge proof π is a VP generated to prove to Bob, the designated verifier, that Alice has the secret knowledge. For example, this secret as a trapdoor could be her private key, and the corresponding public key to be proven could be the commitment key. In this case, the data m can be attested implicitly or explicitly by the issuer in the public key certificate.

[0191] 11. Further Particulars Given the disclosure in this specification, other variations or use cases of the disclosed techniques may become apparent to those skilled in the art. The scope of this disclosure is limited not by the described embodiments, but only by the appended claims.

[0192] For example, some of the above embodiments have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it will be appreciated that the Bitcoin blockchain is one specific example of the blockchain 150 and that the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any mention above of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may each be replaced with a mention of a blockchain network 106, a blockchain 150, and a blockchain node 104. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0193] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network and the Bitcoin node 104 performs at least all of the described functions of creating, issuing, propagating, and recording the block 151 of 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 function of propagating and / or recording a block without creating and issuing the block (recall that these entities are not considered nodes of a suitable Bitcoin network 106).

[0194] In other embodiments of the present invention, the blockchain network 106 may not be a 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, issuing, propagating, and recording the blocks 151 of the blockchain 150. For example, in those other blockchain networks, the term "node" may be used to refer to a network entity that is configured to create and issue the blocks 151 but not record and / or propagate those blocks 151 to other nodes.

[0195] Even more generally, any reference to the term "Bitcoin node" 104 above may be replaced with the term "network entity" or "network element", such entity / element being configured to perform some or all of the role of creating, issuing, propagating, and recording blocks. The functions of such network entity / element may be implemented in hardware in a similar manner as described above with reference to the blockchain node 104.

[0196] Regarding the implementation of a proof-of-work consensus mechanism by a blockchain network to secure a underlying blockchain, several embodiments are described. However, proof-of-work is only one type of consensus mechanism, and in general, embodiments may use any suitable type of consensus mechanism, such as, for example, 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 node 104 is given the opportunity to generate the next block 151. The selected node is often referred to as a validator. Blockchain nodes can lock up their tokens for some period of time in order to have a chance of becoming a validator. In general, the node that locks up the most funds for the longest period of time has the best chance of becoming the next validator.

[0197] It will be appreciated that the above embodiments are merely illustrative. More generally, a method, apparatus, or program may be provided by any one or more of the following claims.

[0198] Claim 1. A computer-implemented method for proving ownership and / or possession of data m, the method comprising generating a data commitment value based on a secret value r and the data m, generating a challenge solution π related to a designated verifier, the challenge solution π being a zero-knowledge proof proving knowledge of the secret value r, and making the data m, the challenge solution π, and the data commitment value available to the designated verifier, wherein the secret value r is not known or made available to the designated verifier.

[0199] Claim 2. The method of Claim 1, wherein the step of generating the challenge solution π related to the designated verifier comprises generating a verifier commitment value related to the designated verifier, and the challenge solution π comprises the verifier commitment value.

[0200] Claim 3. The method of any of the preceding claims, wherein the method further comprises receiving, from the designated verifier, a verifier commitment key related to the designated verifier, and the zero-knowledge proof related to the designated verifier is generated based on the verifier commitment key.

[0201] Claim 4. The method of any of the preceding claims, wherein the method further comprises generating a hash of the data commitment value and making the hash of the data commitment value available to the designated verifier.

[0202] Claim 5. The method of Claim 4, wherein the method further comprises generating a proof blockchain transaction that makes the hash of the data commitment value available when recorded on the blockchain and making the proof blockchain transaction available to one or more nodes of the blockchain.

[0203] Claim 6. The method of any of the preceding claims, wherein the data commitment value is derived based on a data owner commitment key.

[0204] Claim 7. The method of any of the preceding claims, wherein the method further comprises providing the data commitment value and the data m to a notary and receiving a signed version of the data from the notary.

[0205] Claim 8. The method of Claim 7, wherein the signed version of the data is generated by signing the data commitment value.

[0206] Claim 9. The method of Claim 7, wherein the signed version of the data is generated by signing the hash of the data commitment value, and the hash of the data commitment value is received from the certifier.

[0207] Claim 10. The method of Claim 7, further comprising generating a certified blockchain transaction that makes the signed version of the data received from the certifier available when recorded on the blockchain.

[0208] Claim 11. The method of Claim 9, further comprising generating a certified blockchain transaction that makes the hash of the data commitment value received from the certifier available when recorded on the blockchain.

[0209] Claim 12. The method of any one of Claims 1 to 7, wherein the method is performed by a certifier and further comprises receiving data m from the data owner of the data m and generating a signature associated with the data m.

[0210] Claim 13. The method of Claim 12, when dependent on Claim 4, the method comprising receiving a trapdoor proof from a designated verifier, the trapdoor proof being a non-interactive zero-knowledge proof proving knowledge of a trapdoor value, the verifier commitment key comprising a first elliptic curve point and a second elliptic curve point, the trapdoor value defining a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key, and further comprising verifying the trapdoor proof based on the verifier commitment key, and when the trapdoor proof is verified, the certifier makes the verifier commitment value and that version of the data commitment value available to the designated verifier.

[0211] Claim 14. The method of claim 12, when dependent on claim 3, the method comprising receiving a signed version of the verifier commitment key and verifying that the signed version of the verifier commitment key is signed by a trusted trapdoor generator, the trusted trapdoor generator generating a signed pair comprising a signed version of the verifier commitment key and a signed trapdoor value, each signed by the trusted trapdoor generator, the verifier commitment key comprising a first elliptic curve point and a second elliptic curve point, the trapdoor value defining a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key, and when the signed version is verified, the notary makes the verifier commitment value and that version of the data commitment value available to the designated verifier.

[0212] Claim 15. A computer-implemented method for verifying data m by a designated verifier, the method comprising obtaining a data commitment value generated based on data m, the data m and a secret value r, the secret value r not known to the designated verifier, and a challenge solution π related to the designated verifier, the challenge solution π being a zero-knowledge proof proving knowledge of the secret value r, checking that the challenge solution π is related to the designated verifier, and verifying the data commitment value based on the data m based on the challenge solution π.

[0213] Claim 16. The method of claim 15, wherein the challenge solution π related to the designated verifier comprises a target verifier commitment value related to the designated verifier, and the step of checking that the challenge solution π is related to the designated verifier comprises generating a candidate verifier commitment value and comparing the candidate verifier commitment value with the target verifier commitment value, and when the candidate verifier commitment value and the target verifier commitment value are equal, the challenge solution π is related to the designated verifier.

[0214] Claim 17. The method according to Claim 16, further comprising generating a verifier commitment key associated with a designated verifier and sending the verifier commitment key to a generator of a verifier commitment value, wherein the target verifier commitment value is generated based on the verifier commitment key.

[0215] Claim 18. The method according to Claim 17, wherein the verifier commitment key is sent together with a request for obtaining a data commitment value.

[0216] Claim 19. The method according to any one of Claims 15 to 18, further comprising obtaining a target hash of the data commitment value, generating a candidate hash of the data commitment value, and comparing the candidate hash with the target hash of the data commitment value, wherein when the candidate hash matches the target hash, the data m is verified.

[0217] Claim 20. The method according to any one of Claims 15 to 18, wherein the target hash of the data commitment value is obtained from a proof blockchain transaction recorded on a blockchain.

[0218] Claim 21. The method according to any one of Claims 15 to 20, further comprising obtaining a signed version of the data m and verifying the signed version of the data m.

[0219] Claim 22. The method according to Claim 21, wherein the signed version of the data m is obtained from a blockchain transaction recorded on a blockchain.

[0220] Claim 23. The method according to Claim 20, when dependent on Claim 17 or Claim 18, wherein the target hash of the data commitment value is sent to a generator of the verifier commitment value together with the verifier commitment key.

[0221] Claim 24. A method according to claim 17 or any claim dependent thereon, the method comprising generating a trapdoor proof, the trapdoor proof being a non-interactive zero-knowledge proof proving knowledge of a trapdoor value, the verifier commitment key comprising a first elliptic curve point and a second elliptic curve point, the trapdoor value defining a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key, and transmitting the trapdoor proof to a notary, the notary being the generator of the verifier commitment value, and receiving a target verifier commitment value from the notary.

[0222] Claim 25. A computer device comprising a memory having one or more memory units and a processing device having one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured to cause the processing device to execute a method according to any one of claims 1 to 24 when executed on the processing device.

[0223] Claim 26. A computer program embodied on a computer-readable storage and configured to execute a method according to any one of claims 1 to 24 when executed on one or more processors.

Description of the Reference Numerals

[0224] 100 System 101 Packet Switching Network 102 Computer Terminal, Computer Device 103 User, Entity, Party, Agent 103a Alice 103b Bob 103c Charlie 104 Blockchain Node, Bitcoin Node 105 Client Application, Software 106 Peer-to-Peer (P2P) Network, Blockchain Network 107 Side Channel 150 Blockchain 151 Block 152 Transaction 153 Genesis Block 154 Ordered Set, Ordered Pool 155 Block Pointer 201 Header 202 Input, Input Field 203 Output, Output Field, UTXO 502 Notary

Claims

Claim 1 A computer-implemented method for proving ownership and / or possession of data m, comprising: generating a data commitment value based on a secret value r and the data m; generating a challenge solution π related to a designated verifier, wherein the challenge solution π is a zero-knowledge proof proving knowledge of the secret value r; making the data m, the challenge solution π, and the data commitment value available to the designated verifier; and the secret value r is not known by the designated verifier or not made available to the designated verifier. Claim 2 The method according to claim 1, wherein the step of generating the challenge solution π related to the designated verifier comprises generating a verifier commitment value related to the designated verifier, and the challenge solution π comprises the verifier commitment value. Claim 3 The method according to claim 1 or 2, further comprising receiving a verifier commitment key related to the designated verifier from the designated verifier, wherein the zero-knowledge proof related to the designated verifier is generated based on the verifier commitment key. Claim 4 The method according to any one of claims 1 to 3, further comprising generating a hash of the data commitment value and making the hash of the data commitment value available to the designated verifier. Claim 5 generating a proof blockchain transaction that makes the hash of the data commitment value available when recorded on a blockchain; and making the proof blockchain transaction available to one or more nodes of the blockchain. The method according to claim 4, further comprising: Claim 6 The method according to any one of claims 1 to 5, wherein the data commitment value is derived based on a data owner commitment key. Claim 7 providing the data commitment value and the data m to a notary; and receiving a signed version of the data from the notary. The method according to any one of claims 1 to 6, further comprising: Claim 8 The method according to claim 7, wherein the signed version of the data is generated by signing the data commitment value.

9. The method according to claim 7, wherein the signed version of the data is generated by signing a hash of the data commitment value, and the hash of the data commitment value is received from the certifier.

10. The method according to claim 7, further comprising the step of generating a certified blockchain transaction that makes the signed version of the data received from the certifier available when recorded on the blockchain.

11. The method according to claim 9, further comprising the step of generating a certified blockchain transaction that makes the hash of the data commitment value received from the certifier available when recorded on the blockchain.

12. Performed by a certifier, receiving the data m from an owner of the data m, generating a signature associated with the data m The method according to any one of claims 1 to 7, further comprising.

13. When dependent on claim 4, receiving a trapdoor proof from the designated verifier, the trapdoor proof being a non-interactive zero-knowledge proof proving knowledge of a trapdoor value, the verifier commitment key comprising a first elliptic curve point and a second elliptic curve point, the trapdoor value defining a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key, further comprising verifying the trapdoor proof based on the verifier commitment key, wherein when the trapdoor proof is verified, the certifier makes the verifier commitment value and the version of the data commitment value available to the designated verifier. The method according to claim 12.

14. When dependent on claim 3, receiving a signed version of the verifier commitment key, Verifying that the signed version of the verifier commitment key is signed by a trusted trapdoor generator, wherein the trusted trapdoor generator generates a signed pair comprising the signed version of the verifier commitment key, each signed by the trusted trapdoor generator, and a signed trapdoor value, the verifier commitment key comprising a first elliptic curve point and a second elliptic curve point, and the trapdoor value defining a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key, and further comprising: If the signed version is verified, the notary makes the verifier commitment value and the version of the data commitment value available to the designated verifier. The method according to claim 12.

15. A computer-implemented method for verifying data m by a designated verifier, comprising: the data m, a data commitment value generated based on the data m and a secret value r, the secret value r being unknown to the designated verifier, and a challenge solution π related to the designated verifier, which is a zero-knowledge proof proving knowledge of the secret value r obtaining; checking that the challenge solution π is related to the designated verifier; verifying the data commitment value based on the data m based on the challenge solution π A method comprising.

16. The method according to claim 15, wherein the challenge solution π related to the designated verifier comprises a target verifier commitment value related to the designated verifier, and the step of checking that the challenge solution π is related to the designated verifier comprises generating a candidate verifier commitment value and comparing the candidate verifier commitment value with the target verifier commitment value, and if the candidate verifier commitment value and the target verifier commitment value are equal, the challenge solution π is related to the designated verifier.

17. generating a verifier commitment key related to the designated verifier; Further comprising the step of sending the verifier commitment key to the generator of the verifier commitment value, wherein the target verifier commitment value is generated based on the verifier commitment key. The method according to claim 16.

18. The method according to claim 17, wherein the verifier commitment key is sent together with a request for obtaining the data commitment value.

19. The step of obtaining a target hash of the data commitment value, The step of generating a candidate hash of the data commitment value, and the step of comparing the candidate hash with the target hash of the data commitment value. When the candidate hash matches the target hash, the data m is verified. The method according to any one of claims 15 to 18.

20. The method according to any one of claims 15 to 18, wherein the target hash of the data commitment value is obtained from a proof blockchain transaction recorded on a blockchain.

21. The method according to any one of claims 15 to 20, further comprising the step of obtaining a signed version of the data m and the step of verifying the signed version of the data m.

22. The method according to claim 21, wherein the signed version of the data m is obtained from a blockchain transaction recorded on a blockchain.

23. When dependent on claim 17 or 18, the method according to claim 20, wherein the target hash of the data commitment value is sent to the generator of the verifier commitment value together with the verifier commitment key.

24. The step of generating a trapdoor proof, wherein the trapdoor proof is a non-interactive zero-knowledge proof proving knowledge of a trapdoor value, the verifier commitment key comprises a first elliptic curve point and a second elliptic curve point, and the trapdoor value defines a relationship between the first elliptic curve point and the second elliptic curve point of the verifier commitment key. The step of sending the trapdoor proof to a notary, wherein the notary is the generator of the verifier commitment value. a step of receiving the target verifier commitment value from the notary public The method according to any one of claims 17 or dependent claims thereof, further comprising the step. **Claim 25** A computer device, a memory including one or more memory units, a processing device including one or more processing units, the memory storing code configured to be executed on the processing device, and the code being configured to cause the processing device to execute the method according to any one of claims 1 to 24 when executed on the processing device. **Claim 26** A computer program embodied on a computer-readable storage and configured to execute the method according to any one of claims 1 to 24 when executed on one or more processors.

Images