System and method implemented by a computer for time-release encryption on a blockchain network

Abstract

To provide a method and system for generating a public encryption key on a block chain network and enabling access to a corresponding private encryption key after a specified time period.SOLUTION: A digital time-locking contract between an agent and a client on a block chain network specifies a first encryption asset from the agent and a second encryption asset from the client, and the first encryption asset and the second encryption asset are configured by a necessary signature and a time-lock puzzle value that can be derived from a cryptographic private key so as to be transferable to a set address after a set time.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This specification generally relates to digital time lock contracts for time release encryption. The present invention is particularly suitable for use with, but not limited to, the Bitcoin blockchain.

Background Art

[0002] As used herein, the term "blockchain" is used to include any form of electronic, computer-based, distributed ledger. These include consensus-based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Bitcoin is mentioned herein for convenience and illustrative purposes only, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks. Also, a block is composed of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants within the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and the blocks together form a chain, generating a permanent and immutable record of all the transactions written to the blockchain from its inception. Transactions include a small program known as a script that is incorporated into their inputs and outputs. The script specifies how and by whom the outputs of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "verified". Some network nodes function as miners and perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on a node performs this verification work on transactions that reference unspent transaction outputs (UTXOs). Verification may be performed by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true and certain other conditions are met, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, the transaction must: i) be verified by the node that received the transaction, and if the transaction is verified, the node relays the transaction to other nodes within the network; ii) be added to a new block constructed by the miner; and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain such that the transaction is effectively irreversible.

[0005] Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both Bitcoin-based cryptocurrency security systems and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if the blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions can leverage the advantages of the blockchain (e.g., permanent, tamper-resistant records of events, decentralized processes, etc.) while being more diverse in their applications.

[0006] One area of research is the use of blockchain for the implementation of "smart contracts". These are computer programs designed to automate the execution of machine-readable transactions or the terms of an agreement. Unlike conventional transactions that can be described in natural language, smart contracts are machine-executable programs that contain rules for processing inputs to produce results and can execute actions depending on those results.

[0007] Another area of interest related to blockchain is the use of "tokens" (or "colored coins") for the representation and transfer of real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no identifiable meaning or value. Thus, tokens function as identifiers that enable real-world items to be referenced from the blockchain.

[0008] As noted above, this specification is generally related to digital time lock contracts for time release encryption. The basic purpose of time release encryption is that a message can be encrypted at the present time but cannot be decrypted by anyone until some specified future time. This is effectively a way of "sending a message into the future" or putting a message in a "time capsule". There are many possible uses for this type of functionality, including the following. · Sealed bid auctions · Key escrow · Voting without a receipt · Time release of confidential data · "Dead man devices" for politically sensitive information

[0009] There are two general approaches for implementing a time release encryption system, which were outlined in the first detailed paper on the idea by Rivest, Shamir, and Wagner in 1996 [Rivest1996]. These are as follows. 1. Use of a "time-lock puzzle". Encryption of information that requires time-consuming computational operations to decrypt. 2. Use of a trusted agent that promises not to disclose the secret information until a specified future time.

[0010] The former of these approaches does not require the involvement of a third party but has two serious and inevitable drawbacks. That is, first, due to performance differences in computing hardware and unknown future technological innovations, it is impossible to accurately predict how long it will take to solve a specific puzzle. Second, the party performing the decryption must perform continuous high-cost computational operations throughout the time-lock period.

[0011] The latter approach has the potential to be accurate and precise at the time of disclosure and does not require any party to perform expensive computations. However, it relies on a third-party agent that must be trusted to publish the correct key at the correct time. Trust in the agent is therefore critical unless the agent is effectively incentivized to perform correctly.

[0012] Background information regarding time-lock encryption on blockchain networks is summarized below.

[0013] "Ethereum Alarm Clock" provides that a user can execute a transaction during a scheduled time period after providing a deposit. See, for example, the following URLs: docs.ethereum - alarm - clock.com / en / latest / claiming.html#claim - deposit; and https: / / github.com / pipermerriam / ethereum - alarm - clock / commits / master / docs / claiming.rst. This enables the scheduling of events at a later point in time and during a specific time window. Further, the depositor can retrieve the deposit, but may lose the deposit if the execution does not occur within the specified time window. Payments are also included in the service that are made to the account that executes the transaction at the scheduled time.

[0014] "μchain: How to Forget without Hard Forks" (URL: https: / / eprint.iacr.org / 2017 / 106.pdf) discloses an example of time - locked encryption. In the disclosed use case, a user encrypts a confidential document. The decryptor requests access to the decryption key by sending a transaction to a smart contract that triggers a function to check whether the expiration time t has passed. If the time is correct, the decryptor obtains the key. It is proposed that the system can provide a more advanced function that makes the decryption key available only if requested within a specific time window.

