Pseudo-random number generation in blockchain

Abstract

To provide a method which utilizes cryptographic and mathematical techniques to enforce security in relation to electronic transfers conducted over a blockchain network, a system and a storage medium.SOLUTION: A method to be implemented by using a bitcoin blockchain network verifies a third transaction which is associated with a third digital asset and includes first and second puzzles in a locking script. The first puzzle is included in a first transaction in a first locking script which encumbers transfer of control of a first digital asset. The second puzzle is included in a second transaction in a second locking script which encumbers transfer of control of a second digital asset. A pseudorandom number generator generates a pseudorandom number based at least in part on the solution to the first puzzle and the solution to the second puzzle, and transfers control of the third digital asset based at least in part on the pseudorandom number.SELECTED DRAWING: None

Description

[Technical field]

[0001] The present invention relates generally to distributed ledger technology, including blockchain transactions, and more particularly to securing random number generation within a blockchain script. The present invention further utilizes cryptographic and mathematical techniques to enhance security for electronic transfers made on a blockchain network. The present invention is particularly suited for, but not limited to, use in smart contracts. [Background technology]

[0002] In this document, the term "blockchain" may refer to any of a number of types of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and purposes of illustration, reference may be made to the example of "Bitcoin" as a useful application of the technology described in this disclosure, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain; alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure may provide the advantage of utilizing a blockchain implementation that has similar restrictions as Bitcoin regarding what constraints may be encoded in transactions, regardless of whether cryptocurrency exchanges occur.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, which consist of transactions and other information. In some instances, a "blockchain transaction" refers to an input message that encodes a structured collection of field values ​​that contain data and a set of conditions, the satisfaction of which is required before the message can be written to the blockchain data structure with respect to the set of fields. For example, in Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output.

[0004] In some embodiments, a "digital asset" refers to binary data associated with rights to use. Examples of digital assets include Bitcoin and other cryptocurrencies. In some embodiments, such as Bitcoin, digital assets are untokenized, so that there is no identifier for the digital asset identified, for example, in the blockchain; rather, control of the digital asset is demonstrated by the ability to generate valid transactions that become recorded in the blockchain. However, it should be noted that some blockchain implementations may use tokenized digital assets, so that the digital asset is specifically identifiable using information recorded in the blockchain. While digital assets may be used as cryptocurrency in some embodiments, it is contemplated that in addition or alternatively, digital assets may be used in other content. It should be noted that the present invention, while applicable to control of digital assets, is technical in nature and may be used in other contexts that utilize blockchain data structures that do not necessarily involve the transfer of digital assets. A "digital asset" as used in this disclosure may refer to one or more digital assets. For example, a transaction may have multiple inputs, each of which may represent a different digital asset. The digital asset for which control is transferred may, in this example, be a collection of multiple digital assets, which is itself a digital asset. Similarly, the transaction subdivides and / or combines these multiple inputs to generate one or more outputs, so that, for example, the number of inputs and the number of outputs may differ.

[0005] In some implementations, transferring control of digital assets can be performed by reassociating at least a portion of the digital assets from a first entity to a second entity. Each block contains a hash of the previous block, so that blocks are chained together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0006] In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models or operations. That is, a stack-based scripting language may utilize a data structure called a stack. In a stack, values ​​may be pushed onto the top of the stack or popped off the top of the stack. Various operations performed on a stack may result in pushing or popping one or more values ​​from the tip of the stack. For example, the OP_EQUAL operation takes the top two items off the stack, compares them, and pushes the result (e.g., 1 if they are equal or 0 if they are not equal) onto the top of the stack. In some scripting languages ​​used in some embodiments of the present application, there may be at least two stacks, a main stack and an alternate stack. Some operations in the scripting language may move an item from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternate stack. Scripts written in stack-based scripting languages ​​can be pushed onto a logical stack, which can be implemented using any suitable data structure, such as a vector, list, or stack.

[0007] For a transaction to be written to the blockchain, it must be "validated". Network nodes (mining nodes) perform tasks to ensure that each transaction is valid, and transactions that are not valid are rejected from the network. Nodes can have different standards for validity than other nodes. Since validity in the blockchain is consensus-based, a transaction is considered valid if a majority of nodes agree that the transaction is valid. A software client installed on a node performs this validation task for transactions that reference partially unspent transaction outputs (UTXOs) by executing UTXO locking and unlocking scripts. A transaction is validated by a node if the execution of the locking and unlocking scripts evaluates to TRUE, and if other validation conditions are met, if applicable. Validated transactions are propagated to other network nodes, and mining nodes can choose to include the transaction in the blockchain. Thus, in order for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction---and once the transaction is verified, the node relays it to other nodes in the network; ii) be added to a new block that is constructed by mining nodes; and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed when it has been added to the blockchain in enough blocks to make it effectively irreversible.

[0008] One area of ​​current research is the use of blockchain to implement "smart contracts". These are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce outcomes, and can cause actions to be performed that depend on those outcomes.

[0009] In some embodiments, although interactions with specific entities may be encoded in specific steps of a smart contract, the smart contract may otherwise be automatically executed and self-executing. In some examples, automatic execution refers to the successful execution of a smart contract that is executed to allow the transfer of a UTXO. Note that in such examples, an "entity" capable of causing the transfer of a UTXO refers to an entity capable of creating an unlocking script without being required to prove knowledge of any secret. In other words, an unlocking transaction may be verified without verifying that the source of the data has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcement refers to the validating nodes of a blockchain network being forced to execute the unlocking transaction in accordance with the constraints. In some examples, "unlocking" a UTXO refers to creating an unlocking transaction that references the UTXO and executes as valid. Unlocking a UTXO is also known in the art as consuming a UTXO.

[0010] A blockchain transaction output includes information about the ownership of a digital asset, such as Bitcoin, and a locking script. A locking script, which may also be referred to as an encumbrance, "locks" a digital asset by specifying conditions that must be satisfied to unlock the UTXO. For example, a locking script may require that certain data be provided in the unlocking script to unlock the associated digital asset. Locking scripts are also known as "scriptPubKeys" in Bitcoin. Techniques for requiring a party to provide data to unlock a digital asset include embedding a hash of the data within the locking script. However, this is problematic if the data is not determined (e.g., it is unknown and indefinite) at the time the locking script is created. Summary of the Invention

[0011] It is therefore desirable to provide a method and system that improves upon blockchain technology in one or more of these aspects.According to the present invention there is thus provided a method and corresponding system as set out in the accompanying claims. It is thus desirable to provide a computer implemented method for a node of a blockchain network, the computer implemented method comprising: Validating a third transaction including the first puzzle and the second puzzle in a third locking script, the third transaction including: The first puzzle is included in the first transaction in a first locking script that limits the transfer of control of the first digital asset according to a first condition satisfyable by a solution to the first puzzle; The second puzzle is included in the second transaction in a second locking script that limits the transfer of control of the second digital asset according to a second condition that can be satisfied by a solution to the second puzzle; The first transaction and the second transaction are committed to the blockchain; and the third transaction relating to a third digital asset; generating a pseudorandom number based on the solution to the first puzzle and the solution to the second puzzle; and Transferring control of the third digital asset based at least in part on the pseudo-random number.

[0012] The first transaction may be created by a first party and the second transaction may be created by a second party different from the first party. Thus, the solution to the first puzzle and the seeds derived from the solution to the second puzzle may be indeterminable, provided that at least one of the first or second parties remains honest (e.g., does not attempt to tamper with a pseudorandom number generator).

[0013] A first party can access the solution to a first puzzle before making a first transaction. Additionally or alternatively, a second party can access the solution to a second puzzle before making a second transaction. In this way, the parties do not need to expend as many computational resources because they already know the solution to their respective puzzles.

[0014] The first locking script may include a time constraint. Additionally or alternatively, provided that the time constraint is satisfied, validation of the transaction including the solution to the first puzzle may cause control of the first digital asset to be transferred to the first entity. Additionally or alternatively, provided that the time constraint is not satisfied, validation of the penalty transaction may cause control of the first digital asset to be transferred to a second entity different from the first entity.

[0015] The time constraint may be that a solution to the first puzzle be revealed before the time limit is exceeded, thus, the first entity has a reason to provide a solution to the first puzzle within the time constraint or risk losing the digital asset to the second entity.

[0016] Verifying the pseudorandom generated transaction may be performed prior to satisfaction of the first and second conditions. Thus, the pseudorandom generated transaction can be committed to the blockchain before the solution is published, thereby ensuring that the pseudorandom generated transaction cannot be manipulated by an entity that knows the solutions to both the first and second puzzles.

[0017] The first puzzle may be a cryptographic hash puzzle.

[0018] The first puzzle may be a set of operation codes in the locking script of the first transaction. Additionally or alternatively, execution of the set of operation codes may evaluate to true as a result of receiving as input a solution to the first puzzle.

[0019] Solving the first and second puzzles may be computationally more difficult than verifying a solution to the first and second puzzles. Generating the pseudo-random number may include deriving a seed value based at least in part on the solution to the first puzzle and the solution to the second puzzle.

