Proof of ownership

Abstract

A computer-implemented method for proving sole ownership of a commitment key. The commitment key comprises two elements, and a secret trapdoor value x defines the relationship between the elements of the commitment key. The challenge proof part π i is iteratively calculated over a predefined number of iterations d, and the challenge proof part is generated based on a succinct commitment derived using the secret trapdoor value x. The challenge proof π is generated based on the challenge proof part π i . The challenge proof π is made available to the verifier. The challenge proof π is a non-interactive zero-knowledge proof that proves knowledge of the secret trapdoor value x.

Description

Technical Field

[0001] The present disclosure relates to a computer-implemented method for proving sole ownership and / or possession of a commitment key, and a computer-implemented method for verifying sole ownership and / or possession of a commitment key.

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 a "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 across one or more blocks, going back 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 competing among each of a plurality of nodes to perform the solving of a cryptographic puzzle based on a defined set of ordered and validated pending transactions that are 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 publication of a block may be realized through the publication of just the block header.

[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 accumulation of additional user data, or an index to data, within a transaction. There is no predefined limit to the maximum data capacity that can be accumulated within a single transaction, and thus, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0004] (Often referred to as "miners"), the nodes of a blockchain network execute a distributed transaction registration and verification process that will be described in more detail later. In summary, during this process, the nodes attempt to insert the transaction into a block template where the node tries to validate the transaction and identify a valid proof-of-work solution. When a valid solution is found, a new block is propagated to the other nodes in the network, thus enabling each node to record the new block on the blockchain. To record a transaction in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be propagated. The 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 the transaction is validated and thus accepted onto 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 typically 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 carried out by the actions of competing nodes that act as agents of the network and are incentivized to report and block misbehavior. The wide 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 consists of one or more inputs and one or more outputs. Any spendable output comprises an element that specifies an amount of digital assets derivable from the evolving 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 that 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 previous transaction, and may further comprise an unlocking script for unlocking the locking script of the indicated output. Thus, consider a pair of transactions, referred to as 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 in 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 in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another valid transaction earlier. 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 for registering 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 defines the amount to be transferred by reference to an absolute account balance, rather than by reference to the UTXOs of previous transactions in a series of past transactions. The current state of all accounts is accumulated and constantly updated by a node separate from the blockchain. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0009] In the present disclosure, a data owner, or a party authorized by the data owner (e.g., a notary) has control such that a third party can be convinced through it that the data owned by the data owner is appropriate. That is, the data owner can control who can verify the data.

[0010] In the method disclosed herein, the verifier provides their commitment key to the data owner or notary, and the commitment key is used to derive a commitment to the verifier. This "designated verifier commitment" can only be verified by the verifier who provides the commitment key.

[0011] However, due to the nature of the commitment key used, it may happen that multiple verifiers have partial knowledge of the commitment key such that each of the multiple verifiers can verify the data based on the verifier commitment value derived from the commitment key.

[0012] Therefore, it is desirable for the verifier to prove to the party calculating the verifier commitment value that they are the sole owner and / or possessor of the commitment key, i.e., the verifier who provides the commitment key is the only party who can verify the data based on the provided key. In this way, the data owner or notary can be confident that only the verifier can verify the data.

Means for Solving the Problem

[0013] According to one aspect disclosed herein, a computer-implemented method is provided for proving sole ownership and / or possession of a commitment key, the commitment key comprising two elements, a secret trapdoor value x defining a relationship between the elements of the commitment key, the method comprising iteratively calculating a challenge proof portion π i over a predetermined number of iterations d, the challenge proof portion being generated based on a succinct commitment derived using the secret trapdoor value x, and generating a challenge proof π based on the challenge proof portion π i and making the challenge proof π available to the verifier, the challenge proof π being a non-interactive zero-knowledge proof proving knowledge of the secret trapdoor value x.

[0014] Aspects disclosed herein may be used, for example, in the following scenario. Alice (data owner) enters a nightclub, and Bob, i.e., the security guard at the door, asks Alice to prove that she is older than 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 a minor. Since Alice does not want Bob to have her personal data (certified proof), Alice refuses. Instead, it is possible for the police to come to Alice's place, and Alice will talk if she can easily prove to the police that she is over 18 years old. Thus, Alice wants to control who can be convinced of the fact that she is old enough.

[0015] Using the methods described herein, Alice can prove to Bob (the designated verifier) that her data is encrypted (committed and hashed) without giving Bob enough information to prove this to Charlie (a third party). 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 methods disclosed herein involve non-interactive zero-knowledge (nizk) proofs of knowledge for a designated verifier to prove knowledge of the data owner's private value r. The proof π Bob is specifically tailored for Bob (the designated verifier), and he cannot use π Bob to convince anyone else.

[0016] Furthermore, in contrast to general-purpose proof systems, the systems disclosed here do not require any trusted setup and are fast and easy to implement.

[0017] This embodiment will be mainly described with respect to the owner of the commitment key proving ownership, but it should be noted that this embodiment can be equally used to prove the possession of the commitment key. In some examples, the commitment key does not necessarily belong to the data owner, and the data owner only possesses the key. That is, the possession of data does not necessarily mean the ownership of data, and vice versa. In these examples, the data owner may alternatively be referred to as the data possessor. It should be understood that the term "data owner" is only used as a label for identification. In some examples, the data owner may perform both key ownership and possession.

[0018] To assist in the understanding of the embodiments of the present disclosure and to show how such embodiments can be implemented, the accompanying drawings are referred to merely as examples.

Brief Description of the Drawings

[0019]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5a

Figure 5b

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0020] 1. Exemplary System Overview FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switching network 101, i.e., a wide-area Internet network such as the Internet typically. The packet-switching network 101 includes a plurality of blockchain nodes 104 that can be configured to form a peer-to-peer (P2P) network 106 within the packet-switching 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.

