Methods and systems for controlling access to, and integrity of, resources on a blockchain

This application generally relates to securing access to and control of digital resources, assets and/or data. This application may also relate to maintaining and enforcing the state of such digital entities and how they may be distributed or shared among computer-based resources. More specifically, this application relates to validating digital resources/assets/data by multiple nodes in a blockchain network.

The term "blockchain" is used herein to encompass all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. A widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Note that in some instances, Bitcoin may be referenced herein merely for convenience and illustrative purposes, but this application is not limited to use with the Bitcoin blockchain. Alternative blockchain implementations and protocols are within the scope of this application. The term "Bitcoin" is used herein to encompass all variations and versions derived from or based on the Bitcoin protocol. The abbreviation "BTC" may be used for convenience of reference only.

A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized system composed of blocks, which are made up of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between addresses in the blockchain system and contains at least one transaction input and at least one transaction output. Each block contains a hash of the previous block, so that blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception.

The concept of decentralization is fundamental to blockchain systems. Decentralized systems offer the advantage that, unlike distributed or centralized systems, there is no single point of failure. Thus, decentralized systems offer an enhanced level of security and fault tolerance. Security is further enhanced by the use of known cryptographic techniques such as Elliptic Curve Cryptography and ECDSA.

Ownership and control over digital assets or resources in a blockchain system is controlled through public-private key pairs. A digital asset or resource can be a token. A token can represent any type of entity. This can include currency, hard assets, soft assets, computing resources, or any other entity or service. For ease of reference, the term "asset" may be used. An unspent transaction output (UXTO) address is analogous to a public key, and control over the assets assigned to that UXTO is expressed by the use of the corresponding private key. In order to transfer a digital asset by using a UXTO as an input to another transaction, the input must be digitally signed by the corresponding private key. Thus, control over the security and confidentiality of private keys is the basis of the security and reliability of the blockchain.

One type of digital asset may include, for example, an electronic document. However, the invention is not limited to use with documents, and maintaining the access control, security and/or integrity of other types of digital resources is within the scope of the invention. For example, software is often distributed over a computing network. The distribution, storage and processing of that software must be performed in a secure manner, where access is controlled and unauthorized access or modification is prevented. The state and integrity of the software must be guaranteed and it must be verifiable that it has not been modified. Note that for convenience only, reference may be made to an electronic document as a convenient example.

In some circumstances, multiple nodes may submit documents under circumstances where the contents of the documents are kept confidential until all documents are revealed and changes to the documents after submission are prevented. Therefore, access to the data as well as the processing or manipulation of that data must be appropriately controlled. Paper-based submission processes relied on enclosing the documents in a sealed packet and opening the packet after receiving submissions from all participants. As all such systems are now implemented using computer networks and documents are provided in electronic form, sealing such documents and preventing their tampering becomes very difficult. There is a significant risk that submitted electronic documents may be revealed or accessed inappropriately and the integrity of the documents or the submission process may be attacked. The process requires trust in the manager or principal who oversees and implements the submission system and trust in the technical security of the computer system to receive and store the documents. This is not ideal as security breaches and unauthorized data access and, in some cases, changes to it, are various and well known.

By way of example only and not by way of limitation, electronic documents may be submitted as part of a tender procurement process in a competitive bidding situation. To maintain the integrity of the process, it is essential that a bidder not have access to another bidder's materials prior to the end of the submission period and that a bid not be modified after it is submitted. Thus, bidders must rely on the honesty and integrity of the party seeking the bid, as well as the security of any computing systems used for bid submission and storage.

In another purely illustrative example, the documents may be submitted as part of a real estate purchasing process, such as an application and underwriting process involving multiple applied parties. Existing real estate application and underwriting processes typically rely on a real estate broker to maintain the integrity and security of the application and underwriting process and ensure that each applicant is not privy to the details of another applicant's application. Although applications may be received via facsimile or email, existing devices and systems rely on the integrity of the real estate broker to maintain the security of the application documents and to reveal the application documents only after all applicants have submitted them.

In another example, a document may be submitted as part of a testing process, such as submitting an exam question or essay for marking. The contents of the paper should not be made available to anyone until all papers have been submitted, to prevent copying, and no changes to submitted papers should be possible.

Other example scenarios may also be enabled through providing a method and system that ensures submitted documents remain secure and confidential and that each document is verifiably unaltered until all submissions have been received. It would be advantageous to provide a method and system that ensures submitted electronic documents are secure and inaccessible to all until all documents are accessible.

<p>Thus, there is a need for improved solutions for data and digital resources where access and storage must be controlled in a secure manner that prevents modification of the state of the data/resources and/or allows for the integrity of that state to be verified.</p>

<p>The present application provides, among other things, methods and systems having such advantages.</p><p>The present application provides methods and systems as defined in the accompanying claims.</p><p>In overview, the present application may provide computer-implemented methods and systems for controlling access to a digital asset or resource, maintaining the state of the asset or resource, and/or verifying that the state has not been altered.</p><p>The method and system of the present invention may provide that participating nodes maintain private key shares and collaboratively create public keys. Digital resources or assets submitted by one of the participating nodes are encrypted using the node's own public key and the collaborative public key, meaning that the node's own private key and the collaborative private key are required to decrypt the digital asset or resource. (Importantly, it is noted that in the following, digital assets/resources/data may also be referred to as "assets", "digital assets" or "documents" purely for convenience, but without limiting the present invention).</p><p>Through the formation of a commitment channel between each participating node and the main node, the participating node can obtain public storage. Each participating node may finally submit a transaction revealing its private key share in the blockchain, such that any of the nodes may then create a joint private key from the share retrieved from the blockchain. If a participating node intends its own document to be revealed (as it may choose to withdraw), then the participating node may also disclose its own private key, thereby enabling the document to be decrypted. The blockchain transaction may further include a hash of the submitted document to enable verification of the document's integrity. "Verifying the integrity" may include verifying or proving that the state of the digital resource has not been altered. In this way, nodes can be assured that their documents are only revealed when all other nodes participate in revealing their respective key shares in the blockchain, such that all documents from participating nodes are decryptable and accessible at the same time. The system can provide coordinated and synchronized access to encrypted documents in such a way that the documents are verifiably unaltered.</p><p>The present invention may provide a computer-implemented method for controlling access to and/or verifying digital resources (e.g., documents, software, etc.) by multiple nodes and a principal node in a blockchain network.</p><p>The nodes may have respective private key shares, and a collective private key of a collective private-public key pair is based on the set of respective private key shares, and the first node may have a first nodal private-public key pair. The method may be performed by a node. The method may include generating, by the first node, a document encryption public key by combining a first node public key of the first node private-public key pair with a joint public key of the joint private-public key pair; encrypting a document using the document encryption public key; generating, by the first node, a commitment transaction having a commitment transaction output locked by the first node's private key share such that a valid subsequent transaction having the commitment transaction output as an input (requires) to include the first node's private key share; and receiving, by the first node, the valid subsequent transaction signed by the principal node. The method may also include broadcasting the commitment transaction to the blockchain network in response to receiving the valid subsequent transaction signed by the principal node.</p><p>In some implementations, the method includes broadcasting, by the first node, a valid subsequent transaction signed by the principal node to the blockchain network before the first timelock threshold to reveal the first node's private key share in the blockchain.</p><p>In some implementations, the method includes retrieving from the blockchain a set of private key shares associated with the document; in response to determining that the amount of the private key shares is greater than a private key sharing threshold, regenerating a joint private key of a joint private-public key pair from the retrieved set of private key shares; and decrypting the encrypted document using the document encryption private key, where the document encryption private key is a combination of the regenerated joint private key and a first node private key of the first node private-public key pair.</p><p>In some implementations, the commitment transaction has a transaction output that includes one or more unlocking options, including a reveal option that requires a transaction input along with a hash of the document, the first node's private key share, the first node's private key of the first node's private-public key pair, the signature of the principal node, and the signature of the first node, such that a valid subsequent transaction includes a transaction input along with a hash of the document, the first node's private key share, the first node's private key of the first node's private-public key pair, the signature of the principal node, and the signature of the first node to select the reveal option.</p><p>In some implementations, the commitment transaction has a transaction output (UTXO) that includes more than one unlocking option, including a revocation option that requires the first node's private key share, the principal node's signature, and the first node's signature, such that a valid subsequent transaction includes a transaction input with the first node's private key share, the principal node's signature, and the first node's signature to select the revocation option.</p><p>In some implementations, the commitment transaction has a transaction output that includes more than one unlocking option, including a timeout option that requires the signature of the principal node and the signature of the first node, such that a valid subsequent transaction includes a transaction input with the signature of the principal node and the signature of the first node to select the timeout option.</p><p>In some implementations, the encrypted document is stored in a public repository and a commitment transaction is broadcast to the blockchain network in which the document generated by the first node is saved in the public repository.</p><p>In some implementations, the encumbrance on the first asset value is removed in response to a transaction input of a valid subsequent transaction having at least a signature of the principal node and a signature of the first node.</p><p>In some implementations, the valid subsequent transaction is a revocation transaction signed by the principal node, and prior to receiving the revocation transaction signed by the principal node, the method includes generating a revocation transaction that includes a transaction input having a private key share of the first node and a signature of the first node.</p><p>In some implementations, the limit on the first asset value is removed in response to the transaction input of the revocation transaction having the first node's private key share, the principal node's signature and the first node's signature, the limit on the second asset value is removed in response to the transaction input of the further transaction having the principal node's signature, and the limit on the third asset value is removed in response to the transaction input of the further transaction having the first node's signature, the third asset value being the difference between the first asset value and the second asset value.</p><p>In some implementations, the valid subsequent transaction is a public transaction signed by the principal node, and prior to receiving the public transaction signed by the principal node, the method includes generating the public transaction to include a transaction input having a hash of the document, the first node's private key share, the first node's private key of the first node private-public key pair, and the first node's signature.</p><p>In some implementations, the restriction on the first asset value is removed in response to the transaction input of the public transaction having a hash of the document, the first node's private key share, the first node private key of the first node private-public key pair, the principal node signature, and the first node signature, the restriction on the fourth asset value is removed in response to the transaction input of the further transaction having the principal node signature, and the restriction on the fifth asset value is removed in response to the transaction input of the further transaction having the first node signature, the fifth asset value being the difference between the first asset value and the fourth asset value.</p><p>In some implementations, the step of generating one or more blockchain transactions for the first commitment channel includes generating a timeout transaction, the timeout transaction eligible to be broadcast to the blockchain network by the principal node after a first timelock threshold has elapsed.</p><p>The present application also provides a computing device for carrying out the method defined above.</p><p>The present application also provides a non-transitory processor-readable medium storing processor-executable instructions which, when executed by a processor, cause the processor to perform the method defined above.</p><p>These and other aspects of the present application will be apparent from and elucidated in conjunction with the embodiments described herein.</p>