[0020] The seed transaction, which includes the solution to the first puzzle and the solution to the second puzzle, can be verified. Thus, the seed can be indeterminable, provided that at least one of the first or second parties remains honest (e.g., does not attempt to tamper with the pseudorandom number generator).

[0021] Transferring control of the third digital asset may include: providing that, under a condition that the pseudorandom number is a first value, verification of the seed transaction may be successful. Additionally or alternatively, under a condition that the pseudorandom number is a second value, different from the first value, verification of the seed transaction may be unsuccessful. Thus, constraints imposed on a locking script of a pseudorandom number generator may be affected by the pseudorandom number.

[0022] A refund transaction returning control of the third digital asset to the entity that created the third transaction may be validated.

[0023] Validating the refund transaction may occur under the condition that successful validation of the solution to the first puzzle and the seed transaction containing the solution to the second puzzle has not occurred within a predetermined period of time. In this way, the entity that created the third transaction does not incur a loss of digital assets if the UTXO of the third transaction remains untransferred (e.g., after a predetermined period of time).

[0024] It is also desirable to provide a system having a processor and a memory containing executable instructions which, upon execution by the processor, cause the system to perform any of the methods for which protection is claimed.

[0025] It is also desirable to provide a non-transitory computer readable storage medium having executable instructions stored thereon which, upon execution by one or more processors of a computer system, cause the computer system to perform at least any of the methods for which protection is claimed.

[0026] It is therefore further desirable to provide a computer implemented method, the method comprising: at a node of the blockchain network, verifying a first transaction that includes a puzzle, the first transaction relating to a digital asset, and a solution to the puzzle is not determinable at the time of verifying the first transaction; generating a pseudorandom number based at least in part on a solution to a puzzle included in a second transaction by at least partially validating a second transaction created to transfer control of a digital asset associated with the first transaction; and Transferring control of the digital asset based at least in part on the pseudo-random number.

[0027] The puzzle may be a cryptographic hash puzzle.

[0028] The puzzle may be a proof-of-work function.

[0029] The puzzle may be a set of operation codes in the locking script of the first transaction. Additionally or alternatively, execution of the set of operation codes may evaluate to true as a result of receiving as input a solution to the puzzle.

[0030] Solving a puzzle may be more computationally demanding than verifying the solution.

[0031] Transferring control of the digital asset may include: providing that, under a condition that the pseudorandom number is a first value, verification of the second transaction may be successful. Additionally or alternatively, providing that, under a condition that the pseudorandom number is a second value different from the first value, verification of the second transaction may be unsuccessful. Thus, constraints imposed on a locking script of a pseudorandom number generator may be affected by the pseudorandom number.

[0032] The solution may be used at least in part to derive a seed for a pseudo-random number generation algorithm in a locking script of the first transaction.

[0033] A locking script may limit the validation of the second transaction to a certain time frame, thus giving participants a reason to solve the puzzle within a certain time frame.

[0034] Expiration of a particular time frame may allow a designated party to receive control of the digital asset.

[0035] The designated party may be the party that created the first transaction. In this manner, the designated party may be able to request the return of the digital assets if the puzzle is not solved (e.g., after a certain period of time).

[0036] The payoff (e.g., reward) for solving the puzzle may be larger (e.g., of greater value) than the digital assets. In this manner, a larger payoff may motivate participants to solve the puzzle; the larger the payoff in proportion to the digital assets, the greater the incentive. In some cases, the size of the payoff may be limited to minimize the risk of participants attempting to cheat (e.g., by interfering with pseudorandom number generation transactions and / or the solution).

[0037] The solution may be derived at least in part from the headers of blocks in a blockchain network.

[0038] The header may be indeterminate at the time the first transaction is successfully validated. For example, the header may be the header of a future block at or after a certain time in the blockchain network. In this way, a guarantee can be provided that the solution is not known until after a certain time, since future headers tend to be indeterminate at the time the first transaction is created.

[0039] It is also desirable to provide a system having a processor; and a memory containing executable instructions which, upon execution by the processor, cause the system to perform any of the methods for which protection is claimed.

[0040] It is also desirable to provide a non-transitory computer readable storage medium having executable instructions stored thereon which, upon execution by one or more processors of a computer system, cause the computer system to perform at least any of the methods for which protection is claimed.

[0041] The present invention may be described as a verification method / system and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the registration of the transaction in the blockchain; this may in some applications result in the trading or transfer of digital assets via the blockchain. Digital assets are units of resources managed by the blockchain. Digital assets may be used as cryptocurrency in some embodiments, although it is contemplated that digital assets may be used in other contexts in addition or alternatively in embodiments. It should be noted that while the present invention is applicable to the control of digital assets, it is technical in nature and may be used in other contexts utilizing blockchain data structures not necessarily involving the transfer of digital assets. As described below, the present invention may also be described as a security method / system for new and improved advantageous ways of performing operations with a blockchain network or platform. [Brief description of the drawings]

[0042] These and other aspects of the invention will be apparent from and elucidated in conjunction with the embodiment(s) described herein, which are illustrated, by way of example only, in the accompanying drawings, in which:

[0043] [Figure 1] 1 illustrates a blockchain environment in which various embodiments may be implemented. [Diagram 2] A specific example of blockchain randomization according to an embodiment is shown.

[0044] [Diagram 3] 13 shows an example illustrating the insecure randomization problem solved by embodiments.

[0045] [Figure 4]13 shows a specific example of a commitment solution for generating a portion of a seed according to an embodiment.

[0046] [Diagram 5] 13 shows a specific example of a commitment solution penalty according to an embodiment.

[0047] [Figure 6] 13 illustrates an example of implementing a seed transaction to unlock a pseudo-random number generation transaction according to an embodiment.

[0048] [Figure 7] 1 illustrates an example of requesting return of digital assets as a result of expiration of a time limit according to an embodiment.

[0049] [Figure 8] 1 is a flowchart showing a specific example of a commitment solution according to an embodiment.

[0050] [Figure 9] 1 illustrates an example of a puzzle-solving technique for generating seeds according to an embodiment.

[0051] [Figure 10] 1 is a flow chart illustrating an example of a puzzle-solving technique for generating seeds, according to an embodiment.

[0052] [Figure 11] 13 illustrates an example of randomized smart contract constraints according to an embodiment.

[0053] [Figure 12] 1 illustrates a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0054] Referring first to FIG. 1, an exemplary blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure is shown. In an embodiment, the exemplary blockchain network 100 has blockchain nodes implemented as distributed peer-to-peer devices, each node executing instances of software and / or hardware that perform operations according to a blockchain protocol, i.e., operations that are at least partially agreed upon among operators of the nodes 102. In some implementations, a "node" refers to a peer-to-peer electronic device that is distributed within a blockchain network. An example of a blockchain protocol is the Bitcoin protocol.

[0055] In some embodiments, node 102 may comprise any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), a plurality of computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as computing device 1200 of FIG. 12). In some embodiments, node 102 has an input for receiving data messages or objects representing proposed transactions, such as transaction 104. In some embodiments, nodes are queryable about information they hold, such as information about the state of transaction 104.

[0056] As shown in Figure 1, some nodes 102 are communicatively coupled to one or more other nodes 102. This communicative coupling may include over one of wired or wireless communication. In an embodiment, each of the nodes 102 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger may be a distributed ledger. Transactions processed by a node that affect the ledger may be verified by one or more other nodes such that the integrity of the ledger is maintained.

[0057] With respect to which other nodes a node 102 may communicate with, it may be sufficient that each node in the exemplary blockchain network 100 may communicate with one or more other nodes 102, such that messages passing between nodes may propagate throughout the entire exemplary blockchain network 100 (or a substantial portion thereof), provided that the blockchain protocol indicates that the messages should be forwarded. One such message may be the publication of a proposed transaction by one node 102, such as node 102A, which will then propagate along a path, such as path 106. Another such message may be the publication of a new block proposed for inclusion in the blockchain.

[0058] In embodiments, at least some of the nodes 102 are mining nodes that perform complex calculations, such as solving cryptographic problems. A mining node that solves a cryptographic problem creates a new block for the blockchain and broadcasts the new block to other nodes 102. The other nodes 102 review the mining node's work and, upon validation, accept the block into the blockchain (e.g., by adding it to the blockchain's distributed ledger). In some examples, a block is a group of transactions, often marked with a timestamp and a "fingerprint" (e.g., a hash) of the preceding block. In this manner, each block can be linked to the preceding block, thereby creating a "chain" that links the blocks in the blockchain. In embodiments, valid blocks are added to the blockchain by consensus of the nodes 102. Also, in some examples, the blockchain has a list of validated blocks.

[0059] In embodiments, at least some nodes 102 operate as validating nodes that validate transactions as described in this disclosure. In some examples, a transaction includes proof of ownership of a digital asset (e.g., a number of bitcoins) and data providing conditions for accepting or transferring ownership / control of the digital asset. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates (e.g., transfers ownership or control) at least some digital assets represented by a UTXO of a prior transaction to an entity associated with a blockchain address. In some examples, a "prior transaction" refers to a blockchain transaction that includes a UTXO referenced by the unlocking transaction. In some embodiments, a transaction includes a "locking script" that restricts the transaction with conditions that must be satisfied before ownership / control can be transferred ("can be unlocked").