[0021] Each blockchain node 104 includes a peer computer device, and different nodes 104 among the nodes 104 belong to different peers. Each blockchain node 104 includes 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 includes a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units 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.

[0022] 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 storing the entire blockchain 150. Instead, the blockchain 150 may be a pruned one of data as long as each blockchain node 150 stores 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 approach. A given blockchain uses one specific transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output designates an amount representing the quantity of digital assets as a characteristic, and an example of a characteristic is the user 103 to whom the output is cryptographically locked (requiring the signature or other solution of that user to be unlocked and thereby redeemed or consumed). Each input points backward to the output of a preceding transaction 152, thereby linking the transactions.

[0023] 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 series of transactions (note that the series of transactions 152 is allowed to branch). The chain of blocks 151 extends far backward to the genesis block (Gb) 153 which 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.

[0024] Each of the blockchain nodes 104 is configured to transfer 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 store respective copies of the same blockchain 150 in their respective memories. 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 in this specification 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 attempting to consume the same output.

[0025] In a given current transaction 152j, each input comprises a pointer that references an output of a preceding transaction 152i in a series of transactions that designates that this output is to be redeemed or "consumed" within the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming 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 need to exist at the time the current transaction 152j is created and further sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i needs to exist and be validated. Thus, "preceding" as used herein does not necessarily refer to the time of creation or transmission in a temporal series, but rather to the predecessor in a logical series linked by pointers, 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 prior transaction.

[0026] The input of the current transaction 152j also comprises an input authorization, for example, the signature of user 103a to which 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 which may be the original user or entity 103a for providing change). In some cases, a transaction can also have multiple inputs to collect the amount together from multiple outputs of one or more preceding transactions and redistribute it to one or more outputs of the current transaction.

[0027] 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 through 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 usually a server or data center, but in principle could be another user terminal). It is not excluded that in some cases, 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 that the blockchain node 104 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 usually at least includes 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 further nodes 104, etc. In this way, the new transaction is propagated across the entire network of blockchain nodes 104.

[0028] In an output-based model, the determination of whether a given output (e.g., a UTXO) is assigned (or "spent") is whether it has yet been validly redeemed by an input of another transaction 152j further ahead according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of a 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 assign the output of the same transaction more than once. On the other hand, an account-based model protects against double-spending by maintaining account balances. Again, since there is a defined order of transactions, the account balance always has a defined single state.

[0029] In addition to validating transactions, blockchain node 104 also competes to be the first to create a block of transactions in a process typically 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 predetermined condition. For example, the predetermined condition could be that the output of the hash has a certain number of leading zeros. Note 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.

[0030] 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 condition for the output of the hash when the solution to the hash is provided). 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 will then be 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 a 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.

[0031] 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. Whoever first solves each of their respective puzzles 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 "forks" that may occur, which is the case when two blockchain nodes 104 solve their puzzles in very close succession to each other such that conflicting views of the blockchain are propagated among the nodes 104. In short, whichever prong of the 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.