Embodiments of the present application will now be described, by way of example only, with reference to the accompanying drawings, in which:

<figref num="1">FIG. 1 illustrates, in block diagram form, a document repository system according to an example of the present application.</figref><figref num="2">FIG. 2 illustrates a commitment channel according to an example of the present application.</figref><figref num="3A">FIG. 2 illustrates a commitment transaction according to an example of the present application.</figref><figref num="3B">FIG. 2 illustrates a rescind transaction according to an example of the present application.</figref><figref num="3C">FIG. 2 illustrates a reveal transaction according to an example of the present application.</figref><figref num="3D">FIG. 2 illustrates a timeout transaction according to an example of the present application.</figref><figref num="4">FIG. 2 illustrates a commitment channel between a master node and each of several nodes according to an example of the present application.</figref><figref num="5">FIG. 2 is a sequence diagram of transactions between a node, a master node, and an electronic ledger according to an example of the present application.</figref><figref num="6">FIG. 2 illustrates, in flow chart form, a method implemented in a node that submits a document to a document repository system, according to an example of the present application.</figref><figref num="7">FIG. 2 illustrates, in flow chart form, a method implemented in a node for validating documents submitted to a document repository system.</figref><figref num="8">FIG. 2 illustrates a simplified node in block diagram form.</figref>

The present application provides a digital resource repository system for use in a blockchain network to verify that digital resources (e.g., documents, software, data, other digital assets, etc.) submitted to the repository system have not been altered after submission and to ensure that the contents of the submitted documents cannot be revealed to other participating nodes until such time as each participating node reveals at least a private key to decrypt the encrypted document. In the following, the term "document" is used for convenience. However, any type of digital resource to which access needs to be controlled and/or verified is within the scope of the present invention.

The following description provides implementations, use cases and examples related to blockchain protocols, including the Bitcoin protocol, however, the application has broader application and may be used with other systems and computer-based resources and is not limited in this respect.

In this application, each node submits a document to the document repository system via a state-based transaction for eventual broadcast to the blockchain network. After the submission of a document to the document repository system, each node participating in the validation of the document or documents submitted by other nodes may reveal its private key share via a publish or revoke transaction. Furthermore, when each node broadcasts a publish transaction to the blockchain network, each node provides its node private key to reveal the contents of the document submitted by that node. Thus, the document repository system described herein enables immutability of submitted documents and time consistency for the document selection process among participating nodes.

In this application, the term "and/or" is intended to include any one of the listed elements alone, any subcombination, or all of the elements, and to cover all possible combinations and subcombinations of the listed elements without unnecessarily excluding additional elements.

As used in this application, the phrase "at least one of ... or ..." is intended to cover all possible combinations and subcombinations of the recited elements, including any one of the recited element alone, any subcombination, or all of the elements, without unnecessarily excluding any additional elements, and without necessarily requiring all of the elements.

Referring now to FIG. 1, FIG. 1 illustrates in block diagram form a document repository system 100 according to an example of the present application. The document repository system 100 may include a blockchain network, such as a peer-to-peer open membership network. Any number of nodes may join the blockchain network without invitation or consent from other nodes. The blockchain network includes an electronic ledger 102, which may be made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset or value.

The document repository system 100 may include one or more nodes 106. The nodes 106 may be electronic devices and may execute a blockchain protocol. The nodes 106 may be various types of electronic devices, including, for example, computers (e.g., desktop computers, laptop computers, tablet computers, servers, etc.), mobile devices (e.g., smartphones, wearable devices such as smart watches), or other types of electronic devices. The nodes 106 may be coupled to each other using any suitable communication technology, which may include wired or wireless communication technology. In some examples, the document repository system 100 may be implemented at least in part over the Internet, and some of the nodes 106 may be located in geographically distributed locations.

One or more nodes 106 may maintain one or more electronic ledgers 102 of transactions. Each node 106 may store a full or partial copy of the global ledger. Transactions that affect the electronic ledger 102 may be verified by one or more nodes 106 so that the validity of the electronic ledger 102 may be maintained. The details of implementing and operating a blockchain network such as the Bitcoin protocol may be appreciated by those skilled in the art.

In some implementations, each respective node 106 has a node private-public key pair (q_i, Q_i) Each node 10 may generate a node private-public key pair, in which case the node private-public key pair may be used as a "one-time code." For example, the node public key (Q_i) may be used together with an encryption method to encrypt the document._i) may be distributed in response to satisfaction of an operation of a protocol (e.g., as described herein) and may be used in conjunction with a decryption method to decrypt the encrypted document. Thus, once a node private key of a node private-public key pair is revealed, that node 106 may cease using that node private-public key pair for future cryptographic operations.

The document repository system 100 may include a master node 104. The master node 104 may interface with one or more nodes 106 and other components of the document repository system 100. As described herein, the master node 104 may perform operations described herein to form commitment channels with each node 106 and may perform operations described herein for the document repository system 100.

The document repository system 100 may include a data store 120. The data store 120 may collect and store documents. The collected and stored documents may be encrypted documents. In some examples, the data store 120 may include a hash of each document or a hash (e.g., a double hash) of each hashed document. Hashing a document may map the document, which may have any size, to data of a fixed data size.

The data store 120 may be accessible by one or more nodes 106 or the master node 104. A document may be any electronic digital file, such as a long detailed multipage entry or a number. In some examples, a document may be a small finite set of characters, concatenated with a nonce (e.g., a random number).

The encrypted documents stored in the data store 120 are encrypted using a document crypto public key (L_i) may be encrypted with the document encryption public key (L_i) is L_i=P+Q_iwhere a common private key (p) corresponding to the common public key P may initially be unknown to the nodes 106 of the document repository system 100 .

For example, the first node 106 may have a first node private-public key pair (q_i, Q_i)'s first node public key (Q_i) with a joint public key (P) of a joint private-public key pair to generate a document encryption public key. The joint private key (p) of the joint private-public key pair may be based on a set of respective secret key shares. The respective secret key shares may be distributed according to, for example, a threshold secret sharing method. Furthermore, the joint private key (p) may be generated when a set of secret key shares is retrieved from each of the respective nodes 106. As described herein, the joint private key (p) may be generated when a set (or a sufficient/threshold number) of secret key shares are revealed by the respective nodes 106, such that the respective nodes 106 may jointly reveal or verify an encrypted document stored in the data store 120. As described herein, the respective nodes 106 may reveal their secret key shares by broadcasting a valid subsequent transaction, such as a reveal transaction or a revocation transaction.

One or more nodes 106 in the document repository system 100 may perform one or more operations of a threshold secret sharing protocol. For example, one or more nodes 106 may perform operations of a threshold secret sharing protocol to distribute or assign secret key shares to each node 106. Each secret key share may be used to reveal or decrypt one or more documents stored in the data store 120. The one or more nodes 106 that collectively perform operations according to the threshold secret sharing protocol may be organized into a cluster of nodes 130, as illustrated in FIG. 1.