[0060] In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which control of at least some digital assets is to be transferred / reassociated. In some embodiments, in any blockchain protocol implemented, there is a one-to-one correspondence between public keys associated with an entity and blockchain addresses. In some embodiments, validating a transaction includes verifying one or more conditions specified in a locking script and / or an unlocking script. Upon successful validation of a transaction 104, the validating node adds the transaction 104 to the blockchain and distributes it to nodes 102.

[0061] Certain embodiments of the present disclosure operate under the assumption that a scripting system or other system implementing the described instructions allows for more than 200 instructions (e.g., operation codes) in a single script. Similarly, certain embodiments of the present disclosure further assume: The functionality provided by the operation codes referred to in this disclosure is present and enabled in the system that executes the operation code scripts / instructions; and / or The functionality that may be required can be achieved by the creation of custom functions that are written to provide the desired behavior. These custom functions may be written to achieve the functionality of opcodes that exist in the language but are disabled, or they may be "new" opcodes that provide specific functionality not natively provided in the scripting language.

[0062] Specific examples of operation codes that may be referenced in this disclosure include the following: OP_ECPX, returns the x-coordinate of an elliptic curve point. OP_ADD, adds the top two items to the stack. OP_BIGMOD, returns the remainder after dividing the top two items in the stack. OP_BIGMODADD, which performs a modulus addition on the top two items in the stack, then a modulus operation on the third item in the stack. OP_BIGMODINVERSE, which performs a modulus-negative exponentiation operation. OP_BIGMODMUL, performs a modulus multiplication of the top two items of the stack and the third item of the stack. OP_CAT, concatenates the top two items in the stack. OP_CHECKSIG, the public key and signature are popped from the stack and verified against the signature in the transaction field according to the SIGHASH type. If the signature is verified, 1 is returned, otherwise 0 is returned. OP_CHECKSIGVERIFY, which works like OP_CHECKSIG, but then OP_VERIFY is run. OP_DERENCODE, encodes the top two items of the stack in DER format. OP_DUP, Duplicate the top stack item. OP_ECPMULT, which performs elliptic curve point multiplication (also called elliptic curve scalar multiplication) of the top two items on the stack. OP_ELSE, if the above OP_IF or OP_NOTIF or OP_ELSE was not executed, then these statements are executed; otherwise, if the above OP_IF or OP_NOTIF or OP_ELSE was executed, then these statements are not executed. OP_ENDIF, ends an if / else block. OP_EQUAL, returns 1 if the inputs are exactly equal, 0 otherwise. OP_EQUALVERIFY, similar to OP_EQUAL, but then runs OP_VERIFY. OP_FROMALTSTACK, puts the input on the top of the main stack and removes it from the alternate stack. OP_HASH256, the input is hashed twice; first with SHA-256 and then with RIPEMD-160. OP_IF, if the top stack value is False, the statements are executed and the top stack value is removed. OP_MUL, multiplies the top two items in the stack. OP_NOTIF, if the top stack value is false, the statements are executed and the top stack value is removed. OP_ROLL, the item that is n items deep in the stack is moved to the top. OP_SUBSTR, returns a portion of a string. OP_SWAP, the top two items in the stack are swapped. OP_TOALTSTACK, puts the input on the top of the alternate stack and pops it from the main stack. OP_VERIFY, marks the transaction as invalid if the top-stack value is not TRUE.

[0063] 2 is an example 200 illustrating an embodiment of the present disclosure. As shown in FIG. 2, the example includes a pseudorandom number generator (PRNG) transaction 202 having a locking script 210, the PRNG generating random numbers based on a seed value received as a result of execution of an unlocking script 212 of a seed transaction 204 that attempts to unlock a UTXO of the PRNG transaction 202.

[0064] In some embodiments, the PRNG transaction 202 is a blockchain transaction that includes a PRNG in the locking script 210. In some embodiments, a PRNG, also known as a Deterministic Random Bit Generator (DRBG), refers to an algorithm that generates a sequence of numbers that approximates the properties of a sequence of random numbers. A PRNG is distinct from a true random number generator because the sequence depends on an initial seed value. In some embodiments, a PRNG with the same seed value will reproduce the same sequence. In some embodiments, the PRNG is coded in the locking script 210 as a sequence of operation codes that, when executed, produce statistically random values ​​(e.g., those that do not contain any discernible pattern or rule). The PRNG takes as input a value as a seed that initializes the PRNG.

[0065] In some embodiments, the locking script 210 is a script that restricts the PRNG transaction 210 with conditions (e.g., with data provided by the unlocking script 212) that must be satisfied in order for the PRNG transaction 202 to be successfully validated, allowing control / ownership of the digital asset associated with the PRNG transaction 202 to be transferred. For example, the locking script 210 may require that certain data be provided in the unlocking script 212 in order to unlock the digital asset associated with the PRNG transaction 202. More specifically, execution of the locking script 210 by a validating node of a blockchain, such as the blockchain network described in connection with FIG. 1, causes the locking script 210 to accept data from the executed unlocking script (e.g., the unlocking script 212), perform certain operations based on the data, and return a result indicating whether the locking script 210 has been successfully “unlocked” (i.e., whether it satisfies a set of conditions set in the locking script 210). In this disclosure, the locking script 210 further includes a PRNG, as described above, including as a condition that the seed is received (as a result of execution of the unlocking script 212 of the seed transaction 204) as an input to the PRNG. In some embodiments, the locking script is coded to use random numbers generated by the PRNG for use within the constraints of the locking script 210.

[0066] In some embodiments, the seed transaction 204 is a blockchain transaction that includes at least within the unlocking script 212 a seed value that is usable by the PRNG in the locking script 210 of the PRNG transaction 202. In some embodiments, the unlocking script 212 is an executable script of the seed transaction 204 that attempts to satisfy a set of conditions set in the locking script 210 of the PRNG transaction 202. The principle of operation of the present disclosure is that the seed value is not deterministic at the time the locking script 210 is created, and as a result, the value generated by the PRNG based on the seed value is also not deterministic at the time the locking script is created. The present disclosure describes embodiments that satisfy these conditions.

[0067] FIG. 3 is an example 300 showing the insecure random problem solved by an embodiment of the present disclosure. That is, in the example 200 shown in FIG. 2, the PRNG 306 is included in the locking script 310 of the first transaction 302, and the seed 308 for the PRNG 306 is provided by the unlocking script 312 of the second transaction 304 created to unlock / retrieve a digital asset such as Bitcoin associated with the first transaction 302.

[0068] In some embodiments, the first transaction 302 and the second transaction 304 are a set of field values that represent the transfer of digital assets in a blockchain network. In some embodiments, the set of field values can include inputs and outputs. In some embodiments, the input represents an attempt to unlock the output of a preceding blockchain transaction. When the verification of the transaction is successful, in some embodiments, the verification node adds the transaction to the blockchain, causing it to be distributed to other nodes of the blockchain.

[0069] In some embodiments, the second transaction 304 is a blockchain transaction created to reassociate (e.g., transfer ownership or control) at least some of the digital assets (e.g., as indicated by UTXOs) of the first transaction 302 to a particular entity. In some embodiments, the first transaction 302 includes a locking script 310 that restricts the first transaction 302 with conditions that must be satisfied before ownership / control can be transferred (before it is "unlocked"). In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which control of at least some of the digital assets is to be transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between public keys associated with an entity and blockchain addresses. In some embodiments, validating the transaction includes verifying one or more conditions specified in the locking script 310 by successfully executing the unlocking script 312 and the locking script 310.

[0070] As discussed above, in some embodiments, the PRNG 306 is a pseudorandom number generator that generates a sequence of numbers whose properties approximate those of a sequence of random numbers. In some examples, the PRNG 306 is a cryptographically secure pseudorandom number generator (CSPRNG), also referred to as a cryptographic pseudorandom number generator (CPRNG). In some embodiments, the PRNG 306 may be any pseudorandom number generator that can be encoded into a locking script under the above assumptions, including, but not limited to, the Yarrow, Fortuna, and arc4random algorithms.

[0071] In some embodiments, the locking script 310 is a script that restricts the blockchain by specifying conditions that must be satisfied to transfer control of at least some digital assets associated with the transaction (i.e., conditions to be "unlocked"). More specifically, as a result of execution by a validating node of the blockchain system, executing the locking script 310 is configured to accept data from an executed unlocking script, such as the unlocking script 312, perform predefined operations based on the data, and return a result indicating whether execution of the unlocking script successfully "unlocked" the locking script 310 (i.e., satisfied a set of conditions). In some embodiments, the locking script 310 specifies one or more data constraints that must be satisfied (e.g., by data provided by the unlocking script) for successful validation of the transaction. For example, the locking script 310 may require that predefined data be provided in the unlocking script 312 to unlock the digital assets associated with the first transaction 302.