[0032] 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 in a new special type of transaction that distributes a specified additional amount of digital assets (not between agent or user transactions that transfer a certain amount of digital assets 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 a "genesis transaction" or "generation transaction". It usually forms the first transaction of a new block 151n. Proof of work signals the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. 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.

[0033] 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 further, 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.

[0034] 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 as described 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.

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

[0036] Some 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 blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of the system that includes 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 blockchain network 106 and thereby utilize blockchain 150 by connecting to (i.e., communicating with) blockchain node 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 is understood that many more such parties 103 and their respective computer devices 102 may exist and participate in 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 a first party 103a is referred to as Alice and a second party 103b is referred to as Bob, but it is understood that this is not limiting and any reference in this specification to Alice or Bob may be replaced, respectively, with "first party" and "second party".

[0037] The computer device 102 of each party 103 comprises a respective processing device having 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 comprises 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 employing one or more memory media, such as magnetic media like hard disks, SSDs, flash memories, or electronic media like EEPROMs, and / or optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software comprising respective instances of at least one client application 105 configured to execute on the processing device. It will be understood that any action taken by a given party 103 can be executed using software executed on the processing device of the respective computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources, accessed via the user terminal.

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

[0039] The client application 105 has 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 party 103 and sent to one or more Bitcoin nodes 104, and then propagated across the network of the blockchain nodes 104, thereby being included in the blockchain 150. The other is to report back to each party the amount of digital assets that the person currently owns. In an output-based system, this second functionality involves reconciling the amounts defined in the outputs of various transactions 152 scattered across the entire blockchain 150 that belong to the relevant party.

[0040] Note: Although various client functionalities may be described as integrated within a given client application 105, this is not necessarily limiting, and instead, any client functionality 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 at the application layer, or a lower layer such as an operating system, or any combination thereof. The following is described with respect to the client application 105, but it should be understood that this is not limiting.

[0041] An instance of a client application or software 105 on each computer device 102 is 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 a 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 a transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and transfer the transactions 152 to propagate them 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.

[0042] When a given party 103, e.g., Alice, wishes to send a new transaction 152j to be included in 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 some of the conditions for it to be "valid", examples of which are briefly described in more detail. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol or may be defined by a combination of the script and the node protocol.

[0043] In the case where the newly received transaction 152j passes the tests for being considered valid (i.e., in the condition that 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, assuming then that the transaction 152j is valid, this means that the transaction 152j will soon be propagated across the entire network 106 as a whole.

[0044] Once approved in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle in the latest version of each of those pools in 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 defines the set of transactions to be included in the latest block 151. Ultimately, 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 the previous transaction, so the order of the transactions is also invariably recorded.

[0045] Different blockchain nodes 104 may first receive different instances of a given transaction, and thus, before one instance is issued in a new block 151, there may be competing appearances as to which instance is "valid", and 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 first accepted (i.e., the instance not issued in block 151).

[0046] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol as part of an account-based transaction model. In an 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 accumulated and constantly updated by nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the transaction's in-progress transaction ledger (also called a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field 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.

[0047] 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 a 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.

[0048] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may comprise 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 contains a value that specifies the amount of digital assets. 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 comprise a header 201, which may comprise 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 a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0049] 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 an unspent output 203 locked to Alice.

[0050] The preceding transaction Tx0 may already be validated and included in block 151 of blockchain 150 by the time Alice creates her new transaction Tx1 or at least by the time she sends it to network 106. It may already be included in one of the blocks 151 at that time or 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 network 106 together, or Tx0 may even be sent after Tx1 if the node protocol allows buffering of "orphan" transactions. 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 can be equivalently replaced by "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 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 as long as the parent transaction is not 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 time while waiting for the parent.

[0051] One of one or more outputs 203 of a preceding transaction Tx0 comprises a particular UTXO, herein labeled UTXO0. Each UTXO comprises a value specifying the amount of digital assets represented by the UTXO, and a locking script that specifies a condition that must be satisfied by an unlocking script in an input 202 of a subsequent transaction in order for the subsequent transaction to be valid, 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 comprises the condition that an unlocking script in an input of a subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked.

[0052] The locking script (also called scriptPubKey) 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 signature requirements of Alice. The unlocking script appears in the output of the transaction. The unlocking script (also called scriptSig) 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.

[0053] Thus, in the illustrated example, 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 pointing 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 identifying 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 "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.

[0054] 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 are such that the public key P of Alice, as contained within the locking script in the output of Tx0 A is used to authenticate that the unlocking script in the input of Tx1 contains the signature of Alice that signs the expected portion of the data. The expected portion of the data itself ("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 designating the signed portion of the data needs to be included in plaintext).

[0055] 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 plaintext, another entity such as node 104 can authenticate that the message must have been signed by Alice. Signing typically comprises 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.

[0056] If one or more conditions specified in the locking script of Tx0 are satisfied by the unlocking script in Tx1 (so that, in the illustrated example, when 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 throughout 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 for the blockchain 150 to impose 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.

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

[0058] 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 change to herself in the second output of Tx1 or make a payment to another party.

[0059] In practice, Alice also typically needs to include a fee for the 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 the blockchain node 104, and thus, although technically valid, may not be propagated and may not be included in the blockchain 150 (the node protocol does not force the 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 the input 202 and the total amount specified among 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 UTXOs 203 of transaction 152.

[0060] The digital assets of Alice and Bob consist of UTXOs locked to them in some transaction 152 somewhere in the blockchain 150. Thus, typically, the assets of a given party 103 are spread across all the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number accumulated anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the 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. The wallet function can do this by querying a copy of the blockchain 150 stored at any of the Bitcoin nodes 104.

[0061] 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 beginning of a locking script, can accumulate data within a transaction, thereby immutably recording the data in the blockchain 150, creating a non-consumable output of the transaction. For example, the data may be a document that is desired to be accumulated in the blockchain.

[0062] Typically, 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 a part of the transaction input and a 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 outputs are signed (and thus fixed at the time of signing).

[0063] 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 essential 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.

[0064] 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 data exchange separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this may be used to exchange a transaction 152 between Alice and Bob without the transaction (yet) being 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 is sometimes 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 amounts or conditions, data content, etc.

[0065] Side channel 107 may be established via the same packet-switching 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 any 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 overall 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 piece or pieces 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 and even the same type of network.

[0066] 4. Zero-Knowledge Proof

[0067]

Number

[0068] Let be a finite group of prime order p,

[0069]

Number

[0070] and let be a field of exponents.

[0071]

Number

[0072] The elements in are in lowercase Roman letters

[0073]

Number

[0074] and also using

[0075]

Number

[0076] The elements in are in uppercase Roman letters

[0077]

Number

[0078] shown using

[0079]

Number

[0080] The vector of the n elements in is shown as the boldface x. Similarly,

[0081]

Number

[0082] The vector of the m elements in is shown as G

[0083] The symbol “+” in this specification

[0084]

Number

[0085] The group operation (in additive notation) and the field

[0086]

Number

[0087] are both used for the addition operation (addition modulo p) in. The scalar multiplication is denoted as x·G. For actual instantiation,

[0088]

Number

[0089] is set to be an elliptic curve.

[0090] 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 in polynomial time in the length of st, and w of that length is also a polynomial in the length of st.

[0091] 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 more than one witness for a given statement. The induced NP language L R is the set of statements. L R ={st: ∃w such that (st,w) ∈ R}

[0092] The Sigma protocol is a 3-round protocol between the prover and the 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 in this specification, to the verifier, and the verifier verifies the challenge solution π based on the protocol.

[0093] 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).

[0094] The Sigma protocol has the following properties.

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

[0096] 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.

[0097] Special honest verifier zero-knowledge (SHVZK). For input st ∈ L RAnd there exists a polynomial-time algorithm Sim for random e that outputs an accepting transcript π=(A, e, z) that is indistinguishable from the transcript of the protocol.

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

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

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

[0101]

Number

[0102] the Schnorr protocol proves knowledge of the discrete logarithm

[0103]

Number

[0104] as follows. 1. The prover

[0105]

Number

[0106] randomly samples and calculates A := a·G. The prover sends A to the verifier. 2. The verifier challenges

[0107]

Mathematics

[0108] Randomly sample it and send it to the prover. 3. The prover calculates z := a + e x mod p and sends it to the verifier. 4. The verifier accepts only if z · G = A + e · H.

[0109] It is easy to understand that the Schnorr protocol is complete and SHVZK. To understand why it has special soundness, notice 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. Subtract the second equation from the first (note that the same A is used in both), and we get (z - z') · G = (e - e') · H. Therefore,

[0110]

Mathematics

[0111] we conclude that. Since e ≠ e', e - e' has

[0112]

Mathematics

[0113] the multiplicative inverse of in it, and it can be efficiently calculated. Therefore, note that the discrete logarithm can be calculated using two challenges and two responses.

[0114] 4.1.2 Removal of Interaction - Fiat-Shamir Heuristic The Sigma protocol is an example of an interactive coin - based 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 (a single 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.

[0115] 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 the challenge C can be constructed using a well - known hash function such as SHA256. Next, the prover can simply

[0116]

Number

[0117] be set to calculate e without the help of the verifier.

[0118]

Number

[0119] Note that is the (public) transcript that occurs immediately after the challenge e is generated by the verifier 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.

[0120] The assumptions for the RO function guarantee two things. First, the challenge e is randomly distributed, and thus the interactive protocol only needs to satisfy zero-knowledge for honest verifiers (i.e., SHVZK). Second, the prover cannot compute the challenge before computing the commitment

[0121] [Number]

[0122] (and the statement st about that matter), so the order of execution of the protocol cannot be reversed.

[0123] Different commitments

[0124] [Number]

[0125] to try will not hit the (unique) challenge that enables simulation, provided that the challenge space C is large enough. Moderate / conservative choices are, respectively, using challenges of size 80 or 128 bits, although it should be understood that other challenge bit sizes may be used.

[0126] 4.2 Pedersen Commitment A vector Pedersen commitment or batch Pedersen commitment is a single group element

[0127] [Number]

[0128] to use a vector

[0129] [Number]

[0130] It is a generalization of the Pedersen scheme for committing. Batch Pedersen can be instantiated over any group where the discrete logarithm assumption is hard.

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

[0132]

Number

[0133] is assumed to be an implicit input to both algorithms. · Commit Com(m,r,CK): Input message vector

[0134]

Number

[0135] , random element

[0136]

Number

[0137] , and commitment key

[0138]

Number

[0139] in which the output point: C = m1·G1 +... + m n ·G n + r·H · Commit verification VerifyCom(m,r,C,CK): Input opening

[0140]

Number

[0141] , and commitment

[0142]

Number

[0143] , and commitment key

[0144]

Number

[0145] In, C * = Com(x, CK; r) is calculated. If C * = C,

[0146]

Number

[0147] (Acceptance) is output. Otherwise, b = ⊥ (rejection) is output.

[0148] 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 by which n different messages can be committed by a single elliptic curve.

[0149] 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.

[0150] 4.2.2 Trapdoor Commitment Key Exponents x1,..., x nPick up and set H := x1·G1 +... + x n ·G n so that the group element H is generated. Along with the knowledge of x := (x1,..., x n ), note that the Pedersen commitment is no longer binding. For example, in the case of n = 1, consider H = x·G and C = m·G + r·H. Set r' := r + x -1 (m - m') mod p, and it is possible to open the commitment C to an arbitrary value m' ≠ m. The value x may sometimes be called a trapdoor or trapdoor value in this specification.

[0151] 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 to only 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.

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

[0153] The proof π V is specially 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 in for himself. However, since the exact same proof might sometimes be generated by Bob 103b (proving that he knows x), Bob can use π R to show that st ∈ L VOr it is not possible to convince Charlie 103c using x.

[0154] 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 can be used. The prover (Alice 103a) commits to a random value w in the commitment C and, together with the statement, and the first message A of the Sigma protocol, uses C 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)

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

[0156] 5. Proof System This section specifies a proof method 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.

[0157] 5.1 Statement The data owner has a Pedersen commitment key CK DO := (G DO , H DOUse [[]] to commit to that person's data m in a concealed manner. The public statement (known at least to the data owner and the designated verifier) is the following tuple.

[0158]

Number

[0159] The data is

[0160]

Number

[0161] encoded as an element. The data owner generates a non-interactive zero-knowledge proof of knowledge to prove knowledge of an element in the following set.

[0162]

Number

[0163] 5.2 Generation and Accumulation of Commitment Keys The commitment key CK DO can be shared across multiple data owners, but

[0164]

Number

[0165] is generated in a verifiable way that ensures that no one knows it (see Section 4.1). To make this key publicly available, this key may be accumulated as OP_RETURN data in the blockchain.

[0166] 5.3 Prover and Designated Verifier Algorithms For a given statement st as defined above, the data owner generates a nizk argument π 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 the knowledge of DV of.

[0167]

Number

[0168] .

[0169] The designated verifier selects a random secret trapdoor

[0170]

Number

[0171] and sets up a new commitment key as CK DV := (G DV , H DV := xG DV ). In this section, it is assumed that the data owner knows CK DV when generating π DV .

[0172] The algorithms given below use the cryptographic hash function Hash

[0173]

Number

[0174] to generate non-interactive challenges.

[0175]

Table 1

[0176] 5.4 Proof Forgery 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 be satisfied that the data owner, rather than the designated verifier, was the source of the data.

[0177] Let the tuple st := (m, C, CK DO , obf) be such that 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). The designated verifier can open the commitment under their key CK DV to any value they like, and thus (

[0178]

Number

[0179] intentionally prove knowledge of) the challenge of the Schnorr proof can be chosen in advance, making this possible. The algorithm for forging the proof is detailed below.

[0180]

Table 2

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

[0182] 6. Private Timestamp The first application example of the proof system described in Section 5 is to timestamp data in a non - public 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.

[0183] 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 the timestamp of m to the designated verifier, and the obfuscation and non - transferability of the proof guarantee privacy to everyone except the designated verifier.

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

[0185] It should be understood that accumulating obfuscations on the blockchain results in the data being implicitly logged. That is, the data m does not need to be accumulated on the blockchain.

[0186] 6.1 Proof of Appropriate Timestamping When obfData appears in the blockchain, anyone who wishes to verify the link to the data can act as the designated verifier. They can be convinced that m indeed matches obfDat.

[0187] The steps for proving and verifying proper timestamping are as follows: 1. The designated verifier generates the trapdoor commitment key

[0188] [Number]

[0189] such that the trapdoor is H = x·G

[0190] [Number]

[0191] Recall that the designated verifier sends CK DV to the data owner. 2. The data owner runs the algorithm Prove from the previous section on the input (m, C, CK DO , obf), r, and CK DV . The data owner sends (m, C, π DV ) to the designated verifier. 3. The designated verifier runs the algorithm Verify on the input (m, C, π DV ). If the output is being accepted, the designated verifier considers the data m to be appropriate.

[0192] 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.

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

[0194] In step 2, Alice 103a accumulates the obfuscated data value obfData in the blockchain 150 in the form of a proof blockchain transaction. The 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 accumulated in the blockchain 150.

[0195] In step 3, Bob 103b retrieves the obfuscated data value obfData from the blockchain. Bob selects the trapdoor value x and uses it to generate the designated verifier commitment key CK DV such that 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 together with the obfuscated data value obfData. This message serves or includes a request for a proof π to prove the ownership of the data m.

[0196] 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 CK DVis 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.

[0197] 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 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.

[0198] 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.

[0199] 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

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

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

[0202] 6.2 Privacy of Timestamps via Non-Transferable Proofs (m, C, π) having obfDat = SHA256(C), after receiving 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 π DV for any data m * ≠ m that he selects, 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. DV * In other words, Charlie 103c cannot tell whether the data was created before obfDat was uploaded to the blockchain (by Alice 103a) or later (when Bob 103b looks at the commitment C). This means that any data coming from Bob 103b is not restricted by the timestamp obfDat and maintains the privacy of m for anyone other than Bob 103b.

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

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

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

[0206] 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.

[0207] 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 (stored 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.

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

[0209] 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, σ) into the blockchain, where obfDat=SHA256(C).

[0210] 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, along with the non-interactive zero-knowledge proof π of knowledge of the opening r used to generate C from m. The designated verifier checks the proof using the Proof and the signature σ, and also that obfDat is the hash of C. * and the non-interactive zero-knowledge proof π of knowledge of the opening r used to generate C from m, along with the data m and the commitment C from the blockchain to the data owner. The designated verifier checks the proof using the Proof and the signature σ, and also that obfDat is the hash of C. DV and the non-interactive zero-knowledge proof π of knowledge of the opening r used to generate C from m, along with the data m and the commitment C from the blockchain to the data owner. The designated verifier checks the proof using the Proof and the signature σ, and also that obfDat is the hash of C.

[0211] Figures 5a and 5b illustrate the two-step method described above.

[0212] Figure 5a illustrates 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.

[0213] 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.

[0214] Alice 103a requests the notary 502 to notarize data m. To do so, Alice 103a sends the scheme 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.

[0215] The notary 502 returns the signed data Data * :=(obfDat, σ) to Alice 103a. Alice 103a generates a blockchain transaction to accumulate the signed data, including the scheme ID and data owner ID, into the blockchain 150 and sends that blockchain transaction using the "store_data" command to be accumulated in the blockchain 150.

[0216] Figure 5b shows the verification phase 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 scheme ID, and the data owner ID that identifies Alice 103a. The parameters and the signed data are returned to Bob 103b along with the scheme ID and data owner ID.

[0217] 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.

[0218] 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 implements 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.

[0219] 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.

[0220] 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 stored in the blockchain. These two services may be provided in exchange for a fee.

[0221] 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 with their secret value r.

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

[0223] The designated verifier (Bob 103b) registers with the notary 502 by sending his commitment key CK DV 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 DV . Alternatively, Bob 103b may outsource the commitment key generation to a trusted third party in order to reveal the trapdoor value x to the designated verifier. The registration is described in more detail below.

[0224] 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.

[0225] 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).

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

[0227] Explicit signature: The notary 502 signs the data commitment C and sets the obfuscated data to obfDat = SHA256(C||σ), thus, 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).