In some examples, a threshold secret sharing protocol may be defined by a (t;n) threshold, where n may be the number of participating nodes 106 and t+1 may be the minimum number of nodes required to reconstruct the secret. A secret sharing scheme may be an example of a threshold cryptosystem, where a secret may be split into parts among n nodes such that at least t+1 nodes need to participate to reconstruct the secret. Knowledge of any t parts may leave the secret unrevealed.

An example of a threshold secret sharing solution is described in an article entitled "How to share a secret" by Shamir, A., published in Communications of the ACM, 22(11), 612-613 (1979) ("Shamir's method"). Shamir's method is based on polynomial interpolation and wlog, and the secret is assumed to be an element of a finite field F. Shamir's method may include dealer or dealerless methods, and has n nodes U₁,...,U_nand an access structure A. A group of participants can reconstruct the secret. In Shamir's algorithm, any random secret is stored as f(0) in a polynomial f(x) of degree t, and only participant i can access its share f(x_i) can be calculated using Lagrange polynomial interpolation.₁),f(x₂),...,f(x_n) their shares k (of key k)₁,k₂,...,k_nUsing Lagrange polynomial interpolation, we can reconstruct a function f(x) of degree t using t+1 points:<math num="1"><img file="JP7629479B2_D0001.tif" /></math>

In the presence of a dealer node, the dealer node acquires a secret a, which is assumed to be an element of a finite field F of size p (p is a prime number).₀= k and randomly choose t-1 positive integers a1,...at-1, which are the polynomials f(x)=a₀+a₁x+a₂x²+.... The dealer node then identifies the n points (x_i,f(x_i)) and distribute them among the participants.

In the Shamir Dealerless Share Distribution Phase: 1. Each participant U_iEveryone knows x_iis assigned to each x_imust be unique.

2. Each player U_iis a random polynomial f of degree t_iGenerate (x).

3. Each player U_isends to all other players a polynomial f_i(x_j) mod n.

4. Each player U_iAll of them received f₁(x_i),f₂(x_i),...f_p(x_i) (all mod n, where n is the degree of the group generated by the point G on the elliptic curve) to get k_i=f(x_i) mod n, which is a share on the polynomial f(x) mod n.

The above description of Shamir's method is one example of a threshold secret sharing solution, however, other methods or threshold secret sharing solutions may also be considered.

In some implementations, the threshold signature computation may be based on determining k?G, where k is the private key and G is a point on the elliptic curve.

If f(x) is a t-th degree polynomial, then the secret k is k=?_i??b_i,?k_iwhere ? is the share k_a,k_b,...,k_t,k_t+1may be a subset of size t+1 of , and b may be an interpolating factor._imay be a group of t+1 nodes that jointly compute k?G without revealing k. k may be the point x=0 in a polynomial of degree t.

?Each node U_iis part b_i,?k_i?G can be calculated.

All nodes in ? add their parts together (reconstructing the secret k via Lagrange interpolation) to give:_a,?k_a?G+b_b,?k_b?G+???+b_t+1,?k_t+1?G=k?G

The above process of computing Q=kG is sometimes called Secret Share Joining.

In some implementations, the threshold secret sharing operation involves sending a respective secret key share (p^{^}_i), where the joint private key (p) of the joint private-public key pair (p, P) is based on the set of respective private key shares. For example, the joint private key (p) may be generated or regenerated based on the set of respective private key shares and may be expressed as:<math num="2"><img file="JP7629479B2_D0002.tif" /></math>

Therefore, if n nodes 106 are present in the document repository system 100, each of the n nodes 106 has a secret key share (p^{^}_i), where a threshold amount of n or key shares may be required to generate a joint private key of a joint public key P in a joint private-public key pair (p, P).

The master node 104 and each node 106 may form a commitment channel 140. The commitment channel 140 represents an off-chain change of state and eventual settlement in the blockchain network/electronic ledger 102. In some examples, the document commitment channel 140 may include a series of transactions generated or signed by one or both of the principal node 104 or the node 106, as the case may be, for exchange before broadcasting those transactions to the blockchain network. The transactions of the commitment channel 140 may be kept off the blockchain network and function similarly to promissory notes for eventual broadcast to the blockchain network. Thus, as illustrated herein, when the principal node 104 and the respective node 106 form the commitment channel 140, the operations may include generating or signing by one or both of the principal node 104 or the node 106, and may further include broadcasting at least one of those transactions to the blockchain network to form the commitment channel 140. Because transactions based on the commitment channel 140 may be exchanged between the principal node 104 and the respective node 106 "off" the blockchain network, the transactions may be exchanged without the latency typically associated with broadcasting and verifying transactions on the blockchain network.

For ease of explanation, the commitment channel 140 is illustrated in Figure 1 as being between the principal node 104 and a selected node (e.g., node i). However, in some examples, a respective commitment channel 140 may be formed between the principal node 104 and each of one or more nodes 106 that participate in collectively validating or collectively publishing documents available in the data store 120.

Referring to Figure 2, Figure 2 diagrammatically illustrates a commitment channel 140 according to one example of the present application. In some examples, a node 206 or a principal node 204 may form a commitment channel 140 by generating a commitment transaction 250 and at least one other valid subsequent transaction signed by the principal node 204 and sending the commitment transaction 250 to the blockchain network. In some examples, the valid subsequent transaction may include a revocation transaction 252 or a public transaction 254. Additionally, either the node 206 or the principal node 204 may generate a timeout transaction 256.

2 further illustrates restricted digital assets 280. The commitment transaction 250 may include an unspent transaction output (UTXO) that includes an encumbrance of the digital assets 280. As described herein, the restricted digital assets 280 illustrated in FIG. 2 may be allocated in response to a valid subsequent transaction, such as a revocation transaction 252, a public transaction 254, or a timeout transaction 256.

A node 206 may generate and broadcast a commitment transaction 250 to the blockchain network where documents generated by the node 206 are stored in the data store 120. A node 206 may generate documents that the node 206 may want to store in the data store 120 (FIG. 1) and disseminate to other nodes via the document repository system 100. In some implementations, the contents of the generated documents may not be stored or recorded with the transaction on the blockchain network. However, a hash of the document (HoD) may be stored in the blockchain network._i) may be recorded by one or more transactions. The hash of the document may correspond to an encrypted document that may be stored in the data store 120. In some examples, a double hash of the generated document (e.g., H(HoD_i) may be recorded by a transaction broadcast to the blockchain network. The hash function may (1) map data of any size to data of a fixed size so that the generated document can be represented in a blockchain transaction within a predetermined amount of data; or (2) prevent a node 106 from modifying a generated document that may be stored in data store 120. Hashing the modified document may produce a different hash result, indicating that the document stored in data store 120 has been modified.

To provide examples of a commitment transaction 250, a revocation transaction 252, a publication transaction 254, and a timeout transaction 256, reference is now made to Figures 3A-3D, which illustrate respective transactions of a commitment channel 140 according to one example of the present application. In some implementations, a transaction may include a locking script (e.g., &lt;scriptPubKey&gt;). A locking script (e.g., &lt;scriptPubKey&gt;) may be an output of a transaction that may restrict digital assets or values ??by imposing rules or criteria that an unlocking script (e.g., &lt;scriptSig&gt;) of a valid subsequent transaction must satisfy to unencumber the digital assets or values ??of a previous transaction.

3A illustrates an example commitment transaction 250. A node 106 (FIG. 1) may generate a commitment transaction 250 to submit a document to the document repository system 100 (FIG. 1) for consideration by the principal node 104 (FIG. 1) or by other nodes 106 (FIG. 1). When the node 106 submits a document to the document repository system 100 for consideration, the node 106 may also submit a digital asset 390. The document repository system 100 may require submission of a specified value of the digital asset 390 in exchange for consideration of the submitted document by the principal node 104. The commitment transaction 250 may set a limit on the digital asset 390 until such time as a valid subsequent transaction allocates the digital asset 390.

The commitment transaction 250 may include one or more options for unlocking the digital asset 390. The digital asset 390 may represent a first asset value. The options for unlocking the digital asset may be specified in the locking script of the UTXO such that the unlocking script of a valid subsequent transaction must include the required inputs before the digital asset 390 can be unlocked. For example, the withdraw or revoke option 352 may require that the unlocking script of a valid subsequent transaction include the signature of the principal node 104 (e.g., ?(S)), the private key share of the node 106 (e.g.,<math num="3"><img file="JP7629479B2_D0003.tif" /></math>) and the signature of node 106 (e.g., ?(U_i)). A valid subsequent transaction that can include these inputs may correspond to a revocation transaction 252 (FIG. 2), as described herein. That is, in some examples, the commitment transaction has a transaction output that includes more than one unlocking option, including a revocation option that requires the first node's private key share, the principal node's signature, and the first node's signature, so that a valid subsequent transaction includes a transaction input along with the first node's private key share, the principal node's signature, and the first node's signature to select the revocation option.

In some implementations, the locking script of the commitment transaction 150 may include a public option 354. The public option 354 indicates that the unlocking script of a valid subsequent transaction must include the signature of the principal node 104 (e.g., ?(S)), a hash of the encrypted document (e.g., HoD), and the public option 354 must be set to 0 in order to select the public option._i), the secret key share of node 106 (e.g.<math num="4"><img file="JP7629479B2_D0004.tif" /></math>), the node private key of node 106 (e.g., q_i) and the signature of node 106 (e.g., ?(U_i)). A valid subsequent transaction that may include these inputs may be a public transaction 254 (FIG. 2) as described herein. That is, in some examples, the commitment transaction has a transaction output that includes more than one unlocking option, including a public option that requires the hash of the document, the first node's private key share, the first node's private key of the first node private-public key pair, the signature of the principal node, and the signature of the first node, so that a valid subsequent transaction includes transaction inputs along with the hash of the document, the first node's private key share, the first node's private key of the first node private-public key pair, the signature of the principal node, and the signature of the first node to select the public option.