[0072] In some embodiments, the seed 308 is a number or vector used to initialize a pseudorandom number generator such as the PNNG 306. However, since the seed 308 determines the pseudorandom numbers generated by the PRNG 306 as seen in FIG. 3, the entity 314 that supplies the seed 308 to the PRNG 306 can manipulate the output of the PRNG 306. However, this disclosure proposes two solutions to defend against seed manipulation. The first solution is a commitment solution, whereby the seed is a combination of two or more puzzle solutions, where each puzzle solution is known to a different party. However, before the PRNG transaction is created, each party commits a certain amount of digital assets to a puzzle transaction, which can be redeemed by revealing a solution to the puzzle in a solution transaction. In some embodiments of the commitment solution, failure to reveal a puzzle solution will cause the digital assets committed by the defaulter to be forfeited to the person or parties who reveal their puzzle solution. In some of these embodiments, each puzzle solution must be revealed within a certain period of time, or it will be considered a breach of the commitment. In this way, each party may have reason to contribute to the seed of the PRNG. With respect to the commitment solution, each party that generates a puzzle transaction is permitted to know the corresponding solution to the puzzle in advance. In puzzle-solving techniques, the seed is the solution to the puzzle transaction. Although the solution is unknown at the time of the puzzle's creation, the puzzle solver can collect a dividend of the digital asset associated with the puzzle transaction.

[0073] In some examples, a "puzzle" refers to a set of logical expressions using one or more operation codes in a scripting language that evaluate to TRUE when presented with a particular numeric "solution" (or solution) as input. Puzzles can have various levels of difficulty that can affect the time required to solve the puzzle. Puzzles also have the characteristic that arriving at a solution (i.e., solving the puzzle) is computationally more difficult than verifying that the solution is correct. An example of a puzzle is a cryptographic hash puzzle, where the puzzle is to find a number that, when combined with a particular number and processed with a given cryptographic hash algorithm (e.g., SHA256, MD5, BLAKE, BLAKE2, etc.), results in a value that contains a particular digit (e.g., one preceded by five zeros, "1234", etc.). In some examples, a cryptographic hash puzzle is a problem that is created or solved using a cryptographic hash algorithm, such as a problem defined by a function that includes at least one cryptographic hash algorithm and a set of states, and a solution to the puzzle is a set of inputs to the function that results in an output that satisfies the set of states.

[0074] In an embodiment, the hash is generated by a cryptographic hash function or one-way function h(x)=y, where y is easily computed for given x, but note that computing x for given y is computationally expensive. In some cases, the solution may be a party's digital signature or other data that, when provided as input to an unlocking script for a locking script holding the puzzle, causes the locking script to evaluate to TRUE as a result of execution of the unlocking script and the locking script.

[0075] In some instances, computationally difficult refers to a class of complexity from the field of computational complexity theory. For example, digitally signing a message using a Merkle signature scheme involves performing 2r cryptographic hash operations as part of generating a correct solution, where r is the depth of the Merkle tree being generated. Conversely, verifying that the signing key used to generate a digital signature is a leaf node of the Merkle tree involves performing r cryptographic hash calculations to verify the authentication from the leaf node (corresponding to the signing key) to the root node. As can be appreciated, performing 2r cryptographic hash calculations would be more computationally intensive (e.g., extend more central processing unit cycles, utilize more memory / storage space, etc.) than performing r cryptographic hash calculations. As a second example, a system could generate two prime numbers and provide a product of the primes as a puzzle, with the solution being to factorize the provided product.

[0076] It should be noted that the phrase "one-way function" includes functions that are not necessarily one-way in the strict mathematical sense, but that exhibit properties (e.g., collision resistance, preimage resistance, second preimage resistance) that make them useful functions in the context in which the various techniques of this disclosure are applied. In this way, an entity that has the output of the function but does not have access to the corresponding input cannot determine the input without the prohibitively expensive expense required, for example, for a cryptographic attack (e.g., a brute force attack). One-way functions (also referred to as "effective one-way functions") include, but are not limited to, cryptographic hash functions such as message authentication codes (e.g., hash-based message authentication codes (HMAC)), key derivation functions such as PBKDF2 and bcrypt (involving a password based at least in part on a plaintext and a cryptographic key), and other secure random functions that do not necessarily have a domain (set of possible inputs) larger than the range (possible outputs). A value can be derived cryptographically using a one-way function. A cryptographic function may be a one-way function (or a component thereof) from the perspective of an entity lacking the information used as input to the cryptographic function (e.g., a cryptographic key and / or a salt). In some instances, "cryptographically derived" refers to the use of a one-way function at least once using an input that is a value or is derived from a value (perhaps cryptographically derived from a value). For example, a cryptographic computation is "one-way" to an entity that does not have the decryption key.

[0077] FIG. 4 illustrates an exemplary embodiment 400 of the present disclosure. Specifically, FIG. 4 illustrates a first stage in a commitment solution for seed generation. The commitment solution illustrated in the exemplary embodiment 400 includes at least two participants 406A-06B that contribute solutions 408A-08B that can be combined to derive a seed for a PRNG. An advantage provided by the commitment solution is that because the solutions 408A-08B are combined, manipulation of the seed requires consensus from all participants; i.e., to the extent that one participant provides a solution that is not known in advance to the others, the resulting seed will be unknown until it is generated.

[0078] In a commitment solution, each participant 406A-06B, p ∈ {0,1,...,n}, creates an individual commitment transaction 402A-02B with a puzzle 410A-10B included as a constraint in the transaction's respective locking script. In some embodiments, each commitment transaction has a constraint of (σ p ←Verify(puzzle p ,π p Some quantity of digital assets (e.g., x) that is restricted by a locking script that contains a constraint p ), and π pis a proposed solution to the puzzle of parity p. In some embodiments, the constraint is also a time limit, meaning that the parties must demonstrate a solution within a certain period of time or risk forfeiture of their committed digital assets. In some embodiments, the digital assets are committed from the party's own reserves. In other embodiments, the digital assets are offered as a potential dividend by a third party, such as someone seeking to generate random numbers from a seed determined by the parties 406A-06B. In some embodiments, the parties 406A-06B are provided with a basis for participating in the generation of seeds by a promise of a share from the creator of a PRNG transaction, such as PRNG transaction 610 of FIG. 6, or from some other entity interested in creating seeds for pseudorandom number generation.

[0079] After the commitment transactions 402A-02B are mined into the blockchain, each of the parties 406A-06B (p) can derive a solution (π p ←Puzzle solution p ), participants 406A-06B can unlock the UTXOs of their respective commitment transactions. As shown in example embodiment 400, solution transactions 404A-04B contain solutions 408A-08B to their corresponding puzzles 410A-10B. Validation of solution transactions 404A-04B thus allows participants 406A-06B to retrieve the UTXOs of their respective commitment transactions 402A-02B.

[0080] In some embodiments, commitment transaction 402A-02B is a blockchain transaction similar to first transaction 302 of Figure 3 with digital assets committed by individual participants 406A-06B. In some embodiments, solution transaction 404A-04B is a blockchain transaction similar to second transaction 304 of Figure 3 created by participants 406A-06B to "unlock" the UTXOs of the individual commitment transactions to redeem the committed digital assets.

[0081] In some embodiments, the participants 406A-06B are entities that have agreed to provide the puzzles 410A-10B and solutions 408A-08B used to generate a seed for a PRNG, such as the PRNG in the time-limited constraint 610 of FIG. 6. The puzzles 410A-10B need not be complex. For example, the participants 406 may know the result of a cryptographic hash of the letter "A" and may create a puzzle 410A that cryptographically hashes an input and compares the cryptographically hashed input to the known cryptographic hash of the letter "A". If the hashed input matches the known hash result, the input is a correct solution to the puzzle 410A. In this case, the solution is the letter "A", which the first participant 406A is aware of and can enter into the unlocking script of the solution transaction 404A as the first solution 408A. However, other participants who inspect the cryptographic hash in the locking script may not directly recognize that the solution is the letter "A". Although only two participants are shown in example 400, it is contemplated that any number of participants may participate in providing puzzles and solutions, so long as there are at least two participants.

[0082] In some embodiments, solutions 408A-08B (similar to solution 608 in FIG. 6) are multiple values ​​that can be combined to seed a PRNG, such as the PRNG in time limit constraint 610. Individually, each of solutions 408A-08B is a value that, when provided as an input by an unlocking script of solution transaction 404A-04B to a locking script of commitment transaction 402A-02B that includes puzzle 410A-10B, causes the respective unlocking and unlocking script execution to evaluate to TRUE. Seeding a PRNG causes the execution of the PRNG to generate a random number, which can be used in a variety of ways in a smart contract, some examples of which are shown in Tables 2 and 3 below. In some embodiments, at least one of the participants 406A-06B knows or has access to the solution to their respective puzzle at the time the associated commitment transaction is created. In other embodiments, all participants 407A-06B know or have access to the solution to their respective puzzles 410A-10B at the time their associated commitment transactions 402A-02B are created.