[0228] 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.

[0229] 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 reuse the same proof for all of them.

[0230] Attack: A malicious verifier can generate the commitment key CK in a way that the secret is shared (trapdoor), where each colluding verifier V DV generates an additive share of the trapdoor x i and then, without disclosing x

[0231]

Number

[0232] and then CK i :=(G,H := x1·G+...+x DV n ​·G) can be set. None of the verifiers know the trapdoor x := x1+...+x n so the same proof π DV will be believed by all of them.

[0233] In such an attack, one of the malicious verifiers may obtain the proof π DV from the notary and may pass the proof to other malicious verifiers who will also 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.

[0234] The notary can be protected against this type of collusion of verifiers in two ways.

[0235] 8.2.1 External Delegation of Trapdoor Generation An easy solution to avoid malicious collusion of verifiers is to externally delegate the generation of the trapdoor commitment key (x, CK DV ) to a party called the trapdoor generator in this specification. This party is trusted not to collude with the notary to share the trapdoor x and not to generate simulated proofs. When a generation request is received 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.

[0236] No 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 use CK DVBe convinced that the knowledge of the trapdoor x of [[ID=]] is known by at least one party - the de facto designated verifier - i.e., the party that requested the trapdoor generator to generate the key. This will make the proof π believable only to such a designated verifier (and the trapdoor generator), not to the other members of the partnership.