[0015] "Secure Multiparty Computations on Bitcoin" (URL: https: / / eprint.iacr.org / 2013 / 784.pdf) discloses a protocol for multi-party lottery using the Bitcoin currency. This document shows that the Bitcoin system provides an attractive way to construct a version of timed commitments where the committer has to expose his secret within a specific time frame or pay a fine. Deposits are provided by participants who will have their deposits confiscated if the game ends prematurely by a participant acting dishonestly.

[0016] US2016086175 discloses a blockchain system for accessing assets. A room has a secret / public key pair along with an address where credit is deposited by a user who wishes to rent the room for a specific period, and this data is included in a transaction. When the time is right, it is unlocked and the user is permitted to enter the room. If the room is not available during the requested time, the user pays a fee to the provider of the room to obtain access to a refunded room. Summary of the Invention

[0017] This specification describes a system and method that enables secure time-release encryption services using a permissionless public blockchain. The service generates a public key and then publishes a private key corresponding to a future time specified by a client of the service. The security and reliability of this service are obtained from a novel smart contract system and implemented, for example, as Bitcoin Script. This encourages the private key to be published at the correct time and disadvantages early or late publication or key leakage. The service is a non-trust design. That is, clients are not given access to the private key, but they only provide the encrypted assets of the service with the guarantee that the correct value will be published on the blockchain at the time specified within the contract. In one example, this is achieved by zero-knowledge proofs combined with time locks and hash locks of transaction outputs.