[0083] Participant 406A-06B receives a commitment value (e.g., x p ) and the PRNG transaction value (e.g., y in FIGS. 6 and 7) may prompt the participant to reveal their puzzle solution 408A-08B. For example, p >>If y, then the parties 406A-06B have a strong case to disclose their respective solutions 408A-08B because the risk of loss is much greater than the potential gain from forcing a refund transaction, such as refund transaction 704 in FIG. 7.

[0084] In some embodiments, puzzles 410A-10B are algorithms that include a series of operations, such as a series of operation codes in a scripting language, that are executed on one or more inputs and return a TRUE or FALSE indication. For example, if solution 404A is a valid solution to puzzle 410A, then execution of puzzle 410A in the locking script of commitment transaction 402A can evaluate to TRUE (assuming any other constraints present in commitment transaction 402A are satisfied). However, if the solution proposed for puzzle 410A is not a valid solution, then execution of puzzle 410A in the locking script of commitment transaction 402A will evaluate to FALSE.

[0085] FIG. 5 illustrates an example 500 of the consequences of failing to provide a valid solution to a commitment transaction within a particular time frame. Specifically, FIG. 5 illustrates a first party 506A failing to provide a valid solution to a commitment transaction within a particular time frame. c ) before the passage of puzzle 510A(σ a ) of the commitment transaction 502B created by the second party 506B within a time limit 516. b ) solution 508(π b As a result, the second party 506B receives the digital asset (x a ) may be claimed as ownership.

[0086] In some embodiments, commitment transaction 502A-02B is similar to commitment transaction 402A-02B of Figure 4. Similarly, in some embodiments, puzzle 510A-10B is similar to puzzle 410A-10B. In some embodiments, solution transaction 504 is similar to solution transaction 404B of Figure 4. Similarly, in some embodiments, solution 508 is similar to solution 408B of Figure 4. In some embodiments, participant 506A-06B is an entity similar to participant 406A-06B of Figure 4.

[0087] In some embodiments, the penalty transaction 514 is a blockchain transaction that can be verified to unlock the UTXO of the commitment transaction 502A, provided that the UTXO of the commitment transaction 502A remains untransferred after the time limit 516. Since the first party 506A committed some portion of the digital assets to the commitment transaction 506A, the penalty transaction 514 exists to discourage the first party 506A from failing to reveal the solution to the puzzle 514A, because if the first party 506A fails to reveal its solution, one or more parties that created the commitment transaction, such as the second party 506B, can claim whatever digital assets the first party 506A committed to the first commitment transaction 502A. Thus, either the parties 506A-06B must reveal the solution to their respective puzzles 510A-10B, or the parties 506A-06B may risk losing the digital assets they committed. Moreover, the participants 506A-06B are given further justification to reveal their solutions to their respective puzzles 510A-10B due to the chance that other participants will fail to reveal their own solutions, thereby allowing the non-breaching participants not only to recover the digital assets they themselves committed, but also to be awarded at least a portion of the digital assets committed by the breaching participants. This is the case shown in example 500, where the second participant 506B benefits from revealing the solution 508 and receives a dividend from the penalty transaction 514.

[0088] In some embodiments, the time limit 516 is a deadline enforced in the locking script of commitment transaction 502A. That is, in some embodiments, the locking script of commitment transaction 502A-02B is configured to limit the entities permitted to unlock the UTXOs of commitment transaction 502A-02B to only the author of the respective commitment transaction until the expiration of the time limit 516 encoded in the locking script. However, in some embodiments, the locking script can be configured to allow one or more other parties, such as second party 506B, to claim the UTXOs of the commitment transaction after the expiration of the time limit 516, but not allow the author of commitment transaction 502A to claim the UTXOs of commitment transaction 502A. In some embodiments, commitment transactions 502A-02B must include the time limit 516 in their locking script in order to be validated. In this manner, the penalty transaction 514 may act as a penalty to provide a justification for the participants 506A-06B to provide a timely solution to their puzzles 510A-10B.

[0089] FIG. 6 illustrates another exemplary embodiment 600 of the present disclosure. Specifically, FIG. 6 illustrates a second stage in a commitment solution for seed generation that may occur in parallel with the exemplary embodiment 300 of FIG. 4. That is, after the commitment transaction 402A-02B is mined into the blockchain, a PRNG transaction 602 is created by an entity that seeks to impose a random constraint on the transfer of control of the digital asset y. The locking script of the PRNG transaction 602 is then constrained by a locking script that includes a PRNG and a time limit constraint 610 (σ All ←∧σ p), the puzzle solution in the unlocking script of seed transaction 604 {π a ,...,π n} to a solution π (e.g., π←Combine({π a ,...,π n})), from which the seed for the PRNG in the locking script can be derived. That is, in some cases the solution π itself can be used as the seed, and in other cases the solution π can be hashed or otherwise manipulated into a value that can be used by the PRNG as a seed. The time limit constraint 610 can be constrained in a variety of ways. For example, there can be one or more operation codes in the locking script of the PRNG transaction 602 that, when executed, check the current time against a specified expiration time.

[0090] In the example embodiment 600, seed transaction 604 is a blockchain transaction created to unlock the UTXO of PRNG transaction 602. In some embodiments, to discourage manipulation of the PRNG, PRNG transaction 602 is created after a commitment transaction (e.g., commitment transaction 402A-02B of FIG. 4) has been committed to the blockchain but before the creation of a solution transaction (e.g., solution transaction 404A-04B). In some embodiments, seed transaction 604 is created after solutions to all puzzles, such as solutions 408A-08B, have been committed to the blockchain or made available to the creator of seed transaction 604. In some embodiments, seed transaction 604 includes solutions 608 (π) to various puzzles, such as solutions 408A-08B to puzzles 410A-10B of FIG. 4, in an unlocking script.

[0091] In some embodiments, each solution in solutions 608 is listed separately and combined by execution of the locking script of PRNG transaction 602. In another embodiment, each solution is combined together in the unlocking script of seed transaction 604 in a manner supported by the locking script of PRNG transaction 602. The locking script of PRNG transaction 602 can evaluate to TRUE if all solutions 408A-08B are provided in the unlocking script of seed transaction 604. Alternatively, in some embodiments, if a solution 408A-08B is not provided before the expiration of a time limit, the digital asset y is returned, as shown in FIG.

[0092] In one example, an entity engages a group of participants to create a commitment transaction similar to commitment transaction 402A-02B of FIG. 4. The entities then create PRNG transaction 602 utilizing puzzle 410A-10B bound to time-bound constraint 610. That is, in the simplified two-party example for example embodiment 400 of FIG. 4, if a first participant 406A reveals a first solution 608A prior to the creation of PRNG transaction 602, a second participant 408B, already having knowledge of second solution 408B, would now have knowledge of first solution 408B and could potentially determine the outcome of the locking script PRNG of PRNG transaction 602. Therefore, to preserve the unpredictability of PRNG results, solution 408A-08B should not be revealed prior to the creation of PRNG transaction 602.

[0093] In some embodiments, the entity may further create a penalty transaction for each of the commitment transactions 401A-02B, similar to penalty transaction 514 of Figure 5. Furthermore, in some embodiments, the entity may additionally or alternatively create a refund transaction, similar to refund transaction 704 of Figure 7, to ensure that the entity will not forfeit digital asset y if one or more of solutions 408A-08B are not provided.

[0094] FIG. 7 illustrates an example 700 of an alternative outcome for a party that fails to provide a valid solution to a commitment transaction within a particular time frame. Specifically, FIG. 7 illustrates an example of a party that fails to provide a valid solution to a commitment transaction within a particular time frame, such as the situation shown in FIG. All This shows a situation where the company failed to provide a solution to one of the problems. As a result, c After +Δt, the digital asset y associated with the PRNG transaction can be retrieved via refund transaction 704.

[0095] In some embodiments, PRNG transaction 702 is similar to PRNG transaction 602 of Figure 6. As shown in example 700, in some embodiments, PRNG transaction 702 is coded to expire some time (Δt) after the deadline of the commitment transaction (tc), to discourage parties from waiting to reveal their solution until PRNG transaction 702 is about to expire, because doing so could jeopardize their ability to create a seed transaction, such as seed transaction 604, in time to unlock the UTXO of PRNG transaction 702.

[0096] In some embodiments, refund transaction 704 is a blockchain transaction created to refund / return the digital asset y associated with the PRNG transaction 702 if, after time 716t + Δt, the digital asset y remains unclaimed upon verification of the seed transaction including the solution to the puzzle 710. In a specific example, the refund transaction 704 is created by the author of the PRNG transaction 702 to ensure that the author can retrieve the digital asset y if no solution to the puzzle 710 is found. However, in some examples, it is not necessary for the author of the PRNG transaction 702 and the author of the refund transaction 704 to be the same person. In some embodiments, the time 716 is a time limit set with respect to the period during which a solution to the seed of the PRNG transaction 702 is to be provided.

[0097] FIG. 8 is a flowchart illustrating an example of a process 800 for generating a random number according to various embodiments of the commitment solution of the present disclosure. All or part of the process 800 (or any other process described, or variations and / or combinations of these processes) can be executed under the control of one or more computer systems configured with executable instructions and / or other data, and can also be implemented as executable instructions operating together on one or more processors. The executable instructions and / or other data can be stored in a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on magnetic, optical, or flash media).