[0237] 8.2.2 Proof of Knowledge of a Trapdoor in Zero Knowledge The solution described in Section 8.2.1 introduces a new party with a high 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 .

[0238] 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 , the cooperation of the verifier's partnership as above can prove the combined knowledge of x.

[0239] 8.2.2.1 Underlying Idea Commitment key CK DV To register with notary 502, the designated verifier (Bob 103b) acts as the prover and 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.

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

[0241]

Number

[0242] where Hash is a cryptographic hash function (with collision resistance). Here, a is the randomness used to generate the first message of the Schnorr protocol. Then, when the challenge bit e is revealed, the prover sends z e and the verifier checks that z e is the

[0243]

Number

[0244] preimage of.

[0245] This modified Schnorr protocol gives a soundness error

[0246]

Number

[0247] To amplify the soundness to p = 2 -s the protocol can be repeated s times continuously.

[0248] 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 has to be run a total of

[0249]

Number

[0250] is repeated and looped.

[0251] According to this, the prover needs to commit to two d different responses z i = r + e i to x. This can be efficiently done using a Merkle tree of depth d where the i-th leaf is set to z i before the verifier issues the challenge e * . The prover sends the root c of the Merkle tree, and in response, the verifier uses the Merkle proof

[0252]

Number

[0253] together with z * = r + e * to respond using x. Since the Merkle tree commits to one element, namely the Merkle root, along with the n values assigned to the leaf nodes, it is sometimes referred to in this specification as a succinct commitment.