Depending on the implementation, the locking script of the commitment transaction 250 may include a timeout option 356. The timeout option 356 determines whether the unlocking script of a valid subsequent transaction must use the signature of the principal node 104 (e.g., ?(S)) and the signature of the node (e.g., ?(U_i)). A valid subsequent transaction that may include these inputs may correspond to a timeout transaction 256 (FIG. 2). As described herein, when a node 106 does not submit either the revocation transaction 252 or the public transaction 254 within the first timelock threshold period, the principal node 104 may broadcast a timeout transaction 356 to the blockchain network after the first timelock threshold period has elapsed. The timeout transaction 356 may include an unlocking script to provide the signature of the principal node 104 and the signature of the node for the timeout option 356. That is, in some examples, a commitment transaction may have a transaction output that includes more than one unlocking option, including a timeout option that requires the signature of the principal node and the signature of the first node, such that a valid subsequent transaction includes a transaction input with the signature of the principal node and the signature of the first node to select the timeout option. Depending on the implementation, the node (U) included in the transaction input of the commitment transaction 250 may be a_i) signature (e.g., ?(U_i)) and the node included in the transaction output of commitment transaction 250 (U_i) may be based on a different private-public key pair of the node. For example,_i) may have more than one public-private key pair and may generate signatures for different aspects of the commitment transaction 250 or other transactions for the commitment channel 140.

Depending on the implementation, the commitment transaction 250 is generated by the node 106 using a double hash of the document (H(HoD_i)) (not shown in FIG. 3A ). A node 106 may generate a double hash of a document when the node 106 may submit the document to the document repository system 100. The hash function H(?) may (1) map data of any size to data of a fixed size so that the generated document can be represented in a blockchain transaction within a predetermined amount of data, or (2) prevent any node 106 from modifying a generated document that may be stored in the data store 120. Hashing the modified document may result in a different hash result, indicating that the document stored in the data store 120 has been modified.