[0098] For example, all or a portion of process 800 may be performed by one or more computing devices (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device, such as computing device 1200 of FIG. 12). Process 800 includes a series of operations in which two puzzles are combined into a locking script of a PRNG transaction, a solution to the puzzle is combined into an unlocking script of a seed transaction after the PRNG transaction is committed to the blockchain, the PRNG in the locking script of the PRNG transaction is executed based on utilizing a seed derived from the solution to generate pseudorandom numbers, and constraints are imposed based on the generated pseudorandom numbers.

[0099] At 802, one or more puzzles are obtained, such as puzzles 410A-10B of FIG. 4. In an embodiment, the puzzles may be obtained from a script of a commitment transaction, such as commitment transaction 402A-02B. As described above, a puzzle may be a set of logical expressions using one or more operation codes in a scripting language. A puzzle is a puzzle algorithm / logical expression that evaluates to TRUE as a result of execution when a solution to the puzzle is received as input. A puzzle may be a cryptographic hash puzzle, a proof-of-work puzzle, or any other puzzle that has a numerical solution.

[0100] At 804, after the commitment transaction is committed to the blockchain, the puzzle obtained in 802 is bound in some manner to a locking script of a PRNG transaction, such as PRNG transaction 602 in FIG. 6, such that a solution to a puzzle, such as solution 408A-08B, can be received as an input and bound to derive a value that can be used as a seed for a PRNG to generate pseudorandom numbers.

[0101] After determining at 806 that the PRNG transaction has been committed to the blockchain, execution of process 800 proceeds to 808. Once the PRNG transaction has been committed to the blockchain at 808, a solution to the puzzle incorporated in the PRNG transaction is obtained, such as from solutions 408A-08B of FIG. 4. In some embodiments, a time t c After that (e.g. as shown in FIG. 7) solution acquisition is performed.

[0102] At 810, a determination is made as to whether solutions to all puzzles embedded in the locking script of the PRNG transaction have been obtained within the time limit (e.g., t+Δt in FIG. 7). If not all of the solutions have been obtained, execution of process 800 proceeds to 812, where a penalty transaction may be verified to recover the digital assets associated with the PRNG transaction, as described in the context of FIG. 7. Alternatively, if all solutions have been obtained within the time limit, execution of process 800 proceeds to 814.

[0103] At 814, the solution is incorporated into the unlocking script of the seed transaction such that, at 816, executing the unlocking script in combination with the locking script causes the solution to be converted into a seed value (e.g., combining the solution value and performing a SHA256 hash operation on the combined solution value), which causes the PRNG to generate a pseudorandom number as an input to the PRNG of the locking script. At 818, the pseudorandom number can be used to affect the constraints of the locking script of the PRNG transaction. That is, the transfer of control of the digital assets associated with the PRNG transaction is constrained in some manner based on the pseudorandom number generated by the PRNG of the PRNG locking script, such as in the manner described in connection with FIG. 11 (e.g., the pseudorandom number of the signature is accepted, the signature is accepted as valid based in part on whether the pseudorandom number is within a predetermined range of values, whether a pseudorandom amount of the digital asset is transferred, etc.). It should be noted that one or more of the operations performed at 802-18 may be performed in various orders and combinations, including in parallel.

[0104] FIG 9 illustrates an example embodiment 900 of the present disclosure. In particular, FIG 9 illustrates an example of a puzzle-solving technique for seed generation. While the commitment solution described in connection with FIG 408 involved two or more commitment parties, the puzzle-solving technique described in example embodiment 900 only requires having one puzzle solution 908 that can be used to derive a seed for a PRNG transaction 902.

[0105] In some embodiments, the PRNG transaction 902 is associated with a digital asset y that is restricted in a locking script by a constraint that can be unlocked (e.g., evaluate to TRUE) if a valid solution (σ←Verify(puzzle,π)) to the puzzle 910 is provided to the unlocking script of the seed transaction 904. In some embodiments, the locking script of the PRNG transaction 902 further includes a time limit under which the PRNG transaction 902 can be transferred. That is, in this embodiment, if a valid seed transaction 904 is not verified within a certain time frame (e.g., before the time limit expires), the digital asset y can be reclaimed by the author of the PRNG transaction 902 or, in some embodiments, by another party via a refund transaction similar to the refund transaction 704 described in FIG. 7.

[0106] In the puzzle solving technique of example embodiment 900, the puzzle solution 908 to the puzzle 910 is unknown by the parties to the transaction at the time the PRNG transaction 902 is created. In some embodiments, the PRNG transaction 902 is associated with a dividend (e.g., a portion of a digital asset) that is transferred to a first party that provides the puzzle solution 908, providing the parties with a reason to attempt to discover the puzzle solution 908 to the puzzle 910. In some cases, the dividend is a dividend external to the blockchain (e.g., real currency). In other cases, the dividend is a portion of a digital asset y. In yet other cases, the dividend is a portion of a digital asset of yet another transaction. In some embodiments, the dividend is greater than the digital asset y to provide a reason to reveal the puzzle solution 908.

[0107] In some embodiments, puzzle 910 is an algorithm having a series of operations, such as a series of operation codes in a scripting language, that when executed on one or more inputs returns an indication of TRUE or FALSE. For example, in some embodiments, if puzzle solution 908 is a valid solution to puzzle 910, execution of the locking script of PRNG transaction 902 that includes puzzle 910 will evaluate to TRUE. However, in some embodiments, if puzzle solution 908 is not valid, execution of the locking script will evaluate to FALSE. A constraint of puzzle solving techniques is that puzzle solution 908 for puzzle 910 in this embodiment is unknown or not determinable at the time puzzle 910 is created. In some instances, puzzle 910 is computationally complex (e.g., involving a significant amount of time and / or processing power exceeding a threshold) such that it is unlikely that a solution to the puzzle will be determinable before a predetermined time after creation of PRNG transaction 902.

[0108] An example of a puzzle 910 is a proof-of-work function such as a cryptographic hash of a future block header of the blockchain at a particular time. Because the further into the future the particular time is, the more difficult it is to predict future block headers of the blockchain, it is highly unlikely that a puzzle solution 908 to puzzle 910 would be known by the parties to the transaction at the time the PRNG transaction 902 is created, and the payoff is related to providing proof-of-work. Note that the future block header can be specified in a variety of ways. For example, the solution could be the hash of the first block header created after a specified date / time in the future. As another example, the future block header could be specified as the first future block header that contains a predetermined number of transactions in the block. Thus, a proof-of-work puzzle of future block headers is an example of satisfying the constraints of a puzzle-solving technique.