[0254] 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 (when the first message is fixed) from two different accepting transcripts. More specifically, from two different challenges e ≠ e' and two responses z, z', E can

[0255]

Number

[0256] Extract by calculating.

[0257] 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, if the prover knows all possible answers, they explicitly know the trapdoor x. Although they do not know the answer

[0258]

Number

[0259] A valid Merkle proof for

[0260]

Number

[0261] The probability of providing is at most dε, where ε is the probability of finding a collision of the hash function used in the 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,

[0262]

Number

[0263] Note that ε can be ignored for the size of.

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

[0265]

Table 3

[0266] This zero-knowledge proof system proves the 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.

[0267] To maintain zero-knowledge (of the trapdoor), the prover (the designated verifier, i.e., Bob 103b) executes all rounds consecutively. This affects how the challenge is derived from the transcript. Specifically,

[0268] [Number]

[0269] Let be the transcript generated in the i-th round. The (i + 1)-th challenge is

[0270] [Number]

[0271] 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.

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

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

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

[0275] Bob 103b then executes the proof algorithm described above. First, he sets π0 using the context information containing 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 called the challenge proof part.

[0276] 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 of the Merkle tree from 0 to 2 d - 1 such that there are 2 d leaf nodes in each Merkle tree related to the response values. d - 1.

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

[0278] The challenge value e i is 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.

[0279] Bob 103b has a Merkle tree whose root is

[0280]

Number

[0281] a leaf of the Merkle tree and

[0282]

Number

[0283] contains an authentication path to prove that

[0284]

Number

[0285] it generates a Merkle proof for the selected response value, and then generates the challenge proof part π i The challenge proof part includes a commitment, a Merkle root, a challenge value, and the selected response value.

[0286] Bob 103b generates a proof π that includes each π i for 1 ≤ i ≤ r together with the Merkle proof (authentication path)

[0287]

Number

[0288] That is, he generates it based on r Merkle trees. The challenge proof π includes a Merkle root, a Merkle proof, a challenge, and the selected response value.

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

[0290] Bob 103b provides the proof π and his commitment key CK DV to the notary 502. In a manner similar to Bob 103b, the notary 502 uses the context information to set π0.

[0291] 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 also provided in the challenge proof π, which is also called the target challenge value.

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

[0293] 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

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

[0295] 8.2.2.5 Parameter Complexity and Selection ​A Pedersen commitment is initiated via an arbitrary elliptic curve having a degree p of 256 bits and a hash function used to derive challenges and construct a Merkle tree using SHA-256. These selections produce a proof of bit size approximately r(512 + 257d), where d ≪ 256 is the bit size of the challenge and r is the number of iterations (rounds).

[0296]

Number

[0297] However, d ≪ 256 is the bit size of the challenge and r is the number of iterations (rounds).

[0298] 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, which is to minimize both the computational complexity and the communication complexity. However, this would result in a Merkle tree that is overly large for the prover to compute (e.g., 2 s leaf nodes), 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.

[0299] The specific values of r and d should be determined empirically,

[0300]

Number

[0301] keeping in mind that the soundness security parameter is fixed at s ∈ {80, 128, 256} and should be determined empirically.

[0302] 9. Alternative Forms In the example described above, data m, data commitment value C, and obfuscated data value obfData are retrieved from blockchain 150. It will be understood that some or all of these values may 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 will be understood that the use of a blockchain to accumulate and transfer these values brings an additional level of trust when the value is immutably accumulated thereon.

[0303] The data commitment value in the above example is C = m·G DO + r·H DO It will be 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, data commitment value C, or any other suitable value), or it may be a public key.

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

[0305] While the DID is decentralized, the VC can be issued by a trusted entity with cryptographically verifiable credentials. The W3C has also introduced the idea of verifiable presentation (VP) of VC, which may enable selective disclosure and other features to maximize the privacy of VC holders.

[0306] 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 convince others that she is over 18 years old. To protect her privacy, Alice can generate a ZKP with Bob as the designated verifier.

[0307] 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 the X509 format. This implies that she is over 18 years old if she can generate a digital signature for the proven public key. However, instead of generating a valid digital signature that can be reused to convince others, Alice can generate a ZKP of her private key for the designated verifier Bob. As a result, Bob can be convinced that Alice knows the private key without using her digital signature, and Bob cannot convince anyone else.

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

[0309] 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.

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

[0311] 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 the present disclosure is limited not by the described embodiments, but only by the appended claims.

[0312] 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 understood that the Bitcoin blockchain is one specific example of the blockchain 150, and the above description may generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any of the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may each be replaced with a reference to 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.

[0313] 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 accumulating the blocks 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 accumulating blocks without creating and issuing them (recall that these entities are not considered nodes of a suitable Bitcoin network 106).

[0314] 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 accumulating 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 accumulate and / or propagate those blocks 151 to other nodes.

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