3B illustrates an example revocation transaction 252. When forming a commitment channel 140, a node 106 may generate a revocation transaction 252. The node 106 may broadcast the revocation transaction 252 to the blockchain network in a situation where the node 106 has submitted a document to the document repository system 100 but does not intend for the document to be considered for selection by the principal node 104 or any other node 106 thereafter. In particular, the node 106 may broadcast the revocation transaction 252 to the blockchain network in a situation where the node 106 has submitted a document to the document repository system 100 but does not intend for the document to be considered for selection by the principal node 104 or any other node 106 ...<math num="5"><img file="JP7629479B2_D0005.tif" /></math>), the signature of node 106 (e.g., ?(U_i) and a transaction input 360 having the signature of the principal node 104 (e.g., ?(S)). As will be described, the principal node 104 may sign the revocation transaction 252 when the principal node 104 verifies that the revocation transaction 252 includes the mandated transaction inputs and transaction outputs of the commitment channel 140 of the principal node 104 and its respective node 106. Because the revocation transaction 252 includes the private key share of the node 106, the revocation transaction 252 may provide sufficient information that may contribute to decrypting documents submitted by other nodes 106.

The revocation transaction 252 may include a transaction output having two outputs for restricting at least two asset values. For example, the revocation transaction 252 may include outputs for restricting a second asset value 392 and a third asset value 393. Thus, the restriction on the second asset value 392 may be removed in response to the transaction input of the further transaction having a signature of the principal node (e.g., ?(S)). The restriction on the third asset value 393 may be removed in response to the transaction input of the further transaction having a signature of the principal node (e.g., ?(U_i)). The second asset value 392 may be less than the first asset value 390. Further, the third asset value 393 may be the difference between the first asset value 390 and the second asset value 392. Thus, in some examples, the second asset value 392 may be a fee when the node 106 (1) submits the generated document to the data store 120, but (2) withdraws the document from consideration by the principal node 104. The third asset value 393 may represent an unconstrained asset value that may be returned to the node 106 that broadcast the revocation transaction 252.

When a node 106 broadcasts a revocation transaction 252 to the blockchain network, the revocation transaction 252 includes the signature of the master node 104, the signature of that node 106, and the private key share of that node 106 (<math num="6"><img file="JP7629479B2_D0006.tif" /></math>), but not including the node private key of that node 106 (e.g., q_iNote that the node private key (q_i), then (1) a document encryption public key (e.g., L_i=P+Q_i) encrypted using the encrypted document (Enc_L(Doc_i) cannot be decrypted by any of the other nodes 106 because none of the other nodes 106 have the document encryption private key l_i=p+q_iBecause the node 106 cannot determine the node private key (q_i), then the document encryption private key may not be generated.

In addition, when the node 106 broadcasts the revocation transaction 252 to the blockchain network, the node 106Idiot private key share (<math num="7"><img file="JP7629479B2_D0007.tif" /></math>Note also that a shared private key (p) may be included in the transaction input. Thus, a shared private key (p) may be generated, so that q_iEach node 106 has a private-public key pair (q_i, Q_i), then q_iWhen p+q is available on the blockchain network, other nodes 106 can obtain the private document encryption key p+q_ito decrypt the encrypted document.

3C illustrates an example public transaction 254. When forming a commitment channel 140, a node 106 may generate a public transaction 254. A node 106 may broadcast a public transaction 254 to the blockchain network in the event that the node 106 submits a document to the document repository system 100 and intends to have the document considered for selection by the principal node 104 or any other node 106. By intending the document to be considered for selection, an encrypted version of the document is encrypted using the document encryption private key l._i=p+q_iThe transaction input of the public transaction 254 can be decrypted using the private key share of that node 106 (<math num="8"><img file="JP7629479B2_D0008.tif" /></math>), and the node private-public key pair (q_i, Qi)Idiot node private key (q_i), so that either the principal node 104 or the other nodes 106 can decrypt the document stored in the data store 120 as long as a threshold number of other nodes reveal their respective shares of the private key.

In particular, public transaction 254 includes the signature of the master node (?(S)), the hash of the encrypted document (HoD_i), node 106's key share (<math num="9"><img file="JP7629479B2_D0009.tif" /></math>), node 106Idiot node private key (q_i) and the signature of node 106 (?(U_i)). As will be described, the principal node 104 may sign the public transaction 254 (e.g., attribute ?(S) to the public transaction 254) when the principal node 104 verifies the commanded transaction inputs and transaction outputs for the commitment channel 140 of the principal node 104 and its respective node 106. Because the public transaction 254 includes the private key share of the node 106 as well as the node private key of the node's private-public key pair (qi, Qi) for its respective node 106, the public transaction 254 may provide sufficient information to enable decryption of the document. That is, the public transaction 254 includes the document encryption private key l_i=p+q_iThis may provide sufficient information to determine

The public transaction 254 may include a transaction output having two outputs for restricting at least two asset values. For example, the public transaction 254 may include outputs for restricting a fourth asset value 394 and a fifth asset value 395. The restriction on the fourth asset value 394 may be removed in response to the transaction input of the further transaction having a signature of the principal node (e.g., ?(S)). The restriction on the fifth asset value 395 may be removed in response to the transaction input of the further transaction having a signature of the principal node (e.g., ?(U_i)). The fourth asset value 394 may be less than the first asset value 390 (FIGS. 3A and 3B). Additionally, the fifth asset value 395 may be the difference between the first asset value 390 and the fourth asset value 394. Thus, in some examples, the fourth asset value 394 may be a reward for submitting the generated document to the data store 120 for consideration and subsequent validation by the master node 104 or any other nodes 106 participating in the document repository system 100. The fifth asset value 395 may represent an unrestricted asset value that may be returned to the node 106 that broadcast the public transaction 254.

In some examples, the document repository system 100 may be structured to encourage each node 106 to broadcast the public transaction 154 rather than broadcasting the revocation transaction 252. Thus, the fourth asset value 394 may be less than the second asset value 392 (FIG. 3B) of the revocation transaction 252 (FIGS. 2 and 3B). Note that for ease of explanation, any transaction rewards from mining/verifying nodes of a blockchain network according to a blockchain protocol (e.g., the Bitcoin protocol) are not included in the description of restricting and unrestricting digital assets.

3D illustrates an example timeout transaction 256. When forming a commitment channel 140, the principal node 104 and each node 106 may generate a timeout transaction 256. The principal node 104 may broadcast the timeout transaction 256 to the blockchain network in a situation where the node 106 broadcasts a commitment transaction 250 to the blockchain network, but the node 106 does not broadcast any valid subsequent transactions following the broadcasted commitment transaction 250. In some examples, the node 106 may not have broadcast the revocation transaction 252 or the public transaction 254 if the node 106 may have lost network communication with the blockchain network or may have gone offline.

The timeout transaction 256 may be an nLockTime-based transaction such that the principal node 104 may not successfully broadcast the timeout transaction 256 to the blockchain network before the timelock threshold has elapsed. The timelock threshold may be defined in terms of the height of a transaction block in the electronic ledger 102 (FIG. 1) or in terms of UNIX time. As an example, the timelock threshold may be a deadline for each of the nodes 106 to broadcast either the revocation transaction 252 or the public transaction 254 following the respective broadcast of the commitment transaction 250. Recall that the commitment transaction 250 may represent or be an indication of an encrypted document stored in the data store 120 (FIG. 1). That is, when the node 106 broadcasts the commitment transaction 250 to the blockchain network, the node 106 may be broadcasting the existence of that document in the document repository system 100.

When a node 106 fails to broadcast a withdrawal transaction 252 or a public transaction 254 before the first timelock threshold, the node 106 receives a secret key share (<math num="10"><img file="JP7629479B2_D0010.tif" /></math>) and the node private key (q_i) of that node 106. Failure to disclose that node's 106 private key share may prevent other nodes participating in the document repository system 100 from regenerating the joint private key (p) of the joint private-public key pair (p, P), and therefore may prevent other nodes from decrypting encrypted documents stored in the data store 120. Furthermore, failure to disclose that node's 106 node private key (q_iFailure to disclose the document encryption private key (l) may prevent other nodes participating in the document repository system 100 from decrypting the encrypted documents of that particular node 106._i=p+q_i) may be required.

The timeout transaction 256 may include a transaction output having an output for further restricting the first asset value 390 by the principal node 104. That is, the restriction on the first asset value 390 may be removed in response to the transaction input of the further transaction having the signature (e.g., ?(S)) of the principal node. In some examples, the document repository system 100 may require that the structure of the transaction output of the timeout transaction 256 restrict the first asset value 390 as a penalty for nodes 106 that do not broadcast at least one of the withdraw transaction 252 or the publish transaction 254 to the blockchain network before the first timelock threshold (s1).

In some examples, a further transaction having the principal node's signature (?(S)) may include a transaction output that distributes a portion of the first asset value to each of the other nodes 106 on behalf of each of the other nodes 106 that is not available to decrypt encrypted documents that may be stored in the data store 120. Recall that each of the other nodes 106 cannot regenerate the joint private key (p) without private key shares from at least some or a set of nodes 106.

In some examples, the nodes 106 may not broadcast the timeout transaction 256 to the blockchain network. Rather, the timeout transaction 256 may be broadcast to the blockchain network by the master node 204 if the respective node 106 fails to broadcast a publish or revoke transaction before the first timelock threshold. Because the timeout transaction 256 limits the first asset value 390 for the benefit of the master node 204, each respective node 106 may not operate to broadcast the timeout transaction 256 to the blockchain network.

Referring now to FIG. 4, FIG. 4 diagrammatically illustrates commitment channels between a principal node 204 and each of several nodes according to an example of the present application. For example, a first commitment channel 402 may be formed for Hand overode 1and the principal node 204. A second commitment channel 404 may be formed for Hand overode 2and the principal node 204. An nth commitment channel 406 may be formed for Hand overode nand the principal node 204. Each of the respective commitment channels may be associated with an encrypted document associated with the respective node and may be stored in a data store. In some examples, the number of commitment channels in a document repository system may correspond to the number of nodes participating in verifying or revealing encrypted documents stored in the data store 120 (FIG. 1). Each of the first commitment channel 402, the second commitment channel 404, or the nth commitment channel 406 may be associated with a commitment transaction, a revocation transaction, a disclosure transaction, or a timeout transaction, having functionality similar to that described herein in FIG. 2 and FIG. 3A-3D.

As will be explained, a node 106 (FIG. 1) may wish to submit one or more documents to the document repository system 100 (FIG. 1) for consideration by the principal node 104 (FIG. 1) or other nodes 106. Submitting a document to the document repository system 100 may include sending the encrypted document to the data store 120 (FIG. 1) for storage, and may include generating and broadcasting a commitment transaction to the blockchain network. In some examples, the encrypted document may not be specified or stored within a transaction that is broadcast to the blockchain network. Rather, a hash of the encrypted document (e.g., HoD_i) may be specified in a transaction that is broadcast to the blockchain network. The hash of the encrypted document may be used to broadcast to the blockchain network where the encrypted document is stored in data store 120.

Depending on the implementation, the master node 104 may generate a request transaction requesting a document submission from a node 106. The request transaction may include, among other details, a quantity of document submissions that can be received, a quantity of nodes 106 that may make document submissions, or a locking script that specifies a time-lock threshold for when (a) a submission of a commitment transaction to the blockchain network must occur (e.g., until a time-lock threshold is reached), such as a submission threshold time (s0); and (b) a first threshold time (s1) for when a submission of a subsequent valid transaction (e.g., revocation transaction 252 or publication transaction 254) must be broadcast. In some examples, the submission threshold time (s0) may be implemented such that the document repository system 100 may receive the encrypted document from the participating node for storage before proceeding with the operation to decrypt the encrypted document. In some examples, the request transaction may include a time-lock threshold for when a commitment transaction must be submitted to the blockchain network (e.g., until a time-lock threshold is reached), such as a submission threshold time (s0); and (b) a first threshold time (s1). In some examples, the submission threshold time (s0) may be implemented such that the document repository system 100 may receive the encrypted document from the participating node for storage before proceeding with the operation to decrypt the encrypted document. In some examples, the request transaction may include a time-lock threshold for when a commitment transaction must be submitted to the blockchain network (e.g., until a time-lock threshold is reached), such as a submission threshold time (s1). For example, if the document repository system 100 is based on the Bitcoin protocol, an elliptic curve (secp256k1 ECDSA) with the following parameter set may be used: G-base point on an elliptic curve of degree q: q?G=0, and q=a large prime number.

Depending on the implementation, the secret sharing protocol may be implemented to distribute n key shares to n nodes when the n nodes may submit one or more documents to the document repository system 100. As described herein, the n key shares may be used to generate a joint private key (p) associated with a joint public key (P) of a joint private-public key pair (p, P). Depending on the implementation, the joint private key shares may be distributed by a trusted dealer node. When the trusted dealer node distributes the joint private key shares, the trusted dealer node may be the principal node 104 and may have knowledge of the joint private key to generate the joint private key shares for the participating nodes.

In some other implementations, the joint secret key shares may be distributed based on a dealerless protocol, in which a particular node has no prior knowledge of the joint secret key shares, and the protocol may require at least t+1 of the n key shares to generate the joint secret key (p). When a polynomial-based secret sharing protocol is used, "t" may be the degree of the polynomial. The dealerless protocol may require the n nodes to jointly generate and verify their respective joint secret key shares.

In some example implementations, the threshold t+1 may be t?Z:0&lt;t?n-1, where t may be an amount such that t+1?n. Example implementations in which the threshold t+1?n is used may be useful in scenarios in which one or more nodes 106 may have broadcast a commitment transaction 250, but then a particular node 106 may have disconnected its network communication channel with the blockchain network such that it does not broadcast a subsequent valid transaction from its respective commitment channel 140. Note that setting the threshold t+1?n may improve the scenario for the participating nodes 106 to regenerate the joint private key (p) even when one or more nodes have disconnected their network communication channel with the blockchain network. Note that in example implementations in which the threshold may be t+1?n, the encrypted document in the data store 120 may be decrypted before the entire set of nodes 106 broadcasts either the revocation transaction 252 or the public transaction 254 to the blockchain network. Thus, when the encrypted documents in data store 120 may be decrypted before the entire set of nodes 106 broadcasts either the revocation transaction 252 or the public transaction 254 to the blockchain network, nodes 106 that have not yet broadcast either the revocation transaction 252 or the public transaction 254 may reveal the contents of other encrypted documents in data store 120 and, based on such disclosure, may broadcast either the revocation transaction 252 or the public transaction 254 before the lapse of the first timelock threshold.

In some example implementations, the document repository system 100 may utilize a secret sharing protocol that utilizes an n+r threshold, such that n+r key shares may be required to generate the joint private key (p) of a joint private-public key pair (p, P). An additional r private key shares may be distributed to the principal node 104 or other trusted third parties. However, when using a secret sharing protocol with an n+r threshold, retrieving the n private key shares from the blockchain may not be sufficient to generate the joint private key (p) to verify the integrity of or reveal the encrypted documents in the data store 120.

In some example implementations, the nodes 106 of the document repository system 100 may perform operations of a Publicly Verifiable Secret Sharing (PVSS) protocol. It may be desirable for each node to be able to verify that it has been assigned the correct secret key shares. Key share verification may be used to allow nodes to verify their own key shares as well as the key shares of other nodes.

An exemplary PVSS protocol is described in "Publicly verifiable secret sharing", by Stadler, M [Stadler], International Conference on the Theory and Applications of Cryptographic Techniques (Springer Berlin Heidelberg), May 1996, pages 190-199.

In the example PVSS protocol, each node U_iis the corresponding public cryptographic function E_iA decryption function D that allows access to the information encrypted with_iIn this way, the dealer node may distribute key shares using a public cryptographic function and publish them in the following format:_i=E_i(k_i), i=1,...,n

The encrypted shares can be publicly verified by interested nodes: nodes can verify their own key shares and can verify that other nodes received the correct key shares, i.e., whether the dealer node was honest.

The main (high-level) components of the PVSS protocol include: (i) Secret sharing: The dealer node uses the algorithm Share(k) = (k₁,...,k_n) to compute the shares and distribute them among the participating nodes.

(ii) Reconstruction: The participant node_i(K_iThe secret can be reconstructed by running the algorithm Recover such that {i|i?A})=k.

(iii) Verify: The algorithm PubVerify may be used to verify the encrypted share. If a node_i|i?A})=1&gt;Recover({D_i(K_iIf we operate such that {i?A}=u and u=k, then the dealer node may be determined to be honest and the key agreement may be consistent.

In some implementations, the PVSS scheme can be interactive or non-interactive depending on the needs during the recovery phase.

Various implementations of the PVSS protocol based on several cryptosystems may be considered. As an example, the following highlights the protocol described in the publication "A simple publicly verifiable secret sharing scheme and its application to electronic voting" by Schoenmakers, B., published in August 1999 at the Annual International Cryptology Conference (Springer Berlin Heidelberg), pages 148-164.

In the early stages, using public procedures,_qand two independently selected generators G and g. Each node may then determine its private key<math num="11"><img file="JP7629479B2_D0011.tif" /></math>Given the public key,<math num="12"><img file="JP7629479B2_D0012.tif" /></math>may be set.

The dealer node then_qRandom polynomials of degree up to t-1 with coefficients<math num="13"><img file="JP7629479B2_D0013.tif" /></math>You can set a₀Set =k. Commitment<math num="14"><img file="JP7629479B2_D0014.tif" /></math>and the encrypted share f(i) (using the participant's public key).<math num="15"><img file="JP7629479B2_D0015.tif" /></math>may be made public.

<math num="16"><img file="JP7629479B2_D0016.tif" /></math>By computing<math num="17"><img file="JP7629479B2_D0017.tif" /></math>We can generate a proof of knowledge of f(i) by showing that

Verification of the key shares can be performed using the Fiat-Shamir cryptography technique in Stadler cited above. The main steps of the non-interactive protocol include: A prover (every node) may choose a random wi ? Zq;<math num="18"><img file="JP7629479B2_D0018.tif" /></math>may be calculated and the value may be broadcast.

?c=H(X_i,Y_i,a_1i,a_2i) (where H() is a cryptographic hash function), the prover (e.g., a node) can_i=w_i-f(x_i)c and broadcast it.

Given ri and ci, the verifier<math num="19"><img file="JP7629479B2_D0019.tif" /></math>_iYou may prove that the hash of (1?i?n) of matches c.

When necessary, a participant node can share f(x_i), the secret s can be reconstructed without having to learn anything about it. The required information is<math num="20"><img file="JP7629479B2_D0020.tif" /></math>The secret is computed via Lagrange interpolation.

<math num="21"><img file="JP7629479B2_D0021.tif" /></math>

The above example utilizes a dealer node to compute and distribute key shares. However, it is conceivable that a dealerless implementation of the secret sharing protocol may be implemented, as described by the Fiat-Shamir heuristic technique (see, for example, "Fiat-Shamir heuristic", https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic (accessed February 26, 2018)).

As described, in some implementations, the nodes 106 may perform the operations of a secret sharing protocol. A set of nodes may jointly generate a joint public key (P), where P=pG, where G may be a selected base point of an elliptic curve, and p may be a joint private key (p).

As described, the nodes and the master node may form respective commitment channels based on the generation of one or more transactions and broadcasting the commitment transactions to the blockchain network. To illustrate the formation of an example commitment channel, refer to FIG. 5. FIG. 5 shows a sequence diagram 500 of transactions exchanged between the node 206 (FIG. 2), the master node 204 (FIG. 2), and an electronic ledger 502 according to an example of the present application. The electronic ledger 502 may be a component of a blockchain network. For ease of explanation, in some examples, the blockchain network may be used to refer to the electronic ledger 502. The sequence diagram 500 may show an example formation of the commitment channel 140 illustrated in FIG. 2.

At operation 502, node 206 may generate commitment transaction 250 (FIG. 2) having a commitment transaction output locked by the private key share of node 206 such that a valid subsequent transaction having the commitment transaction output as an input includes the private key share of node 206. In some examples, commitment transaction 250 may be similar to commitment transaction 250 of FIG. 3A.

At operation 502, node 206 may also send commitment transaction 250 to principal node 204. By generating and sending commitment transaction 250 to principal node 204, node 206 may indicate to principal node 204 that node 206 is submitting the document to document repository system 100. Additionally, at operation 502, node 206 may send the encrypted document to data store 120 (FIG. 1) for storage. Data store 120 may be publicly accessible such that nodes 106 and principal nodes of document repository system 100 may access the encrypted document stored therein, but node 106 or principal node 104 may only access the document encryption private key (_i=p+q_i), where p is a shared secret key based on a set of shared secret key shares distributed to the nodes 106, and q_iis the node private key associated with the encrypted document.

In some examples, the commitment transaction 250 may be hashed, and the node 206 may transmit the hash of the commitment transaction 250 to the principal node 204. In some implementations, the hash of the commitment transaction 250 may be an identifier ("ID") to reference the commitment transaction 250. For example, the ID may be included in the revocation transaction 252, the publication transaction 254, or the timeout transaction 256 to identify the corresponding commitment transaction 250. In some examples, the hash of the commitment transaction 250 may (1) map the commitment transaction 250 to a fixed data size, and/or (2) help detect subsequent modifications of the commitment transaction 250, since hashing a modified document may result in a different hash result. Either the principal node 204 or the node 106 may utilize the predicted hash result to determine whether the commitment transaction 250 may have been modified.

At 504, the node 206 may generate a valid subsequent transaction. The valid subsequent transaction may be a revocation transaction 252 similar to that illustrated in FIG. 3B. The revocation transaction 252 may include a transaction input having the node's 206 private key share and the node's 206 signature. At 504, the node may also send the revocation transaction 252 to the principal node 204.

At 506, the principal node 204 may verify that the revocation transaction 252 includes the ordered transaction inputs and transaction outputs for the commitment channel 140. For example, the principal node 204 may verify that the revocation transaction 252 includes at least the hash of the node 206 or the desired input or output asset values. In some examples, the node 206 may still have its respective private key shares (<math num="22"><img file="JP7629479B2_D0022.tif" /></math>), the principal node 204 may not have provided the signature of the principal node 252 to the node 206. Once the principal node 204 verifies that the revocation transaction 252 includes the ordered transaction inputs and transaction outputs, the principal node 204 may append or concatenate the principal node's signature (?(S)) to the revocation transaction 252 and send the signed revocation transaction to the node 206. In some examples, the principal node 204 may append or concatenate the principal node's signature without having knowledge of the node 206's private key share. That is, at 506, the principal node 204 may have configured the revocation transaction 252 such that it may then be broadcast to the blockchain network.

Note that the exchange of the Grindingnsignedand principal-signed revocation transactions occurs Climbffthe blockchain. A node 206 may broadcast a principal-signed revocation transaction 252 to the blockchain network at a later time if the node 206 wishes to withdraw a document associated with the node 206 from consideration by the principal node 204 or other nodes of the document repository system 100. The revocation transaction 252 may be broadcast to the blockchain network at a later time if the node 206 wishes to withdraw a document associated with the node 206 from consideration by the principal node 204 or other nodes of the document repository system 100. The revocation transaction 252 may be transmitted to the blockchain network using the node 206Idiot private key share (<math num="23"><img file="JP7629479B2_D0023.tif" /></math>), when the revocation transaction 252 is broadcast to the blockchain network, the revocation transaction 252 may reveal the private key share of that node 206 on the blockchain, so that each node can revoked the encrypted document Enc_L(Doc_iNote that a set of private key shares can be retrieved from the blockchain to generate a joint private key (p) that can be used in combination with a node private key (qi) to decrypt the

At 508, the node 206 may generate a public transaction 254, similar to that shown in FIG. 3C. For example, the public transaction 254 may be another example of a valid subsequent transaction as described above. The public transaction 254 may include a hash of a document (HoD) associated with the node 206._i), node 206's shared secret key (<math num="24"><img file="JP7629479B2_D0024.tif" /></math>), a node private key (q_i) and a transaction input having the signature of node 206.

At 510, the principal node 204 may verify that the public transaction 254 includes the transaction inputs and transactions outputs as ordered for the commitment channel 140. For example, the principal node 204 may verify that the public transaction 254 includes at least the signature of the node 206 or the desired input-output asset values. In some examples, the node 206 may verify that the public transaction 254 includes at least the signature of the node 206 or the desired input-output asset values._i), node 206's shared secret key (<math num="25"><img file="JP7629479B2_D0025.tif" /></math>) or a node private key (q_i) to the node 206. Once the principal node 204 verifies that the public transaction 254 contains the ordered transaction inputs and transaction outputs, the principal node 204 may append or concatenate the principal node's signature (?(S)) to the public transaction 254 and send the signed public transaction to the node 206. In some examples, the principal node 204 may also send a hash of the document (HoD_i), node 206's shared secret key (<math num="26"><img file="JP7629479B2_D0026.tif" /></math>) or a node private key (q_i), the principal node's signature may be appended or concatenated without the knowledge of the principal node 204. That is, at 510, the principal node 204 may have set up the public transaction 254 so that it may then be broadcast to the blockchain network.

Note that the exchange of the "unsigned" and master signed public transactions occurs "off" the blockchain. Node 206 may broadcast the signed public transaction 254 to the blockchain network at a later time if Node 206 wishes to publish the encrypted document in a data store for consideration by master node 204 or other nodes participating in document repository system 100. When node 206 broadcasts public transaction 254 to the blockchain network, node 206 may register node 206's private key share (<math num="27"><img file="JP7629479B2_D0027.tif" /></math>) and the node private key (q_i) to clarify.

In some implementations, node 206 may require that at least one valid subsequent transaction (e.g., revocation transaction 252 or public transaction 254) be signed by principal node 204 before broadcasting commitment transaction 250 to the blockchain network. By refraining from broadcasting node 206's commitment transaction 250 to the blockchain network until at least one of the principal-signed revocation transaction 252 or the principal-signed public transaction 254 is received, node 206 may be assured that a portion of first asset value 390 (FIG. 3A) may be returned if at least one of the principal-signed revocation transaction 252 or the principal-signed public transaction 254 is broadcast to the blockchain network before the first timelock threshold (s1).

In the examples described herein, because at least one valid subsequent transaction may need to be primary signed before the restriction is removed on the third asset value 393 (FIG. 3B) or the fifth asset value 395 (FIG. 3C), a node 206 may refrain from broadcasting its commitment transaction 250 until a valid subsequent transaction that has been primary signed is received. When the commitment transaction 250 is broadcast to the blockchain network, the node 206 may use its private key share (<math num="28"><img file="JP7629479B2_D0028.tif" /></math>) to their respective sets of private key shares. In some implementations, the revocation transaction 252 may be signed by the principal node 204 before the public transaction 254, or vice versa. In some examples, the node 206 may prefer that the public transaction 254 be signed by the principal node 204 before any other valid subsequent transactions, at least because the fifth asset value 395 is likely to be greater than the third asset value 393. In some implementations, the revocation transaction 252 may be signed by the principal node 204 substantially simultaneously with the public transaction 254.

When node 206 does not submit either revocation transaction 252 or signed public transaction 254, as described herein, principal node 204 may broadcast timeout transaction 256 (FIG. 3D) to the blockchain network. Timeout transaction 256 may include a transaction output having an output to limit first asset value 390 for the benefit of principal node 204. In the situation where node 206 broadcasts commitment transaction 250 to the blockchain network to indicate that node 206 may wish to submit the document to document repository system 100, but node 206 fails to follow up by broadcasting either signed revocation transaction 252 or signed public transaction 254 before the first threshold time (s1), principal node 204 may remove the limit on first asset value 390. In this case, first asset value 390 may be represented in the blockchain by node 206's private key share (<math num="29"><img file="JP7629479B2_D0029.tif" /></math>) may be a penalty to node 206 for not disclosing the

In some implementations, either node 206 or principal node 204 may generate the timeout transaction 256. However, principal node 204 may use the timeout transaction 256 to penalize node 206 for not revealing its private key share in the blockchain. Thus, in operation 512, principal node 204 may generate the timeout transaction 256. The timeout transaction 256 may be similar to that illustrated in FIG. 3D and may include a transaction input with the signature of principal node 204.

At 514, the node 206 may verify that the timeout transaction 256 includes the ordered nLockTime-based transaction, and upon verification, the node 206 may generate a signature (?(U_i)) may be appended or concatenated to the timeout transaction and the signed timeout transaction may be sent to the principal node 204.

Additionally, the timeout transaction 256 may include a transaction output that includes a restriction on the first asset value 390 for the benefit of the principal node 204. When the timeout transaction 256 is broadcast to the blockchain network, the restriction on the first asset value may be removed in response to the transaction input of the further transaction having the signature of the principal node (?(S)). Note that the timeout transaction 256 is held from being successfully broadcast and verified on the blockchain network until a first timelock threshold (s1) has elapsed. In some implementations, the operation to form the commitment channel 140 may include the node 206 broadcasting the signature of the node (?(U_i)) to the timeout transaction 256.

In some implementations, once the timeout transaction 256 is successfully broadcast and verified on the blockchain network, the unconstrained first asset value 390 may be distributed to the other nodes 206 as compensation or redress for a lost opportunity to generate a joint private key based on the set of private key shares. Each of the other nodes 206 may then distribute the document encryption private key l_i=p+q_iRecall that each node publishes its own private key share on the blockchain, relying on all other nodes 206 to generate a joint private key (p) to assemble the document encryption private key._iThis may be used to decrypt encrypted documents originating from

In some implementations, the timeout transaction 256 signed by both the node 206 and the principal node 204 may be stored in the data store 120, such that a plurality of nodes 106 for the document repository system 100 (FIG. 1) may note that each of the nodes 106 in the plurality of nodes may be subject to a penalty if each node 206 fails to (1) broadcast the commitment transaction 250 to the blockchain network and (2) broadcast at least the revocation transaction 252 or the publication transaction 254 signed by the principal node 204 before the first timelock threshold (s1).

At 516, the node 206 may broadcast the commitment transaction 250 associated with the node 206 to the blockchain network. When the commitment transaction 250 is broadcast to the blockchain network, the commitment channel 140 may be formed. Based on at least the examples above, the node 206 and the lead node 204 may perform operations 502 through 516 described herein to form the commitment channel 140.

Further, to ensure that node 206 is not penalized by a value equal to first asset value 390 (FIG. 3A), at 518 node 206 may broadcast either revocation transaction 252 or public transaction 254 to the blockchain network prior to a first timelock threshold (s1).

Referring to FIG. 6, FIG. 6 illustrates in flow chart form a method 600 implemented at a node 106 (e.g., a first node=node i) of FIG. 1 to submit a document to the document repository system 100 (FIG. 1) according to one example of the present application. The method 600 may include operations that may be performed by one or more processors of the node 106 of the blockchain network. The method 600 may be performed by the node 106 to submit a document to the document repository system 100 for consideration by the master node 104 (FIG. 1) or by any other nodes participating in the document repository system 100.

At operation 610, the processor determines secret key shares (p) based on the operation of a threshold secret sharing protocol to distribute or assign secret key shares to each node in the document repository system 100.^{^}_i) may be retrieved. Examples of threshold secret sharing protocols include the above-mentioned Shamir's method, although other methods similar to threshold secret sharing protocols are contemplated. As explained, the joint private key (p) of a joint private-public key pair (p, P) may be retrieved from an encrypted document Enc_L(Doc_i) document encryption private key (l_i=p+q_i) may be used to generate

At operation 620, the processor generates a node private-public key pair (q_i, Q_i) may be calculated. The calculated node private-public key pair may be used as a "one-time code". For example, the node public key (Q_i) is the document encryption public key (L_i=P+Q_i) may be used to generate the node private key (q_i) may be broadcast via a public transaction 254 (FIG. 2). Thus, once the node private key is made public to the blockchain network, the node 106 may refrain from using the node private-public key pair for future cryptographic operations within the document repository system 100.

At operation 630, the processor derives a document encryption public key (L_i=P+Q_iIn some examples, the processor may generate a document encryption public key by combining the community public key (derived via the operation of a threshold secret sharing protocol) with the node public key of the node 106.

In operation 640, the processor may encrypt the document that the node 106 is tasked to submit to the document repository system 100. The encrypted document may be stored in the data store 120. Any of the nodes in the document repository system 100 may access the data store 120 to retrieve the encrypted document stored therein. However, the node cannot find the content of any one of the encrypted documents until the document of interest is decrypted with the document encryption private key. The document encryption private key includes a combination of the joint private key and the node private key associated with the document of interest. The node 106 may generate the joint private key (p) once a threshold number of nodes participating in the document repository system 100 reveal their respective private key shares on the blockchain via a revocation transaction 252 or a publication transaction 254. In some examples, the encrypted document may not be recorded via a transaction broadcast to the blockchain network. Rather, the document or a hash of the encrypted document may be recorded in one or more transactions described herein that may be broadcast to the blockchain network.

In operation 650, the processor may generate one or more transactions for the first commitment channel 140 (FIG. 1). In an example implementation, the processor may generate one or more transactions for the first commitment channel 140 of the node 106 based on the operations illustrated by the sequence diagram 500 of FIG. 5. The first commitment channel 140 may be determined to be formed in subsequent operations when the commitment transaction 250 (FIG. 2) is generated, when at least one of the revocation transaction 252 or the publication transaction 254 is signed by the principal node 204 (FIG. 2), and when the commitment transaction 250 is broadcast to the blockchain network. In some example implementations, the commitment channel 140 may be formed when each of the transactions described by FIG. 5 is generated and signed by the node 106 and by the principal node 104, and when the commitment transaction 250 is broadcast to the blockchain network.

At operation 660, in response to receiving a valid revocation transaction or a publication transaction signed by the principal node, the processor may broadcast the commitment transaction 250 to the blockchain network such that the commitment transaction 250 may be verified by mining nodes of the blockchain network. In some examples, when the processor broadcasts the commitment transaction 250 to the blockchain network, the processor forms a commitment channel 140. In some implementations, broadcasting the commitment transaction 250 to the blockchain network may be similar to submitting a document of node 106 to document repository system 100 for consideration by the principal node or other nodes in the document repository system 100.

The processor may refrain from broadcasting the commitment transaction 250 to the blockchain network until such time as a valid revocation or publication transaction is signed by the principal node 104. As described herein, the revocation or publication transaction may include a transaction output to remove a restriction on at least a portion of the first asset value 390 (FIGS. 3B, 3C) such that at least a portion of the first asset value 390 may be returned as a UTXO to the node 106 in lieu of the node 106's private key share contribution to the set of private key shares.

In some examples, if the processor does not receive a valid revocation transaction or a public transaction signed by the principal node, the processor may stop forming the commitment channel, and the processor may avoid broadcasting the commitment channel to the blockchain network.

Upon indication by node 106 via broadcast of a commitment transaction that the processor may be submitting a document for consideration in document repository system 100, in operation 670, the processor may broadcast a revocation transaction or a public transaction to the blockchain network before a first timelock threshold (s1). The first timelock threshold (s1) may be established by the master node or any other node of document repository system 100. The first timelock threshold may be set to govern the time period for document submission and private key share submission by each node to document repository system 100.

The processor may broadcast a public transaction to the blockchain network if the node intends for the document to be considered. The document may be considered by the master node or any other node in the system for selection. For example, the document may be a submission to a contest managed by the document management system 100. In some other examples, the document may be a legal document submission to a court managed by the document management system 100, where a deadline for legal document submission may be set by statute. In other examples, the document may be a bid submission to an agency for the award of an infrastructure project managed by the document management system 100. By limiting the publication of document contents to when a temporal time threshold has passed, the bidding process may facilitate bid submissions that may result in a competitive process (e.g., best cost, etc.).

In some examples, the processor may broadcast a revocation transaction to the blockchain network if the node intends to remove the document from consideration, but intends to reveal the node's private key shares so that the necessary set of private key shares can be collected to generate a joint private key (p) for decrypting the document. Note that a node may be motivated to broadcast a revocation transaction to the blockchain network rather than simply broadcasting any valid subsequent transactions because, at a minimum, broadcasting a revocation transaction (1) exposes the node's private key shares on the blockchain and (2) limits a portion of the first asset value for the node's benefit. If the node simply did not broadcast any valid subsequent transactions, the first asset value would be limited (via broadcast of a timeout transaction by the principal node) for the benefit of the principal node or each of the other nodes participating in the document repository system 100.

Referring to Figure 7, Figure 7 illustrates in flow chart form a method 700 implemented at a node 106 (e.g., first node = node i) of Figure 1 for verifying a document submitted to the document repository system 100 (Figure 1) according to an example of the present application. The method 700 may include operations that may be performed by one or more processors of the node 106 of the blockchain network. The method 700 may be performed by the node 106 to verify a document previously submitted to the document repository system 100.

At operation 710, the processor_i) or encrypted document Enc_L(Doc_i) from the blockchain. The set of private key shares may be<math num="30"><img file="JP7629479B2_D0030.tif" /></math>), where each private key share in the set is associated with its respective document (Doc_i), based on public or revoked transactions broadcast on the blockchain network by each node participating in validating the

At operation 720, in response to determining that the amount of the private key shares is greater than the private key share threshold, the processor may<math num="31"><img file="JP7629479B2_D0031.tif" /></math>From the retrieved set of , the nodes may generate a joint private key (p) of a joint private-public key pair (p, P). In some examples, where n nodes may participate in verifying documents submitted to the document repository system 100, the private key sharing threshold may be n private key shares. That is, to allow either node 106 or the principal node 104 to verify a document in the data store 120 (FIG. 1), each of the n participating nodes must have at least n of their respective private key shares.<math num="32"><img file="JP7629479B2_D0032.tif" /></math>must be revealed on the blockchain. If one or more of the n nodes fails to reveal their respective private key shares (e.g., via a revocation transaction or broadcast of a public transaction), the processor must reveal the document encryption private key (_i=p+q_i), none of the n nodes may be available to generate a joint private key (p) for generating the n nodes' respective private keys. If one or more of the n nodes fails to disclose their respective private keys, then none of the nodes 106 participating in the document repository system 100 may be able to decrypt the encrypted documents stored in the data store 120. That is, none of the nodes may be able to decrypt and verify the encrypted documents without the cooperation/contribution of a private key share from each of the n nodes.

In some examples, where n nodes are participating in verifying documents submitted to the document repository system 100, the secret key sharing threshold may be less than the number of nodes participating in the document repository system 100. Thus, if one or more of the n nodes fail to reveal their respective private keys, but the amount of the secret key shares is greater than the secret key sharing threshold, the processor may determine whether the document encryption private key (_i=p+q_i), in order to generate a shared private key (p) for generating the first time-lock threshold (s1). In some implementations, it may be desirable to provide a private key sharing threshold that is less than the number of nodes participating in the document repository system 100 to account for nodes that may lose connection to the blockchain network and to account for a limited number of nodes that may not be able to broadcast public or revoked transactions before the first time-lock threshold (s1).

In some examples, if the processor fails to retrieve the necessary amount of private key shares above the private key share threshold from the blockchain before the first timelock threshold (s1), the processor may be unable to decrypt encrypted documents stored in data store 120, at least because the joint private key may not have been generated. In such a situation, depending on the implementation, principal node 104 (FIG. 1) may broadcast a timeout transaction 256 (FIG. 2) to the blockchain network, and the restriction on first asset value 390 (FIG. 3D) may be removed and then included in a locking script for principal node 104 or other nodes in document repository system 100.

If the processor can generate a joint secret key from the set of retrieved secret key shares, then in operation 730, the processor: (1) generates a document encryption private key (_i=p+q_i), and (2) generate the encrypted document (Enc_L(Doc_i)) may be decoded.

In some implementations, the processor hashes the decrypted document (e.g., H(?)) and multiplies the hash of the document (H(Doc_iOnce the required number of private key shares have been revealed to the blockchain, any of the nodes 106 in the document repository system 100 may then perform operations to verify (1) a joint private key generated from the set of private key shares and (2) the document (Doc_i)_iThe node private key (q_i) to generate an encrypted document (Enc_L(Doc_iNote that in some implementations, each node participating in document repository system 100 may perform operations to (1) decrypt the encrypted document, (2) hash the decrypted document, and (3) verify that the hash of the decrypted document corresponds to the hash of the document retrieved from the broadcasted commitment transaction associated with the node that originated the document.

Reference is now made to Figure 8, which illustrates in block diagram form a simplified node 800 according to one example of the present application. The node 800 includes a processor 802, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The node 800 may further include memory 804, which may include persistent and non-persistent memory for storing values, variables, and in some examples, processor-executable program instructions, and a network interface 806.

The node 800 may include a processor-executable blockchain application 808 that includes processor-executable instructions that cause the processor 802 to perform one or more of the functions or operations described herein.

The above-described embodiments are illustrative rather than limiting of the invention, and it will be appreciated that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the scope of the claims. The words "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "including or consisting of" and "comprising" means "including or consisting of". A singular reference of an element does not exclude a plural reference of such element and vice versa. The invention may be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.