[0109] Future access to block headers can be enforced by implementing constraints on the unlocking script's data, such as requiring the unlocking script to include a block header, a blockchain, or a chain of block headers. By implementing such constraints on the unlocking script's data, and by injecting such data into the unlocking script at runtime, transactions can be based on aspects of the blockchain. For example, a block header can be included as data in the unlocking script of a potential seed transaction, and a sequence of operation codes can be executed in the unlocking script to verify that the data is a valid block header (e.g., the size of the script is 90 bytes, an n-bit field of the data is equal to or greater than the blockchain's difficulty, and the SHA256 is less than or equal to a target value), such a script is shown in Table 1 below.

[0110] Table 1: [Table 1]

[0111] In some embodiments, the seed transaction 904 is a transaction created to provide a value, in the form of a puzzle solution 908, to the PRNG of the PRNG transaction 902 locking script that can be used to derive a seed. In some embodiments, the puzzle solution 908 is a value that, when provided as an input to the puzzle 910 by the unlocking script of the seed transaction 904, causes the locking script of the PRNG transaction 902 to evaluate to TRUE as a result of execution. Providing a seed to the PRNG further causes execution of the PRNG to generate a random number. In embodiments, solving the puzzle 910 is associated with a payout, such as at least a portion of the digital assets associated with the PRNG transaction 902, as a reason for revealing the solution. In this manner, a solver of the puzzle 910 is given a reason to avoid withholding the solution 908, because doing so increases the likelihood that someone else will solve the puzzle 910 and be the first to claim the payout.

[0112] 10 is a flow chart illustrating an example process 1000 for generating random numbers according to various embodiments of the puzzle-solving techniques of the present disclosure. All or a portion of process 1000 (or any other processes described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems that are comprised of executable instructions and / or other data and may be implemented as executable instructions collectively running on one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on a magnetic, optical, or flash medium).

[0113] For example, all or a portion of process 1000 may be performed by one or more computing devices (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device, such as computing device 1200 of FIG. 12). Process 1000 includes a series of operations in which a PRNG transaction including a puzzle is verified, and a seed transaction causes a seed to be provided to the PRNG in a locking script of the PRNG transaction. The execution of the PRNG generates a pseudorandom number. Constraints are imposed on the transaction based on the generated pseudorandom number.

[0114] At 1002, a PRNG transaction, such as PRNG transaction 902 of FIG. 9, is validated by validating nodes in the blockchain network. In embodiments, the PRNG transaction is a puzzle, similar to puzzle 910, that has an unknown solution at the time of the PRNG transaction's creation. For example, in some embodiments, the solution to the puzzle includes data that is not available or determinable until a predetermined amount of time has passed since the PRNG transaction's creation. At 1004, after the PRNG transaction is committed to the blockchain network, a seed transaction that includes the solution to the puzzle in the unlocking script (e.g., puzzle solution 908) is obtained by the same or a different validating node in the blockchain network.

[0115] At 1006, the same or a different validating node executes the seed transaction's unlocking script, causing the solution to be made available as input to the PRNG transaction's locking script. The validating node then executes the PRNG transaction's locking script, which takes the solution as input and derives a value based on the solution available by the PRNG to generate a pseudorandom number. At 1008, the pseudorandom number is used to affect the constraints of the PRNG transaction's locking script. That is, the transfer of control of the digital asset associated with the PRNG transaction is constrained in some manner based on the pseudorandom number generated by the PRNG of the PRNG locking script, such as in the manner described in connection with FIG. 11 (e.g., the pseudorandom number of the signature is accepted, the signature is accepted as valid based in part on whether the pseudorandom number is within a predetermined range of values, whether a pseudorandom amount of the digital asset is transferred, etc.). It should be noted that one or more of the operations performed at 1002-08 may be performed in various orders and combinations, including in parallel.

[0116] FIG. 11 illustrates an example 1100 of how the PRNG of the embodiments described in this disclosure may be implemented. Specifically, FIG. 11 illustrates an example locking script for a PRNG transaction 1102 that randomly generates one of two outcomes as a result of being seeded in the manner described in the full-time embodiment. Note that while FIG. 11 only illustrates two possible outcomes, the actual number of possible outcomes and the probability of each outcome may be determined by the author of the PRNG transaction 1102 and encoded in the locking script of the PRNG transaction 1102. Thus, there may be many possible outcomes and probabilities. In the first possible outcome illustrated in the example 1100, the random outcome 1106A is that a first transaction 1104A attempting to unlock the UTXO of the PRNG transaction 1102 is successfully verified, but a second transaction 1104B attempting to unlock the UTXO of the PRNG transaction 1102 is unsuccessful. In a second possible outcome, the random result 1106B is that the first transaction 1104A attempting to unlock the UTXO of the PRNG transaction 1102 is unsuccessful in validating, but the second transaction 1104B attempting to unlock the UTXO of the PRNG transaction 1102 is unsuccessful in validating.

[0117] In some embodiments, PRNG transaction 1102 is similar to PRNG transaction 602 or PRNG transaction 902 described in connection with Figures 6 and 8, respectively. In some embodiments, first and second transactions 1104A-04B are similar to seed transaction 604 or seed transaction 904 of Figures 6 and 9. That is, each of first and second transactions 1104A-04B may include one or more solutions to one or more puzzles included in the locking script of PRNG transaction 1102. However, because the seed for the pseudorandom number generator is derived from the solution provided to the locking script, the outcome (in example 1100, a determination that the transaction was successfully verified) is pseudorandom, even though first transaction 1104A and second transaction 1104B may include the same solution. For example, a locking script can be coded to accept Alice's signature for values ​​from the pseudorandom number generator greater than 5, and Bob's signature for values ​​from the pseudorandom number generator less than or equal to 5.

[0118] In some embodiments, the random results 1106A-06B reflect the results of a RPNG of a locking script of a PRNG transaction 1102 seeded with one or more puzzle solutions. The following table shows some examples of using random numbers generated by a RPNG of a locking script to determine a set of constraints. Table 2 shows an example of using a random number generator of the type described in this disclosure to determine a set of constraints.

[0119] Table 2: [Table 2]

[0120] In the above table, a random number is generated based on a seed (e.g., a value is derived from a value in stack memory after execution of the unlocking script) and is constrained to a value between 1 and 3 by performing a modulus 3 operation and adding 1. With the random number in the stack, the OP_CHECKMULTISIG operation checks for a signature number equal to the random number in the stack. Table 3 shows another example of utilizing a random number generator of the type described in this disclosure to determine a set of constraints.

[0121] Table 3: [Table 3]

[0122] In the above table, as in the previous script, a random number is generated based on a seed. In this case, the value is restricted to the range 0 or 1. If the random number is 1, a check is made to check for a valid signature of Alice (e.g., associated with PubK A), if the random number is 0, a check is made to check for a valid signature of Bob (e.g., associated with PubK B).

[0123] In the context of describing the disclosed embodiments, unless otherwise indicated, it should be noted that the use of language referring to executable instructions (also referred to as code, applications, agents, etc.) that perform tasks that "instructions" do not normally perform on their own (e.g., transmitting data, performing calculations, etc.) indicates that the instructions are executed by a machine, thereby causing the machine to perform the particular tasks.

[0124] FIG. 12 is an exemplary simplified block diagram of a computing device 1200 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 1200 may be used to implement any of the systems shown and described above. For example, the computing device 1200 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 12, the computing device 1200 may include one or more processors 1202, which in embodiments are configured to communicate with and operably couple to a number of peripheral subsystems via a bus subsystem 1204. In some embodiments, these peripheral subsystems include a storage subsystem 1206, including a memory subsystem 1208 and a file / disk storage subsystem 1210, one or more user interface input devices 1212, one or more user interface output devices 1214, and a network interface subsystem 1216. Such a storage subsystem 1206 may be used for temporary or long-term storage of information.

[0125] In some embodiments, the bus subsystem 1204 provides a mechanism that allows the various components and subsystems of the computing device 1200 to communicate with each other as intended. Although the bus subsystem 1204 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem use multiple buses. In some embodiments, the network interface subsystem 1216 provides an interface to other computing devices and networks. The network interface subsystem 1216, in some embodiments, serves as an interface to receive data from other systems and to transmit data from the computing device 1200 to other systems. In some embodiments, the bus subsystem 1204 is used to communicate data such as details, search terms, etc.

[0126] In some embodiments, the user interface input devices 1212 include one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen integrated into a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 1200. In some embodiments, the one or more user interface output devices 1214 include a display subsystem, a printer, or a non-visual display, such as an audio output device. In some embodiments, the display subsystem includes a cathode ray tube (CRT), a flat panel device, such as a liquid crystal display (LCD) or a light emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 1200. One or more user interface output devices 1214 may be used to provide a user interface that facilitates user interaction, where such interaction is appropriate, with applications that execute the processes described, and variations thereof, for example.

[0127] In some embodiments, the storage subsystem 1206 provides a computer readable storage medium that stores basic programming and data structures that provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which in some embodiments when executed by one or more processors, provide functionality of one or more embodiments of the present disclosure, are stored in the storage subsystem 1206 in some embodiments. These application modules or instructions can be executed by one or more processors 1202. In various embodiments, the storage subsystem 1206 additionally provides a repository for storing data used in accordance with the present disclosure. In some embodiments, the storage subsystem 1206 includes a memory subsystem 1208 and a file / disk storage subsystem 1210.

[0128] In an embodiment, memory subsystem 1208 includes multiple memories, such as main random access memory (RAM) 1218 for storage of instructions and data during program execution, and / or read-only memory (ROM) 1220 in which permanent memory may be stored. In some embodiments, file / disk storage subsystem 1210 provides non-transient, persistent storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0129] In some embodiments, computing device 1200 includes at least one local clock 1224, which in some embodiments is a counter that represents the number of ticks that have occurred since a particular starting date and in some embodiments is integrally located within computing device 1200. In various embodiments, local clock 1224 is used to synchronize data transfers among computing device 1200's processors and subsystems contained therein with a particular clock pulse and can be used to coordinate synchronization processes between computing device 1200 and other systems in a data center. In another embodiment, the local clock is a programmable interval timer.

[0130] The computing device 1200 can be of any of a variety of types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 1200 can, in some embodiments, include other devices that can be connected to the computing device 1200 through one or more ports (e.g., USB, headphone jack, lighting connector, etc.). In embodiments, such devices include ports configured to receive fiber optic connectors. Thus, in some embodiments, the device is configured to convert optical signals into electrical signals, which are transmitted through ports that connect the device to the computing device 1200 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device shown in FIG. 12 is intended only as a specific example for purposes of illustrating a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 12.

[0131] The specification and drawings should therefore be interpreted in an illustrative rather than restrictive sense. However, it will be apparent that various modifications and changes can be made thereto without departing from the scope of the invention as set forth in the appended claims. Similarly, other variations are within the scope of the disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown in the drawings and have been described in detail above. It is to be understood, however, that there is no intention to limit the invention to the particular form or forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents within the scope of the invention as defined in the appended claims.