[0316] Regarding the implementation of a proof-of-work consensus mechanism by a blockchain network to secure a blockchain forming a basis, several embodiments are described. However, proof-of-work is just one type of consensus mechanism, and generally, 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 look up their tokens over some period of time in order to have the opportunity to become validators. Generally, the node that locks up the most funds for the longest period of time has the best chance of becoming the next validator.

[0317] It will be understood that the above embodiments are merely described as examples. More generally, a method, apparatus, or program may be provided by any one or more of the following statements.

[0318] Statement 1. A computer-implemented method for proving sole ownership of a commitment key, the commitment key comprising two elements, a secret trapdoor value x defining a relationship between the elements of the commitment key, the method comprising repeatedly calculating a challenge proof portion π i over a predefined number of iterations d, the challenge proof portion being generated based on a succinct commitment derived using the secret trapdoor value x, and the challenge proof portion π igenerating a challenge proof π based on [the above], and making the challenge proof π available to a verifier, where the challenge proof π is a non-interactive zero-knowledge proof that proves knowledge of a secret trapdoor value x.

[0319] Statement 2. The method of Statement 1, wherein the succinct commitment is represented by a Merkle tree.

[0320] Statement 3. The method of Statement 2, further comprising, for each iteration, deriving a corresponding Merkle tree, and assigning an answer value z calculated based on the trapdoor value x and a randomly selected value a i to at least some leaf nodes of the Merkle tree. i,j

[0321] Statement 4. The method of Statement 3, wherein each answer value is calculated using z i,j = a i + jx mod p where i is the iteration, j is the leaf node number, and p is a soundness error.

[0322] Statement 5. The method of any of the foregoing statements, further comprising, for each iteration, generating a challenge based on the Merkle root of the Merkle tree and a previous challenge proof portion π i-1

[0323] Statement 6. The method of Statements 3 and 5, further comprising selecting one of the answer values based on the generated challenge.

[0324] Statement 7. The method of Statement 6, further comprising generating a Merkle proof based on the selected answer value among the answer values.

[0325] Statement 8. The method of Statements 5 and 6, wherein the challenge proof portion π iIt comprises a Merkle root, a selected answer value among the answer values, and a part of the challenge.

[0326] Claim 9. The method of claim 8, wherein the challenge proof π comprises, for each iteration, a Merkle root, a Merkle proof, a challenge, and a selected answer value.

[0327] Claim 10. The method of any of the preceding claims, wherein each Merkle tree comprises 2 d leaf nodes, and d is the number of bits of the challenge corresponding to the challenge proof π.

[0328] Claim 11. The method of any of the preceding claims, wherein the challenge proof is made available to the verifier using a request for registering a commitment key with the verifier, and the verifier is configured to use the registered commitment key to generate a proof of knowledge of a secret value r, and the proof of knowledge of the secret value r can be verified only by a user having knowledge of the commitment key.

[0329] Claim 12. The method of claim 11, the method further comprising receiving a target designated verifier commitment value derived based on the secret value r and the commitment key, calculating a candidate designated verifier commitment value based on the commitment key, and comparing the target designated verifier commitment value with the candidate designated verifier commitment value.

[0330] Claim 13. The method of claim 11 or claim 12, the method comprising obtaining data m, obtaining a data commitment value C calculated based on the secret value r and the data m, receiving a data challenge solution, wherein the data challenge solution is a non-interactive zero-knowledge proof proving knowledge of the secret value r, and verifying the data commitment value C based on the data m and the data challenge solution.

[0331] Claim 14. A method for verifying sole ownership of a commitment key, where the commitment key comprises two elements and the relationship between the elements of the commitment key is defined by a trapdoor value x, the method comprising receiving from a candidate designated verifier the commitment key and a challenge proof π, where the challenge proof π is derived from a plurality of Merkle trees and the challenge proof comprises a Merkle proof and a target challenge value for each of the plurality of Merkle trees, for each of a predetermined number of iterations, where the number of iterations corresponds to the number of Merkle trees from which the challenge proof is derived, checking the Merkle proof corresponding to the Merkle tree, calculating a candidate challenge value and comparing it with the target challenge value of the challenge proof π, and where the Merkle proof check passes and the candidate challenge value is equal to the target challenge value, sole ownership is verified.

[0332] Claim 15. The method of Claim 14, the method further comprising receiving a request to use the commitment key to generate a proof of knowledge of a secret value r, where the proof of knowledge of the secret value r can only be verified by a designated verifier having knowledge of the commitment key, and the request is honored if sole ownership is verified.

[0333] Claim 16. The method of Claim 14 or Claim 15, the step of checking the Merkle proof comprising determining whether the Merkle proof corresponds to a Merkle proof preimage, where the challenge proof π comprises a Merkle proof preimage for each of the plurality of Merkle trees.

[0334] Claim 17. The method of Claim 16, where the Merkle proof preimage is a selected response value z among a plurality of response values z calculated based on the trapdoor value x and a randomly selected value a. i of the selected response values.

[0335] Claim 18. The method of Claim 17, where the selected response value is selected based on the target challenge value.

[0336] Claim 19. Any one of the methods of Claims 14 to 18, wherein the candidate challenge value is calculated based on the received commitment key and the challenge proof π.

[0337] Claim 20. Any one of the methods of Claims 14 to 19, wherein the challenge proof includes a Merkle root for each Merkle tree, and the Merkle proof check is based on the Merkle proof, the target challenge value, and the Merkle root provided in the challenge proof.

[0338] Claim 21. The method of Claim 15 or any claim dependent thereon, the method further comprising generating a designated verifier commitment value based on the commitment key and the secret value r, and making the designated verifier commitment value available to the designated verifier.

[0339] Claim 22. The method of Claim 21, the method further comprising generating a data challenge solution based on the secret value r and the designated verifier commitment value, the data challenge solution being a non-interactive zero-knowledge proof proving knowledge of the secret value r.