[0018] According to a first aspect of the present invention, a computer-implemented method for generating a public encryption key on a blockchain network and enabling access to a corresponding private encryption key after a specified time period, the method comprising: Configuring a digital time lock contract between an agent and a client on the blockchain network, wherein the agent has an agent signature associated with an agent address on the blockchain network, the client has a client signature associated with a client address on the blockchain network, and the digital time lock contract comprises: (i) the agent holding the private encryption key corresponding to the public encryption key on the blockchain network and then publishing the encryption secret to the blockchain network within a specified time window; (ii) The agent provides a first encrypted asset (e.g., a deposit) for holding, and then publishes the encryption secret key to the blockchain network within the specified time window. The first encrypted asset is transferable to the agent address on the blockchain network when the encryption secret key is published to the blockchain network within the specified time window. (iii) The client provides a second encrypted asset (e.g., a fee) to the agent for holding, and then publishes the encryption secret key to the blockchain network within the specified time window. The second encrypted asset is transferable to the agent address on the blockchain network when the encryption secret key is published to the blockchain network within the specified time window. (iv) If the encryption secret key is published before the start of the time window, the second encrypted asset is transferable to the client address on the blockchain network (the client or someone else may use the secret key to capture the agent's first encrypted asset). (v) If the encryption secret key is not published before the end of the time window, the second encrypted asset is transferable to the client address on the blockchain network (the first encrypted asset may also be transferable to the client address on the blockchain network). Steps that specify For mining on the blockchain, the step of broadcasting the digital time lock contract to the blockchain network A computer-implemented method is provided that includes one or both of

[0019] The steps of constructing the digital time lock contract and broadcasting the contract may be executed by the same entity. However, it is also conceivable that these steps may be executed by different entities. Here, the foregoing definition designates one or both of the steps required by any single entity.

[0020] It should be noted that the present invention described herein does not only provide a time lock contract implemented on a blockchain as a better way to conduct business. The starting point of the present invention is that it is known to implement a time lock contract using an encryption method. However, these conventional systems have technical problems. The technical problems associated with the prior art are that they are not secure, or their use may be difficult and computationally intensive. These problems are inherently technical. The present invention provides a secure, easy-to-use, and computationally efficient solution. That is, the present invention provides a better computer system from the perspective of providing a system that combines security and low computational overhead to implement a time lock contract in a trustless manner. Providing a combination of security, ease of use, and computational efficiency is the technical contribution of the present invention.

[0021] The method implemented by the computer may be initiated by the client sending a request indicating a desire to set a digital time lock contract. The client can specify the second encrypted asset and the time window. The agent can then construct the encryption public key and encryption private key pair. The agent can then also construct the digital time lock contract. The digital time lock contract can become active after being embedded in the blockchain, and the encryption public key is publicly available for use in encrypting data that cannot be decrypted until the encryption private key is made public.

[0022] The time window can be specified as the start time t of the time window and the time period Δt, and the time window ends after Δt. The digital time lock contract can be configured to enable one or more of the following transfers: The second encrypted asset can be transferred to the client address at any time by the encryption private key, a time lock puzzle value derivable from the encryption private key, and the client signature. The second encrypted asset can be transferred to the agent address after time t by the encryption private key and the agent signature. The second encrypted asset can be transferred to the client address after time t+Δt by the client signature. The first encrypted asset can be transferred to any address at any time by providing the encryption private key and a time lock puzzle value derivable from the encryption private key. The first encrypted asset can be transferred to the agent address after time t by the encryption private key and the agent signature. The first encrypted asset can be transferred to the client address after time t+Δt by the client signature.

[0023] In view of the above, another definition of a method implemented by a computer for generating a public encryption key on a blockchain network and enabling access to the corresponding private encryption key after a specified time period is Steps of configuring a digital time lock contract between an agent and a client on the blockchain network, where the agent has an agent signature associated with an agent address on the blockchain network, the client has a client signature associated with a client address on the blockchain network, and the digital time lock contract a first encrypted asset (e.g., a deposit) from the agent, The second encrypted asset (e.g., a fee) from the client, the public encryption key, and a time window in which the agent should publish the encryption private key corresponding to the public encryption key, the time window being defined by a start time t of the time window and a time period Δt, the time window ending after the time period Δt, are specified, and the digital time lock contract is configured to enable the following transfers: The second encrypted asset can be transferred to the client address at any time by the time lock puzzle value derivable from the encryption private key and the encryption key, and the client signature. The second encrypted asset can be transferred to the agent address after time t by the encryption private key and the agent signature. The second encrypted asset can be transferred to the client address after time t + Δt by the client signature. The first encrypted asset can be transferred to any address at any time by providing the encryption private key and a time lock puzzle value derivable from the encryption private key. The first encrypted asset can be transferred to the agent address after time t by the encryption private key and the agent signature, and the first encrypted asset can be transferred to the client address after time t + Δt by the client signature, steps; broadcasting the digital time lock contract to the blockchain network for mining on the blockchain, including one or both of the steps.

[0024] The agent may participate in a plurality of digital time-lock contracts with a plurality of clients. The agent may be a single agent that holds the private key. Alternatively, the agent may include a plurality of agents each holding a share of the cryptographic private key. In this case, the derivation of the cryptographic private key is enabled by a threshold number of private key shares provided by the plurality of agents. The first encrypted asset and the second encrypted asset are then split among the agents. The security and reliability of the service can be further enhanced by extending the core protocol to a group of independent service providers each having an individual contract and distributing the time release of the private key using a dealer-free secret sharing (m-of-n) threshold scheme. Thus, it is resilient to service providers with sub-threshold malfunction. We describe an extended zero-knowledge proof that enables a client to prove that a private key share corresponding to a shared public key is revealed in order to cancel the contract before any payment is made.

[0025] Based on a digital time-lock contract, a client can provide services to a plurality of end users. For example, the service may be one or more of a secret bid auction, an escrow system, a voting system, a time release of confidential data.

[0026] The computer-implemented method described herein can be implemented by providing a computer-readable storage medium including computer-executable instructions that, when executed, configure a processor to perform the method described herein. Further, an electronic device can be provided that includes an interface device, a processor coupled to the interface device, and a memory coupled to the processor, the memory storing computer-executable instructions that, when executed, configure the processor to perform the method described herein.

[0027] The present invention described herein is different from the prior art discussed in the foregoing background art.

[0028] The Ethereum Alarm Clock system is significantly different from the system described herein in that it does not disclose that an agent holds a secret cryptographic key associated with a public key and then a digital contract is provided to manage the system to ensure that the agent discloses the secret key within a specified time window and that the agent discloses the secret cryptographic key at the appropriate time. Further, the conventional system does not allow the use of the public key for a specified amount of time during which the data associated with the use is encrypted and then does not disclose the secret key to enable the decryption of the data associated with the use.

[0029] The system described in "μchain: How to Forget without Hard Forks" is also considered to be significantly different from the system described herein in that it does not disclose that an agent holds a secret cryptographic key associated with a public key and then a digital contract is provided to manage the system to ensure that the agent discloses the secret key within a specified time window and that the agent discloses the secret cryptographic key at the appropriate time. The conventional system is considered not to allow the use of the public key for a specified amount of time during which the data associated with the use is encrypted and then not to disclose the secret key to enable the decryption of the data associated with the use. Here, the disclosure of the secret key is premised on terms that guarantee disclosure at the appropriate time. Rather, in the μchain literature, the decryption key is not generated by the agent but by the user of the system. That is, the user remains in control of the disclosure of the decryption key, and thus the system relies on trusting the user. The user can thus immediately compromise security.

[0030] Similarly, neither "Secure Multiparty Computations on Bitcoin" nor US2016086175 discloses that an agent holds a private cryptographic key associated with a public key and then discloses the private key within a specified time window, and a digital contract is provided to manage the system to ensure that the agent discloses the private cryptographic key at the appropriate time, which is significantly different from the system described herein.

Brief Description of the Drawings

[0031] The above and other aspects of the present invention will be apparent from and taught by the embodiments described herein. Embodiments of the present invention will be described below by way of example only with reference to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Modes for Carrying Out the Invention

[0032] The emergence of the Bitcoin blockchain has led to a system that has both a decentralized global consensus (as recorded in the block headers) and trustless automatic execution of contracts (scripts). These are unique features that can be utilized for the realization of secure and reliable time-release encryption services. In this specification, we describe a system for a time-release encryption service that utilizes a combination of smart contracts based on Bitcoin scripts and zero-knowledge proofs that do not rely on complete trust in service providers. Further, we show how the protocol can be extended using a dealerless threshold scheme to improve the resilience and security of the service through decentralization using multiple agents for a single public key.

[0033] Certain configurations utilize the concept of zero-knowledge proofs of knowledge (ZKP) to make the protocol completely trustless. There are two techniques that can be used as part of the scheme. Namely, non-interactive proofs, and cut-and-choose.

[0034] Non-interactive zero-knowledge (NIZK) proofs are preferred for this application as they minimize the communication required between the parties involved. However, they can be complex to implement and computationally expensive. Formally, NIZK proofs can be provided directly from the prover to the verifier, but in this case they require a trusted setup (σ). In this application, the verifier performs the trusted setup and then sends this to the prover. The prover then calculates the proof (π) and returns this to the verifier.

[0035] In the first application, we require a zero-knowledge proof that the preimage of the hash (provided to the verifier) equals the secret key corresponding to the elliptic curve public key (also provided to the verifier). The mathematical structure of this particular NIZK is detailed in [Fuchsbauer 2008]. This NIZK proof can be implemented by zk-SNARKS [Lundkvist 2017].

[0036] In the second application using the extended system, the construction of efficient NIZK proofs is interesting. In this case, a simplified interactive type of cut-and-choose for ZKP is available [Crepeau 2011]. In this approach, the prover provides the verifier with a large number of commitments to different statements. The verifier then randomly selects a subset of these commitments and requests the prover to send the knowledge to prove them. When it is shown that this subset of statements is true, the verifier can infer the probability that the remaining statements are also true.

[0037] A particular construction utilizes some standard features of Bitcoin transaction scripts to enable the use of time locks and hash locks for outputs.

[0038] Bitcoin outputs can be configured such that an unlocking script is required to provide a secret that hashes to a specified value (e.g., using the HASH256 opcode). That is, in order to spend the output, the input must provide a value that hashes to another value specified within that output [Maxwell 2016].

[0039] The output can also be configured to be unusable until some specified future point in time. This is achieved using the CHECKLOCKTIMEVERIFY (CLTV) opcode. This opcode can be used to prevent the use of a transaction until a specified Unix epoch time or block height is reached [Todd 2014].

[0040] To ensure the smart contract structure, a novel application of a short time-lock puzzle is utilized to prevent a "race attack". A successive squaring time-lock puzzle that requires only negligible computational work to set (the lock of the output) can be used [Rivest 1996]. For a second party without the setting parameters, a set number of serial calculations (requiring a specific amount of time) must be performed on the input to solve the puzzle and reveal the output value.

[0041] In one configuration of a time-based public-key encryption scheme by a trusted agent, the agent generates a public-private key pair (using a public-key cryptosystem), publishes the client's public key to be used for encrypting information, and then sends it to the recipient. Next, at the agreed-upon time (determined by the agent), the agent publishes the private key to the recipient for decrypting the information. In this case, the agent must be fully trusted to perform this operation and securely hold the private key.

[0042] Rabin and Thorpe [Rabin 2006] proposed a system to extend the security and fault tolerance of this configuration by distributing key generation among some group of agents worthy of trust. As a result, even if some of the parties are dishonest or there is information leakage, none of them can know the complete private key until a threshold number of agents agree that it is the proper time to publish the private key.

[0043] In this system, a group of network-connected agents (n) cooperate using a dealerless threshold (m-of-n) secret sharing scheme to generate a shared secret key and corresponding shared public key. The shared public key is then made public to the client (the client can then encrypt messages). The complete secret key can be reconstructed and sent to the recipient only when a threshold number (m) of agents agree that the time has come to make the key public.

[0044] Shamir's secret sharing scheme (SSSS) [Shamir 1979] is based on the concept that a polynomial of degree t can fit any set of t + 1 points. The polynomial f(x) of degree t is formed with the shared secret key as the constant term (a0 = f(0)), and the remaining coefficients are randomly chosen. The n points on the curve are then given to each participant. When m = t + 1 or more participants combine their points, there is sufficient information to fit a polynomial of degree t to these points, and a0 is revealed as the secret. This scheme enables the sharing of a single secret key among any large number of parties with any threshold number.

[0045] The standard SSSS can be extended to remove the requirement for a trusted dealer to generate the polynomial and distribute the (single point of failure and thus not trustless) secret shares. In this dealerless SSSS, each participant P i generates their own random polynomial f i (x) of degree t and then securely sends f i (j) to each other participant P j . Each P i then adds up all the received points, f1(i) + f2(i) +... + f n (i), to obtain their secret share S i = f(i). This is the point of P i on the shared polynomial f(x).

[0046] After the secret share is generated, the public key corresponding to the shared secret key (unknown to any participant) is calculated as follows (by the elliptic curve generator G).

[0047] Participant P i calculates their public key share as b i s i ×G, where i = 1,..., t + 1 and is as follows.

Equation

[0048] These public key shares are then broadcast, and the shared public key A is then calculated simply as the sum of the t + 1 shares as follows.

Equation

[0049] <Single Agent Protocol> This chapter describes the configuration when a single agent provides a time public key encryption service. The protocol is described in relation to Bitcoin transactions and its native scripting language (Script) without loss of generality, but is applicable to any encryption system with a public blockchain and equivalent scripting capabilities.

[0050] The protocol is directly related to two parties. · The client specifies the parameters of the required lock time encryption service and pays the fee (F) for it. The client controls the address CAddr. · The agent executes the time lock encryption service and receives the fee upon normal completion. The agent provides a deposit (D) that will be confiscated if the service is not properly executed. The agent controls the address AAddr.

[0051] Figure 1 shows a flow diagram of an initialization protocol for setting up a digital time lock contract between a client and an agent after the establishment of a communication channel between the client and the agent. The setup proceeds as follows.

[0052] 1. The client submits a request for a time lock service in a public forum. The request consists of the client address (CAddr), the fee (F) they want to pay, the time (T) after which they require the key to be made public, and the required waiting time (Δt).

[0053] 2. An agent who wishes to execute the service contacts the client and establishes a secure communication channel. The client sends the transaction ID of the UTXO to be used for the fee.

[0054] 3. The agent then securely generates a random encrypted private key (EPrivK) and the corresponding public key (EPubK).

[0055] 4. The agent then calculates a value tlpEPrivK, which is a time lock puzzle output from EPrivK, and requires approximately one hour of continuous calculation (the standard Bitcoin blockchain transaction confirmation time) to calculate from EPrivK as input.

[0056] 5. The agent then sends EPubK, the SHA-256 hash H(EPrivK) of the corresponding private key, and H(tlpEPrivK) to the client.

[0057] 6. The client performs a NIZK proof setup: σ←Setup(1 256 ) and sends the result to the agent.

[0058] 7. The agent constructs proofs π1 ← Prove(σ, H(EPrivK), EPubK), where the preimage of H(EPrivK) is the ECC private key corresponding to EPubK, and π2 ← Prove(σ, H(tlpEPrivK), H(EPrivK)), where the preimage of H(tlpEPrivK) is the preimage of H(EPrivK), with a time-lock puzzle of about one hour, and sends them to the client.

[0059] 8. The client verifies both proofs: Verify(σ, H(EPrivK), π1) = true and Verify(σ, H(tlpEPrivK), π2) = true.

[0060] 9. The agent then generates a transaction (Tx0) that functions as a time-lock encrypted smart contract using the request parameters, the hash of the encryption private key (EPrivK), and the hash of tlpEPrivK.

[0061] Tx0 has two inputs, namely, the client fee (F) UTXO and the agent deposit (D) UTXO.

[0062] Tx0 has three outputs, namely, output 1 for the fee amount, output 2 for the deposit amount, and output 3 for the encrypted public key metadata. Output 1: Payment (F) to the client address by EPrivK, tlpEPrivK, and the client signature at any time. Payment (F) to the agent address by EPrivK and the agent signature after time T. Payment (F) to the client address by the client signature after time T + ΔT. Output 2: Payment (D) to any address by EPrivK and tlpEPrivK at any time. Payment (D) to the agent address by EPrivK and the agent signature after time T. Payment (D) to the client address by the client signature after time T + ΔT. Output 3: OP_RETURN containing the encrypted public key (EPubK) as metadata.

[0063] Figure 2 shows the entire transaction structure. In Figure 2, for clarity, <…PubKey> is OP_DUP OP_HASH160 <pubkeyhash>Note that it is replaced by OP_EQUALVERIFY. Here, pubKeyHash is equivalent to the address. Outputs 1 and 2 may be implemented as P2SH (pay-to-script-hash) scriptPubKeys with corresponding Redeem scripts to be sent and / or issued to the relevant parties.

[0064] 10. The agent signs the transaction and sends the transaction to the client.

[0065] 11. The client signs the transaction and broadcasts the transaction to the Bitcoin network.

[0066] 12. When the transaction is mined into the blockchain, the time lock contract is activated. EPubK is now publicly available for use in encrypting any data. The data cannot be decrypted until EPrivK is made public.

[0067] Figure 3 shows a schematic time series of a digital time lock contract and the destination of the output that depends on the time period. The contract is designed such that the agent publishes the encrypted private key (EPrivK) within the time interval T to T + ΔT to bill both the fee and the deposit. To do this, the agent generates two transactions, Tx1 (using Tx0 output 1) and Tx2 (using Tx0 output 2). The scriptSig to unlock the output is <eprivk>It includes both <AAddr Pubkey> and <AAddr Sig>. Tx1 and Tx2 then pay both F and D to the addresses selected by the agent. Once these transactions are embedded in the blockchain, EPrivK is then publicly disclosed and becomes available to anyone.

[0068] To prevent the agent from leaking EPrivK to someone (possibly in exchange for a bribe) before time t, the contract is designed so that if someone who knew EPrivK before time T uses Output 2 by providing the hash preimage (and the corresponding time - lock puzzle tlpEPrivK, see the race - attack protection below) without a signature, the agent can then claim the entire agent deposit. This party is called the leaker. When this occurs, the client then also knows EPrivK and before time T, scriptSig <eprivk>Output 1 can be used by <CAddr Pubkey> <CAddr Sig> to re-bill the client fee.

[0069] This provides a strong incentive structure for the agent to keep EPrivK secure. If someone (including a hacker) discovers EPrivK before time T, they can anonymously bill the agent's deposit. If the agent bills (or enables) the deposit as an information leaker before time T, they will have their fees forfeited (which are refunded to the client). Therefore, the choice of the values of the fees and the deposit should affect the security of the system and be appropriate for the reasons for the encryption requirements.

[0070] The contract is also designed to ensure that the agent publishes the encryption key after time T and before time T+ΔT (where ΔT is the required waiting time). After time T+ΔT, if EPrivK has not been published, the client can unlock both Output 1 and Output 2 (re-bill the fee and also take the agent's deposit as compensation). In this case, the client generates both of the two transactions TxR1 (using Tx0 Output 1) and TxR2 (using Output 2) with scriptSig <CAddr Pubkey> <CAddr Sig>, and pays both F and D to the addresses selected by the client.

[0071] The properties of the Bitcoin script language allow (by OP_CHECKLOCKTIMEVERIFY) to prevent an output from being spent until a certain point in time, but it is not possible to prevent an output from being spent after a certain point in time (if it was spendable before that point in time). Thus, once scriptSig becomes valid, it remains valid forever. This presents a problem with the lock script of output 2, where by providing EPrivK, anyone can at any time, even after time T, use output 2 just by being requested the preimage of H(EPrivK).

[0072] This could enable a "race double spending attack" against an agent. That is, if an agent properly broadcasts Tx1 and Tx2 to the Bitcoin network (after time T), any miner could extract EPrivK from either of them and include their own anyone - can - spend transaction in a block to spend output 2 and steal the deposit first (or someone else could freely replace it).

[0073] The solution implemented here to prevent this attack is an additional requirement for the tlpEPrivK (time-lock puzzle output from EPrivK) that should always be provided together with EPrivK to unlock Output 2. If someone (the information leaker) comes to own EPrivK before time T, they can secretly determine tlpEPrivK with one hour of computation and then claim the deposit (i.e., unlock Output 2). When EPrivK is embedded in Tx1 and Tx2 that are waiting to be mined in the mempool, if they first acquire EPrivK (after time T), the agent transaction (Tx2) that uses Output 2 is already confirmed in the blockchain until they derive tlpEPrivK (one hour of computation). The result of the race attack protection is that, since tlpEPrivK takes one hour to derive, an agent can publicly disclose EPrivK in less than one hour before time T without the risk of being deprived of the deposit. This limits the "time resolution" or precision of the contract to one hour.

[0074] <Multi-agent protocol> The above smart contract protocol can be stored in the case of multiple agents with threshold secret keys. In this case, each agent generates its own version of Tx0 with its own deposit and individual fees. The only difference is that the secret key (EPrivK) hash and public key (EPubK) are replaced by the hash of the secret key share and the shared public key, respectively. Each contract is executed independently, and the key shares are revealed on the blockchain after time T. Since a threshold number of key shares are required to reconstruct the entire secret key, the system can tolerate sub-threshold agents being dysfunctional and removes the single point of failure (single agent) for more important and critical applications. The main technical differences required for this extended protocol relate to dealerless shared key generation and a multi-party zero-knowledge proof system that enables a group of agents to cooperate in proving that the preimage of the hash of their secret key shares corresponds to the shared public key whose hash is published.

[0075] The multi-agent protocol then relates to the following participants. · A client who specifies the parameters of the required lock-time encryption service and pays the total fee (F) for it (split among n UTXOs). The client controls the address CAddr. · n independent agents who cooperate in executing the service and each receive a portion (F / n) of the fee if they execute the protocol correctly. Each agent provides a deposit (D) that will be forfeited if the protocol is not executed properly. Each agent (i = 1, 2,..., n) controls the address AAddr i and.

[0076] Figure 4 shows a schematic diagram of the multi-agent protocol. The setup proceeds as follows.

[0077] 1. The client submits a request for the time-lock service within the public forum. The request consists of the client address (CAddr), the fee (F) they want to pay, the time (T) after which they request the key to be made public, the required waiting time (Δt), the required number of agents (n), and the required threshold (m).

[0078] 2. n agents who wish to execute the service contact the client and establish a secure communication channel. The client transmits the transaction ID of the UTXO to be used for the fee.

[0079] 3. The client then broadcasts the detailed contact information of each agent to the group, and each agent establishes secure communication with each other agent in the group (by means of a public-key cryptosystem or Diffie-Hellman key exchange).

[0080] 4. The players then jointly execute a dealerless secret sharing protocol with threshold m to generate a shared key EPrivK (encrypted secret key). Each player (i = 1,..., n) then processes a key share sEPrivKi (EPrivK is not known to any party).

[0081] 5. The group of n players then calculates their public key shares for each secret key share and broadcasts these shares (sEPubKi) to the rest of the group. Each player can then independently calculate the corresponding shared public key EPubK.

[0082] 6. The agents (i = 1,..., n) then calculate a value tlpsEPrivKi which is a time-lock puzzle output from sEPrivKi and requires approximately one hour of continuous calculation to compute from sEPrivKi as input.

[0083] 7. Next, the agents (i = 1, ..., n) send EPubK, the SHA-256 hash H(sEPrivKi) of their corresponding private keys, and H(tlpsEPrivKi) to the client.

[0084] 8. The group of agents then cooperatively provides the client with a zero-knowledge proof that the pre-images of the hashes of their secret key shares can be used to reconstruct the secret key corresponding to EpubK with a threshold of m. The development of NIZK proofs for this is a significant amount of work and can be extremely expensive. However, the "cut-and-choose" method is relatively efficiently available. In this case, the group of n agents repeats steps 4 - 7 a large number of times (N = 100 - 1000). The client then randomly selects one of the shared public keys and requests that the group reveal the secret key shares for the remaining N - 1 public keys. The client verifies both that the secret key shares can reconstruct the secret key corresponding to each shared public key and that the secret key shares are the pre-images of the hashes that were sent. This then verifies that there is a probability of less than (N - 1) / N that an agent is dishonest. Any agent that provides an invalid key share or hash is removed from the protocol and replaced (and the process is repeated). The randomly selected shared public key (and the corresponding secret key share hash) is then used in the protocol for the n transactions.

[0085] 9. Next, the agents (i = 1, ..., n) generate a transaction (Tx0i) with exactly the same structure as Figure 1 using the request parameters, the hash of the encrypted private key (EPrivK), and the hash of tlpEPrivK.

[0086] Each Tx0i has two inputs. Namely, the client fee share (F / n) UTXO and the agent deposit (D / n) UTXO.

[0087] Each Tx0i has three outputs. That is, Output 1 for (F / n), Output 2 for D, and Output 3 for EPubK metadata. Tx0i Output 1 (Output1): Payment (F / n) to the client address at any time by sEPrivKi, tlpEPrivK, and the client signature. Payment (F / n) to the agent address by sEPrivKi and the agent signature after time T. Payment (F / n) to the client address by the client signature after time T+ΔT. Tx0i Output 2 (Output2): Payment (D) to any address by sEPrivKi and tlpsEPrivKi at any time. Payment (D) to the agent address by sEPrivKi and the agent signature after time T. Payment (D) to the client address by the client signature after time T+ΔT. Tx0i Output 3 (Output3): OP_RETURN containing the encrypted public key (EPubK) as metadata.

[0088] 10. Each agent signs their corresponding transaction and sends the transaction to the client.

[0089] 11. The client signs each of the n transactions and broadcasts them to the Bitcoin network.

[0090] 12. When the transaction is embedded in the blockchain, EPubK becomes publicly available for use in encrypting any data, which cannot be decrypted until the data is revealed from the key shares sEPrivKi of the threshold number (m) of keys whose EPrivK has been published by the agent.

[0091] Each individual contract (Tx0i) is executed in the same way as the single-agent contract described above. Each agent risks losing their deposit if their key share leaks before time T. They are each individually incentivized to publish their key share after time T in order to claim their deposit and their share of the fees. The execution of each individual contract is completely independent of each other. This system is then resilient to a sub-threshold (n - m) number of participants not publishing their key shares at the appropriate time or leaking them prematurely, without risking the security or reliability of the service. For each agent that does not publish their key share before time T + ΔT, the client can claim their share of the fees and the deposit of the malfunctioning agent.

[0092] It should be noted that the above-described embodiments do not limit the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention defined by the appended claims. In the claims, any reference signs enclosed in parentheses shall not be construed as limiting the claim. The terms "comprising" or "comprises" etc. do not exclude the presence of elements or steps other than those listed in any claim and in the specification as a whole. In the present specification, "comprises" means "includes" or "consists of", and "comprising" means "including" or "including of". The reference to a single element does not exclude the presence of a plurality of such elements, and vice versa. The present invention can be implemented by hardware having a plurality of distinct elements or by a computer appropriately programmed. In a claim of an apparatus listing a plurality of means, these plurality of means can be implemented by one and the same hardware element. The fact that specific amounts are recited in mutually different dependent claims does not indicate that a combination of these amounts cannot be used advantageously.

[0093] References [Abliz200]: Abliz, Mehmud, and Taieb Znati. "A guided tour puzzle for denial of service prevention." Computer Security Applications Conference, 2009. ACSAC'09. Annual. IEEE, 2009. [Fuchsbauer2008]: Fuchsbauer, Georg, and David Pointcheval. "Encrypting Proofs on Pairings and Its Application to Anonymity for Signatures." IACR Cryptology ePrint Archive 2008 (2008): 528. [Lundkvist2017]: https: / / media.consensys.net / introduction-to-zksnarks-with-examples-3283b554fc3b [Crepeau2011]: Crepeau, Claude. "Cut-and-choose protocol." Encyclopedia of Cryptography and Security. Springer US, 2011. 290 - 291. [Maxwell2016]: https: / / bitcoincore.org / en / 2016 / 02 / 26 / zero-knowledge-contingent-payments-announcement / [Todd2014]: https: / / github.com / bitcoin / bips / blob / master / bip-0065.mediawiki< / eprivk> < / eprivk> < / pubkeyhash>

Claims

1. A method implemented by a computer for generating a public key in a blockchain network and enabling access to a corresponding private key after a specified time period, the method comprising, at an agent on the blockchain network having an agent signature associated with an agent address on the blockchain network, generating a private key and a corresponding public key; deriving a time-lock puzzle from the private key and calculating a value representing the output of the time-lock puzzle output; sending the public key, a first hash of the private key, and a second hash of the value to a client on the blockchain network, the client having a client signature associated with a client address on the blockchain network; constructing a first non-zero knowledge proof that the private key is a preimage of the first hash and a second non-zero knowledge proof that the value is a preimage of the second hash, and sending the first non-zero knowledge proof and the second non-zero knowledge proof to the client; constructing a digital time-lock contract between the agent and the client using the first hash and the second hash; wherein the digital time-lock contract comprises: (i) the agent publicly disclosing the private key to the blockchain network within a specified time window; (ii) the agent holding the private key and providing a first encrypted asset for public disclosure to the blockchain network within the specified time window, the first encrypted asset being transferable to the agent address on the blockchain network if the private key is publicly disclosed to the blockchain network within the specified time window; (iii) The client provides a second encrypted asset to the agent for holding the secret encryption key and publishing it to the blockchain network within the specified time window, and the second encrypted asset is transferable to the agent address on the blockchain network when the secret encryption key is published to the blockchain network within the specified time window. (iv) If the secret encryption key is published before the specified time window starts, the second encrypted asset is transferable to the client address on the blockchain network. (v) If the secret encryption key is not published before the specified time window ends, the second encrypted asset is transferable to the client address on the blockchain network. (iii) A method implemented by a computer, which specifies the above. (2) (5) The method according to claim 1, further comprising the step of receiving, from the client, a result of a set non-zero proof of knowledge and using the result to construct the first non-zero proof of knowledge and the second non-zero proof of knowledge. (3) (7) The method implemented by a computer according to claim 1 or 2, wherein the client verifies the first non-zero proof of knowledge and the second non-zero proof of knowledge before the agent constructs the digital time lock contract. (4) (9) The method implemented by a computer according to any one of claims 1 to 3, wherein in step (iv), the client or another person can use the secret encryption key to capture the first encrypted asset of the agent. (5) (11) The method implemented by a computer according to any one of claims 1 to 4, wherein in step (v), the first encrypted asset is also transferable to the client address on the blockchain network. (6) (13) The method implemented by a computer according to any one of claims 1 to 5, which is started by the client sending a request indicating a desire to set a digital time lock contract. (7) (15) The method implemented by a computer according to claim 6, wherein the client specifies the second encrypted asset and the specified time window.

8. The digital time lock contract becomes active after being mined into the blockchain, the public key is made available to the public for use in encrypting data, and the data cannot be decrypted until the private key is made public. A method implemented by a computer according to any one of claims 1 to 7.

9. The specified time window is specified as a time t at which the specified time window starts and a time period Δt, and the specified time window ends after the time period Δt. A method implemented by a computer according to any one of claims 1 to 8.

10. The second encrypted asset can be transferred to the client address at any time by the private key, the value, and the client signature. A method implemented by a computer according to claim 9.

11. The second encrypted asset can be transferred to the agent address after time t by the private key and the agent signature. A method implemented by a computer according to claim 9 or 10.

12. The second encrypted asset can be transferred to the client address after time t + Δt by the client signature. A method implemented by a computer according to any one of claims 9 to 11.

13. The first encrypted asset can be transferred to any address at any time by providing the private key and the value. A method implemented by a computer according to any one of claims 9 to 12.

14. The first encrypted asset can be transferred to the agent address after time t by the private key and the agent signature. A method implemented by a computer according to any one of claims 9 to 13.

15. The first encrypted asset can be transferred to the client address after time t + Δt by the client signature. A method implemented by a computer according to any one of claims 9 to 14.

16. The agent executes the steps a plurality of times together with each of a plurality of clients. A method implemented by a computer according to any one of claims 1 to 15.

17. A computer-readable storage medium including computer-executable instructions that, when executed, configure a processor to perform the method according to any one of claims 1 to 16. **Claim 18** An electronic device, an interface device, a processor coupled to the interface device, a memory coupled to the processor, the memory storing computer-executable instructions that, when executed, configure the processor to perform the method according to any one of claims 1 to 16, an electronic device comprising.

Images