[0132] The use of the terms "a" and "an" and "the" and similar references in the context of describing the disclosed embodiments (particularly in the context of the claims that follow) shall be construed to cover both the singular and the plural unless otherwise specified or the context contradicts. Terms such as "comprises," "has," "includes," and "comprises" shall be construed as open-ended terms (i.e., meaning "including, but not limited to") unless otherwise indicated. The term "connected," when unmodified and referring to a physical connection, shall be construed as being partially or wholly contained within, attached to, or joined together, even if there is some intervening space. Recitations of ranges of values ​​in this disclosure, unless otherwise indicated, are merely intended to serve as a shorthand method of referring individually to each individual value falling within the range, and each separate value is incorporated into the specification as if it were individually set forth. Use of the term "set" (e.g., "set of items") or "subset" should be construed as a non-empty collection containing one or more members, unless otherwise indicated or contradicted by context. Furthermore, unless otherwise indicated or contradicted by context, the term "subset" or "subset" of a corresponding set does not necessarily refer to a proper subset of the corresponding set; a subset and a corresponding set may be equivalent.

[0133] Phrases of the form "at least one of A, B, and C" or conjunctions such as "at least one of A, B, and C" are understood in their general usage context to indicate that an item, term, etc. may be either A or B or C, or any non-empty subset of the set of A, B, and C, unless specifically stated otherwise or clearly contradicted by context. For example, in the exemplary example of a set having three members, the conjunctions "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such conjunctions are not generally intended to imply that a given embodiment requires that there be at least one A, at least one B, and at least one C, respectively.

[0134] The operations of the described processes may be performed in any suitable order unless otherwise indicated or clearly contradicted by context. The described processes (or variations and / or combinations thereof) may be performed under the control of one or more computer systems comprised of executable instructions and may be implemented in hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) collectively operating on one or more processors. In some embodiments, the code may be stored on a computer-readable storage medium, e.g., in the form of a computer program including a plurality of instructions executable by one or more processors. In some embodiments, the computer-readable storage medium is non-transitory.

[0135] The use of any and all specific examples given, or exemplary language (e.g., "etc.") is intended merely to better illuminate embodiments of the invention and does not impose limitations on the scope of the invention unless otherwise required. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0136] The embodiments of the present disclosure have been described, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments will become apparent to those skilled in the art upon reading the above description. The inventors anticipate that those skilled in the art will use such variations as appropriate, and the inventors intend for the embodiments of the present disclosure to be carried out differently than specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by applicable law. Moreover, any combination of the elements described above in all possible variations thereof is encompassed within the scope of the present disclosure unless otherwise indicated or clearly contradicted by context.

[0137] All references, including cited publications, patent applications, and patents, are herein incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and to the same extent as if each reference was fully set forth.

[0138] It should be noted that the above-described embodiments illustrate rather than limit the invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as set forth in 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 "comprises" 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, "comprises" means "comprises or consists of" and "comprises" means "comprises or consists of". A reference to an element alone does not exclude a reference to a plurality of such elements, and vice versa. The invention can 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, these several means can be embodied by one and the same item of hardware. The mere fact that certain items are recited in mutually different dependent claims does not indicate that a combination of these items cannot be usefully employed.

[0139] summary The techniques described and suggested in this disclosure extend the functionality of blockchain without disrupting the blockchain's ability to guarantee the integrity of data stored in the blockchain data structure. For example, the techniques described in this disclosure advance the field of computing, specifically the field of smart contracts, by providing greater flexibility for implementing constraints on transactions. Furthermore, the techniques described and suggested in this disclosure can advance the functionality of blockchain networks by enabling pseudo-random number generation in scripts. Furthermore, the techniques described and suggested in this disclosure are necessarily rooted in computer technology to overcome problems specifically created by the lack of random number generation capabilities in blockchain script operation codes.

[0140] [Note] (Appendix 1) 13. A computer-implemented method comprising: Validating a third transaction including the first puzzle and the second puzzle in a third locking script, the third transaction including: The first puzzle is included in a first transaction in a first locking script that limits the transfer of control of a first digital asset according to a first condition that can be satisfied by a solution to the first puzzle; The second puzzle is included in a second transaction in a second locking script that limits the transfer of control of a second digital asset according to a second condition that can be satisfied by a solution to the second puzzle; The first transaction and the second transaction are committed to a blockchain; and the third transaction relating to a third digital asset; generating a pseudorandom number based at least in part on the solution to the first puzzle and the solution to the second puzzle; transferring control of the third digital asset based at least in part on the pseudo-random number; The method according to claim 1, (Appendix 2) the first transaction is made by a first party; and 2. The method of claim 1, wherein the second transaction is created by a second party different from the first party. (Appendix 3) 3. The method of any one of claims 1-2, wherein the first party has access to a solution to the first puzzle prior to making the first transaction. (Appendix 4) the first locking script includes a time constraint; subject to the time constraint being satisfied, validation of the transaction including the solution to the first puzzle triggers a transfer of control of the first digital asset to a first entity; and The method of any one of appendixes 1-3, wherein, provided the time constraint is not satisfied, validation of the penalty transaction causes control of the first digital asset to be transferred to a second entity different from the first entity. (Appendix 5) 5. The method of claim 4, wherein the time constraint is that a solution to the first puzzle is revealed before a time limit is exceeded. (Appendix 6) 6. The method of any one of claims 1-5, wherein verifying the pseudo-random number generated transaction is performed before the first condition and the second condition are satisfied. (Appendix 7) 7. The method of any one of claims 1-6, wherein the first puzzle is a cryptographic hash puzzle. (Appendix 8) the first puzzle is a set of operation codes in a locking script of the first transaction; and 8. The method of any one of claims 1-7, wherein execution of the set of operation codes evaluates to true as a result of receiving as input a solution to the first puzzle. (Appendix 9) 9. The method of any one of claims 1-8, wherein solving the first puzzle and the second puzzle is computationally more difficult than verifying a solution to the first puzzle and a solution to the second puzzle. (Appendix 10) 10. The method of any one of claims 1-9, wherein the step of generating a pseudo-random number includes deriving a seed value based at least in part on the solution to the first puzzle and the solution to the second puzzle. (Appendix 11) 11. The method of any one of claims 1-10, further comprising the step of verifying a seed transaction including a solution to the first puzzle and a solution to the second puzzle. (Appendix 12) The step of transferring control of the third digital asset includes: that, under the condition that the pseudo-random number is a first value, validation of the seed transaction is successful; and 12. The method of any one of claims 1-11, further comprising: under a condition that the pseudo-random number is a second value different from the first value, verification of the seed transaction is unsuccessful. (Appendix 13) 13. The method of claim 12, wherein the seed transaction unlocking script includes a solution to the first puzzle and a solution to the second puzzle. (Appendix 14) The method of any one of claims 1-13, further comprising the step of verifying a refund transaction to return control of the third digital asset to the entity that created the third transaction. (Appendix 15) 15. The method of claim 14, wherein the step of validating the refund transaction occurs under the condition that successful validation of a seed transaction containing the solution to the first puzzle and the solution to the second puzzle has not occurred within a predetermined period of time. (Appendix 16) A processor; and memory containing executable instructions; wherein the executable instructions, when executed by the processor, cause the system to perform a method as recited in any one of claims 1-15. (Appendix 17) A non-transitory computer-readable storage medium having executable instructions stored thereon which, when executed by a processor of a computer system, cause the computer system to perform at least one of the methods described in any one of claims 1-15.

Claims

1. 1. A computer-implemented method comprising: obtaining a first puzzle and a second puzzle from a first and a second commitment transaction, respectively; combining the first and second puzzles and incorporating it into a locking script of a third blockchain transaction; committing the third transaction to the blockchain; obtaining a solution to the first puzzle and a solution to the second puzzle; incorporating the first and second solutions into an unlocking script of a seed transaction and converting the solution into a seed value of an input to the third transaction for generating pseudo-random numbers; imposing a constraint on the third transaction based on the pseudo-random number; The method includes:

2. the first commitment transaction is made by a first party; and The method of claim 1 , wherein the second commitment transaction is made by a second party different from the first party.

3. The method of claim 2 , wherein the first party has access to a solution to the first puzzle prior to making a first transaction.

4. The method of any one of claims 1 to 3, wherein the locking script of the third transaction includes a time constraint.

5. 5. The method of claim 4, wherein validation of a penalty transaction causes a return of a first digital asset associated with the third transaction if the time constraint is not satisfied.

6. The method of claim 4 , wherein the time constraint is that solutions to the first and second puzzles are revealed before a time limit is exceeded.

7. The method of any one of claims 1 to 6, wherein the first puzzle is a cryptographic hash puzzle.

8. the first puzzle being a set of operation codes in a locking script of a first transaction; and A method according to any preceding claim, wherein execution of the set of operation codes evaluates to true as a result of receiving as input a solution to the first puzzle.

9. The method of any one of claims 1 to 8, further comprising the step of validating a seed transaction including a solution to the first puzzle and a solution to the second puzzle.

10. The method of any one of claims 1-9, wherein transferring control of the third digital asset is restricted in a pseudo-random based manner.

11. A processor; and a memory containing executable instructions; 11. A system comprising: said executable instructions, upon execution by said processor, causing said system to perform a method according to any one of claims 1-10.

12. A non-transitory computer-readable storage medium having executable instructions stored thereon, the executable instructions, when executed by a processor of a computer system, causing the computer system to perform at least one of the methods recited in any one of claims 1-10.

Images