[0340] Claim 23. 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 execute on the processing device, the code being configured to cause the processing device to execute any one of the methods of Claims 1 to 22 when executed on the processing device.

[0341] Claim 24. A computer program embodied on a computer-readable storage and configured to execute any one of the methods of Claims 1 to 22 when executed on one or more processors.

Description of Reference Numerals

[0342] 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, distributed 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 203 UTXO 502 Notary

Claims

1. A computer-implemented method for proving sole ownership and / or possession of a commitment key, wherein the commitment key comprises two elements, a secret trapdoor value x defines a relationship between the elements of the commitment key, the method comprising: Repeatedly calculating the challenge proof part π over a given number of iterations d i wherein the challenge proof part is generated based on a succinct commitment derived using the secret trapdoor value x, and the step of repeatedly calculating the challenge proof part π i generating a challenge proof π based thereon; making the challenge proof π available to a verifier; wherein the challenge proof π is a non-interactive zero-knowledge proof proving knowledge of the secret trapdoor value x.

2. The method according to claim 1, wherein the succinct commitment is represented by a Merkle tree.

3. further comprising, for each iteration, a step of deriving a corresponding Merkle tree, the trapdoor value x and the randomly selected value a i the response value z calculated based on i,j is assigned to at least some leaf nodes of the Merkle tree, the method according to claim 2.

4. Each response value is z i,j =a i +jx mod p calculated using, where i is the iteration, j is the leaf node number, and p is a soundness error, the method according to claim 3.

5. For each iteration, further comprising the step of generating a challenge based on the Merkle root of the Merkle tree and the previous challenge proof part π i-1 The method according to any one of claims 1 to 4, further comprising the step of generating a challenge based on i-1 .

6. The method according to claims 3 and 5, further comprising selecting one of the response values based on the generated challenge.

7. The method according to claim 6, further comprising generating a Merkle proof based on the selected response value among the response values.

8. the challenge proof part π i The method according to claim 5 and 6, wherein the challenge proof part π comprises the Merkle root, the selected response value among the response values, and a part of the challenge.

9. The challenge proof π, for each iteration, the Merkle root, the Merkle proof, the challenge, and the selected response value The method according to claim 8, comprising.

10. Each Merkle tree has 2 d leaf nodes, and d is the number of bits of the challenge corresponding to the challenge proof π, the method according to any one of claims 1 to 9.

11. The challenge proof is made available to the verifier using a request for registering the commitment key with the verifier, the verifier being configured to use the registered commitment key to generate a proof of knowledge of a secret value r, the proof of knowledge of the secret value r being verifiable only by a user having knowledge of the commitment key. The method according to any one of claims 1 to 10.

12. receiving a target-designated verifier commitment value derived based on the secret value r and the commitment key; calculating a candidate-designated verifier commitment value based on the commitment key; comparing the target-designated verifier commitment value with the candidate-designated verifier commitment value The method according to claim 11, further comprising.

13. obtaining data m; obtaining a data commitment value C calculated based on the secret value r and the data m; A step of receiving a solution to a data challenge, wherein the solution to the data challenge is a non-interactive zero-knowledge proof that proves knowledge of the secret value r A step of verifying the data commitment value C based on the data m and the solution to the data challenge The method according to claim 11 or 12, comprising:

14. A method for verifying sole ownership and / or possession of a commitment key, wherein the commitment key comprises two elements, the relationship between the elements of the commitment key is defined by a trapdoor value x, and the method comprises: Receiving, from a candidate designated verifier, the commitment key and a challenge proof π, wherein the challenge proof π is derived from a plurality of Merkle trees, and the challenge proof comprises, for each of the plurality of Merkle trees, a Merkle proof and a target challenge value For each of a predetermined number of iterations, the number of iterations corresponding to the number of Merkle trees from which the challenge proof is derived Checking the Merkle proof corresponding to the Merkle tree Calculating a candidate challenge value and comparing it with the target challenge value of the challenge proof π, comprising: When the Merkle proof check passes, and When the candidate challenge value is equal to the target challenge value, Sole ownership is verified Method

15. The method according to claim 14, further comprising receiving a request to use the commitment key to generate a proof of knowledge of the secret value r, wherein the proof of knowledge of the secret value r can be verified only by the designated verifier having knowledge of the commitment key, and the request is accepted when sole ownership is verified

16. The method according to claim 14 or 15, wherein the step of checking the Merkle proof comprises determining whether the Merkle proof corresponds to a Merkle proof preimage, and the challenge proof π comprises the Merkle proof preimage for each of the plurality of Merkle trees

17. The method according to claim 16, wherein the Merkle proof preimage is a selected response value among a plurality of response values z calculated based on the trapdoor value x and a randomly selected value a. i ​

18. The method according to claim 17, wherein the selected response value is selected based on the target challenge value

19. The method according to any one of claims 14 to 18, wherein the candidate challenge value is calculated based on the received commitment key and the challenge proof π.

20. The method according to any one of claims 14 to 19, wherein for each Merkle tree, the challenge proof includes a Merkle root, and the Merkle proof check is based on the Merkle proof, the target challenge value, and the Merkle root provided in the challenge proof.

21. generating a designated verifier commitment value based on the commitment key and the secret value r; making the designated verifier commitment value available to the designated verifier; The method according to claim 15 or any one of the claims dependent thereon, further comprising:

22. The method according to claim 21, further comprising generating a data challenge solution based on the secret value r and the designated verifier commitment value, wherein the data challenge solution is a non-interactive zero-knowledge proof proving knowledge of the secret value r.

23. A computer device, comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, and when the code is executed on the processing device, the processing device is configured to execute the method according to any one of claims 1 to 22.

24. A computer program embodied on a computer-readable storage and configured to execute the method according to any one of claims 1 to 22 when executed on one or more processors.

Images