COMPUTER-IMPLEMENTED METHOD AND SYSTEM FOR PSEUDO-RANDOM DATA GENERATION - Patent application

Abstract

A method for pseudo-randomly generating data is disclosed. The method comprises: generating first data items (s1', s2'...s) from a plurality of first participants; N receiving the second data (Σ i s i and combining the first data items to generate a third data item (Σ i s i '), and the one-way function is adapted to receive the input data and generate output data based on the input data, wherein the input data is not inferable from the output data and the one-way function.

Description

[Technical field]

[0001] The present disclosure relates generally to pseudorandom data generation, and more specifically to pseudorandom number generation. The present disclosure is particularly suited for use in, but not limited to, pseudorandom number generation for blockchain transactions. [Background technology]

[0002] In this document, the term "blockchain" is used to include all forms 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 best-known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, Bitcoin may be referred to herein, but it should be noted that this disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of this disclosure. The term "user" may be used herein to refer to a person or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system of blocks, which in turn are made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, so that blocks become strung together and create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions have small programs, known as scripts, embedded in their inputs and outputs that specify how and who can access the transaction's outputs. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore implementing new systems using both the cryptographic security system that Bitcoin is based on, and the data that can be stored on the blockchain. It would be highly advantageous to be able to use blockchain for automated tasks and processes that are not limited to the cryptocurrency world. Such solutions would be able to utilize the benefits of blockchain (e.g., tamper-proof permanent record of events, distributed processing, etc.) while broadening their range of applications.

[0006] The international lottery industry continues to grow, particularly due to the development of internet and mobile device applications.

[0007] The main issues that worry users, especially in online lottery platforms, are related to the fairness and trustworthiness of the service provider. When an online lottery is established by a third party, participants cannot be sure that the winning product exists, nor that the lottery itself has never been manipulated. In such lotteries, users have no guarantee that the process used to select the winner is random and secure.

[0008] One possible solution to the first of these problems, the existence of a lottery fund, is provided by the blockchain. If the lottery is structured as a multi-party transaction on the blockchain, all participants can verify that the accumulated prize funds exist, and the nature of the blockchain means that there is an immutable record of that fact on a distributed public ledger. This use of the blockchain also solves several other problems, such as instantaneous payout of lottery funds, unconstrained participation across borders, and the ability to monitor the funds involved in the lottery.

[0009] It then remains to find a way to ensure randomness and security in the selection of winners in a blockchain-based lottery. By using blockchain as a platform for such applications, it is hoped that both major problems inherent in online lotteries will be avoided.

[0010] Among the latest examples of blockchain-based lottery games, it is worth mentioning Quanta, published in K. Farris, S. Ormond-Smith, L. Hills, Quanta Whitepaper (2018), https: / / www.quantaplc.im / Quanta.pdf, which runs on the Ethereum blockchain and TrueFlip, published in N. Parkhomenko, K. Katsev, TrueFlip Whitepaper (2016), https: / / trueflip.io / TrueFlip%C2%A9%20Whitepaper.pdf?new. Randomness in the TrueFlip protocol is generated by using verified block hashes, which are built into the (open source) algorithm for generating winning numbers.

[0011] Despite the presence of elements of decentralization and transparency, such as the open source code used to randomly generate the winning numbers, much of the process is controlled by the entity that invented the TrueFilp protocol and involves a large number of off-chain transactions.

[0012] In general, one of the main problems that remains to be solved is that of finding a trusted and verified source of entropy and a cryptographically secure random number generator that is compatible with blockchain operations and scripts.

[0013] It can be recalled that new opcodes such as the proposed "OP_DETERMINISTICRANDOM" published in P. Strateman, New Opcodes (2016), https: / / www.elementsproject.org / elements / opcodes / , could be used to generate random numbers in scripts. These solutions presented now do not eliminate the problem, but rather provide incentives for good behavior, and said incentives can be adjusted.

[0014] However, setting aside the specific technical issues with the proposed solutions, all of them are fundamentally problematic in that they require the introduction of new opcodes into the existing Bitcoin script library, which is undesirable as it increases the attack surface of the underlying blockchain and weakens the case for using it as a platform for lotteries and games all together. [Prior art documents] [Patent documents]

[0015] [Patent Document 1] International Publication No. 2017 / 145016 [Non-patent literature]

[0016] [Non-Patent Document 1] K. Farris, S. Ormond-Smith, L. Hills, Quanta Whitepaper (2018), https: / / www.quantaplc.im / Quanta.pdf [Non-Patent Document 2] N. Parkhomenko, K. Katsev, TrueFlip Whitepaper(2016), https: / / trueflip.io / TrueFlip%C2%A9%20Whitepaper.pdf?new [Non-Patent Document 3] P. Strateman, New Opcodes (2016), https: / / www.elementsproject.org / elements / opcodes / [Non-Patent Document 4] S. Blake-Wilson, D. Brown, P. Lambert, Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), Network Working Group (2002), https: / / tools.ietf.org / html / rfc3278 Summary of the Invention [Problem to be solved by the invention]

[0017] It is therefore desirable to provide a method for generating random numbers for use on a blockchain.

[0018] Such an improved solution has now been devised. [Means for solving the problem]

[0019] Thus, in accordance with the present disclosure there is provided a method as defined in the accompanying claims.

[0020] According to the present disclosure, there may be provided a method for pseudo-randomly generating data, the method comprising: receiving first data from each of a plurality of first participants, the first data comprising at least one respective first data item; combining a plurality of said first data items to generate second data; and applying at least one one-way function to at least a portion of the second data to generate third data, the or each one-way function being adapted to receive input data and generate output data based on the input data, the input data being not inferable from the output data and the one-way function.

[0021] By applying at least one one-way function to the data from multiple first participants, this provides the advantage that the third data cannot be predicted by any of the first participants and is therefore pseudo-random. For blockchain transactions, this provides the further advantage of allowing pseudo-random data / random number generation without significant computational overhead.

[0022] The first data may be received by the first participant in an encrypted form.

[0023] This provides the advantage of increased security by providing secure communications.

[0024] The method may further comprise the step of receiving fourth data comprising at least one respective fourth data item from each of a plurality of said first participants, the or each said fourth data item being generated by applying at least one one-way function to the or each respective first data item corresponding to said first participant.

[0025] This provides the advantage of making it possible to increase security by verifying that the first data item has not been altered.

[0026] The method may further comprise transmitting the fourth data to a plurality of the first participants.

[0027] This provides the advantage of allowing the first participant to independently verify that the first data has not been altered.

[0028] At least one of the one-way functions may be a hash function.

[0029] At least one of said one-way functions may associate the public and private keys of each public-private key pair of a cryptosystem.

[0030] The cryptosystem may be an elliptic curve cryptosystem.

[0031] For blockchain transactions, this brings the advantage of allowing hash functions available for other purposes to be easily used.

[0032] At least one of the first data items may include at least a portion of a respective first digital signature.

[0033] This provides the advantage that it allows random integer generation by a digital signature algorithm to be used, thereby also allowing randomness to be added to the generation of the first data item in addition to the randomness generated by the method defined above.

[0034] At least one of the first data items may include at least a portion of a respective first digital signature based on a private key and an ephemeral key.

[0035] The method may further comprise receiving at least one respective second digital signature from each of a plurality of said first participants, said second digital signature being signed using the same private key as the corresponding said first digital signature.

[0036] This has the advantage that it allows verification to be made that both the first and second digital signatures were signed using the same private key, thereby allowing verification that the first data has not been altered. Also, in the case of blockchain transactions, signature verification can be easily performed using a digital signature algorithm in the script.

[0037] The method may further comprise receiving fifth data comprising a respective fifth data item from each of a plurality of said first participants, said fifth data item being part of a corresponding said first digital signature, said first digital signature being constructed by combining said fifth data item with said corresponding said first data item.

[0038] The method may further comprise transmitting the fifth data to a plurality of the first participants.

[0039] This provides the advantage of allowing each first participant to independently verify that the first data item has not been altered.

[0040] At least one of the fifth data items may include at least a portion of a respective first digital signature based on the ephemeral key.

[0041] This provides the advantage of being easily generated by a digital signature algorithm in the blockchain script, further increasing security by adding further randomness to the generation of the first data.

[0042] The method may further comprise the step of transmitting the first data to a plurality of the first participants subsequent to generating the third data.

[0043] This provides the advantage of allowing the mechanism for generating the third data to be verified.

[0044] The third data may form part of a blockchain transaction redeemable by a script including said first data item.

[0045] This has the advantage that when the script is executed, it automatically makes the first data item public on the blockchain, thereby making the process of generation of the third data automatically verifiable.

[0046] Execution of the script may regenerate the third data item from the first data item.

[0047] This provides the advantage of efficient validation of the process generating the third data.

[0048] The third data may be generated by a plurality of said one-way functions.

[0049] This has the advantage of increasing security.

[0050] The third data may be generated by repeated application of at least one of said one-way functions.

[0051] This has the advantage of increasing security.

[0052] The third data may be generated by a plurality of second participants.

[0053] This provides the advantage of increased security, since a single trusted second participant provides sufficient randomness to allow successful execution of the process.

[0054] The method may further comprise the step of selecting an item from the plurality of items based on the third data.

[0055] The selection may comprise selecting a public key of a public-private key pair of a cryptosystem, at least one of the participants having access to the private key of the pair.

[0056] The present disclosure also provides a system, the system comprising: A processor; a memory including executable instructions that, upon execution by a processor, cause the system to perform any embodiment of the computer-implemented methods described herein; Equipped with.

[0057] The present disclosure also provides a non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least embodiments of the computer-implemented methods described herein.

[0058] These and other aspects of the present disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter, which will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0059] [Figure 1] FIG. 1 is a diagram of a Bitcoin script for pseudo-randomly generating numbers using a method embodying the present disclosure. [Diagram 2] FIG. 1 is a diagram of an initiation transaction for a blockchain lottery embodying the present disclosure. [Diagram 3] FIG. 1 is a diagram of a blockchain lottery oracle transaction embodying the present disclosure. [Figure 4] FIG. 13 is a diagram of a blockchain lottery oracle transaction of a further embodiment of the present disclosure. [Diagram 5] FIG. 13 is a diagram of a blockchain lottery winnings payout transaction embodying the present disclosure. [Figure 6]FIG. 5 is a diagram of a Bitcoin script for refunding funds blocked by the oracle transaction of FIG. [Figure 7] FIG. 1 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0060] Randomness on the blockchain

[0061] In order to make it possible to put luck-based game algorithms into the Bitcoin script, it is desirable to come up with new ways to incorporate random processes into the blockchain. This means that the presented method must ensure the following properties of the random numbers to be generated and used in the script: (1) Unpredictability: The random numbers used to determine the outcome should not be predictable before funds are committed to a luck-based event. (2) Deterministic: The random numbers generated must be reproducible from the same input at all times after the initial generation. (3) Verifiable: It must be possible for all nodes to reproduce and verify the chosen random numbers so that all nodes agree on the numbers generated.

[0062] The method proposed in this application ensures that all of the above properties are maintained in the generation of random numbers on the blockchain. The term "Bitcoin" is used herein to include all variants of protocols derived from the Bitcoin protocol.

[0063] Basic Concepts

[0064] Pseudorandom number generator

[0065] Random numbers generally fall into two categories: truly random or pseudorandom. The distinction to be made is that true randomness is very difficult to achieve and usually relies on the acts of nature or electronic noise.

[0066] Alternatively, the pseudorandomness can be calculated by using a pseudorandom number N k A single high-entropy seed value V is used to initialize the algorithm for generating sequences of Seed (truly random), where k is a random number generator V Seed →(N1,N2,…,N k ) period.

[0067] In most practical applications, pseudorandom number generators are used where their properties are suitable. If randomness is built into the blockchain, the mechanism for pseudorandom number generation is also required to be cryptographically secure. This is by usual definition called a CSPRNG (Cryptographically Secure Pseudorandom Number Generator).

[0068] In general, CSPRNGs are deterministic, so V Seed Such a generator is suitable for the purposes of blockchain applications, except for two main problems:

[0069] First, a long algorithm needs to be built from a known CSPRNG into the Bitcoin scripting language, which adds computational overhead and limits the opportunities for algorithmically generated random numbers to work.

[0070] In addition, the seed value V has sufficient entropy to be classified as truly random. Seed There is still the question of whether it is possible to provide such a seed. Currently, there is no mechanism for generating such a seed within the script, nor for using an external seed as input to the redemption script in such a way that requirement (1) that the generated random numbers are unpredictable is satisfied.

[0071] Hash Functions

[0072] The construction of a blockchain relies on the use of hash functions and their inherent properties. In the case of Bitcoin transactions, a hash function H takes an arbitrary data structure X and converts it into a 256-bit number

number

[0073]

number

[0074] Please appreciate the fact that hash functions such as SHA-256 act as one-way random oracles: if a hash Y is computed from a preimage X that is unknown to a user, then it is computationally hard for a user to discover X.

[0075] The property of hash functions is that the hashes of two 256-bit data structures that differ in the value of only a single bit can be treated as completely unrelated -- in other words, as long as the user does not know the entire preimage, the hash value behaves as a truly random number with respect to the user.

[0076] This means that, under the assumption that no single party has full control over the input preimage X, it is possible to simply take the hash value Y, or some function of it, and treat it as the single random number R that is intended to be generated. For unknown X, R:= R and:=Y=H(X)

[0077] Extending this to a (k+1)-random sequence of random numbers, S R may be generated by repeated hashing of an initial random number R0 using the same arguments. R0=H(X0); R1=H(R0); R k =H(R k-1 ) S R =(R0,R1,…,R k )

[0078] Since hash functions are deterministic, any party can derive a sequence S with only knowledge of the specific hash function used and an initial preimage X0 that serves as a seed. R Please note that the entire document may be reproduced.

[0079] If this initial pre-image is published when the random sequence is generated, then every node may independently verify that the sequence corresponds to this pre-image.

[0080] It is then clear that a hash function may be used to generate a random number sequence to be used in a script that satisfies criteria (1) and (2) above, but only if the initial preimage X0 cannot be manipulated in its entirety by any single party involved in generating the random numbers.

[0081] Alternative One-Way Functions

[0082] In general, the term "hash function" is used in this application to refer to a specific type of one-way function within a broader classification of functions, since hash functions have existing opcodes in the Bitcoin script. However, it is conceivable that alternative one-way functions could be used in place of any instance of a hash function herein. Two examples are: 1. Elliptic Curve (EC) Point Multiplication - The function used to generate an EC public key from a private key, E(x)=x·G, where G is the base point of the elliptic curve and "·" is the EC point multiplication operator. It is a one-way function because computing E(x) given x is easy, but determining G given E(x) is computationally hard. 2. Rabin Function - Function R(x)=x2 mod N, where p and q are both primes, and N=pq. Finding the square R(x) modulo N is easy, but finding the square root ±x given R(x) and N is as hard as factoring N to find p and q, which is computationally intractable.

[0083] Digital Signature

[0084] Your private key S A Consider a player Alice who wishes to create a digital signature for a message hash H(m) using the public key P that is associated with her private key according to ECC (Elliptic Curve Cryptography, using elliptic curves as defined by the secp256k1 standard). A where G is the base point of an elliptic curve of degree n. P A =S A G

[0085] There are two components of a digital signature that need to be created: r and s. Alice will generate a random

[0086]

number

[0087] Then, we generate an ephemeral key as (R x ,R y )=k G r=R x It is derived as:

[0088] The signature part s is then derived from r in combination with Alice's private key, Alice's hashed message, and the ephemeral key: s=k -1 (H(m)+S A *r) mod n It is derived as:

[0089] Concatenating r and s creates a data structure known as the ECDSA digital signature of the message hash. Sig P A =(r,s)

[0090] Given the values ​​r and s separately, a complete signature may be constructed in the Bitcoin script using the operator OP_CAT. When the signature is reconstructed, it must be in the standard DER (Distinguished Encoding Rules, as disclosed in S. Blake-Wilson, D. Brown, P. Lambert, Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), Network Working Group (2002), https: / / tools.ietf.org / html / rfc3278) format [Appendix 5.1] to be used in the Bitcoin script. This becomes important when using the signature method discussed below to generate random numbers.

[0091] method

[0092] There are three common variants of proposed methods for generating random numbers using blockchain, each of which involves multiple parties participating in creating the random numbers.

[0093] The first method uses a combination of hash preimages to generate secure random numbers, while the second method uses a combination of s components from several signatures. Finally, a hybrid of the two methods is proposed.

[0094] In each case, a secure random integer R N ∈{0,N-1}.

[0095] Hashing Method

[0096] There are N first participants in the form of players, each of whom has their own unique public hash value Y i =H(X i ), and each player creates his own unique secret preimage X i Consider that it is prescribed to choose a first data item of the form: The properties of hash functions allow the assumption that no player can deduce another preimage given knowledge of the public hash value.

[0097] The player then receives the secret preimage X in the form of an oracle. i to the second participant (the method generalizes to both types of oracles, blind or otherwise). This may be done, for example, via secret value sharing techniques as outlined in WO 2017 / 145016, but any method that provides a secure channel or mechanism for communicating the pre-image to the oracle may be used.

[0098] The oracle then generates a random number R via the following method: N Generate.

[0099] 1. The oracle calculates Y for each preimage provided by each player. i =H(X i ) to verify that

[0100] Recall that the hash values ​​are already public before the preimage is sent to the oracle. This ensures that the oracle is provided with the correct preimage as originally provided by each player. On the blockchain, these public values ​​are immutable, so they cannot be changed by the players after they send the preimage.

[0101] This verification step ensures that the oracle does not proceed to generate random numbers until all players have supplied the oracle with their chosen secret preimages.

[0102] 2. Oracle is R N of

number

[0103] All N element preimage values ​​X i If and only if none of the players knows N Recall from above that is a random number for each individual player. In this method, all preimages are kept secret by the players and securely communicated to the oracle. This means that there is no way that a malicious party could possibly know all these inputs unless they had control over all the players involved. In this case, the adversary would only be able to manipulate the random numbers used only by themselves.

[0104] In all other scenarios with at least one genuine player, the described properties of hash functions allow an adversary to exploit R N This means that no one can manipulate the preimage X. This is true even when the adversary has control over all N-1 other players. Thus, there is no way for any party to affect the random numbers generated by this method in a way that could adversely affect another party. i Note that "+" addition is used in this example because it is easy to implement in Bitcoin script, but it is possible to use different operators in succession, such as concatenation, which is similar to the addition above.

[0105] Then, we have a random number R that is generated in such a way that (1) it is unpredictable by any of the parties involved in the process, and (2) it is reproducible via a deterministic process. N We will show below that the final requirement above, that the random numbers be verifiable, is also satisfied. N It may also be generated by an oracle by repeated hashing of

[0106] How to sign

[0107] Here, each of them has a signature Sig P i and a second signature Sig P whose s' component is kept secret. i A random value that forms part of r i Consider the first participant in an N-player format who publishes '. Sig P i =(r i ,s i ) Sig P i '=(r i ', s i ')

[0108] Both signatures are public key P i The same private key S i It is important that both signatures are signed using the same ECDSA standard mentioned above. P i =S i G

[0109] The player then reveals his secret s i ' Send a first data item in the form of a value to a second participant in the form of an oracle, again done securely, for example via a secret sharing method as outlined in WO 2017 / 145016, or otherwise.

[0110] The oracle then generates a random number R via the following method: N Generate.

[0111] 1. The Oracle i ', which is the Sig P i and verify that they correspond to the same entity. This second signature is then encoded using the DER standard as shown in Appendix 1. i 'Secret value s i' value. The oracle then applies the standard ECDSA signature verification algorithm to both signatures and verifies that they are consistent with the public key P i This ensures that another party can verify that a given r i 'Ensure that no one can influence the random number by providing your own unique signature for the value.

[0112] 2. Oracle is R N of

number

[0113] replacement Y i →P i and X i →s i ' is done, the similarity is clear and the comments presented in step 2 of the hashing method described above also apply in this case.

[0114] Like the hashing method described above, here we generate a random number R in a way that is unpredictable and verifiable to all parties involved. N is generated, satisfying criteria (1) and (2) outlined above.

[0115] It should be made clear that the signature method and the hash method are directly analogous to one another and share key properties of their respective methods for random number generation. Specifically, both methods use the X for the hash method and the signature method, respectively. i and s iIt requires that each user is responsible for generating a secret value, '. An added advantage of using the signature method here is that while the act of choosing the secret is already standardized under the ECDSA procedure, choosing an arbitrary hash preimage is not.

[0116] In the signing method, a secret value s is sent to the oracle. i The method to directly verify ' is to use the accompanying primary signature Sig P i =(r i ,s i ) to find the corresponding published value r i This verification is the only implicit verification in the hashing method.

[0117] R in scripts N Calculation

[0118] In both methods, the random number R N meets the requirements outlined above of being both (1) unpredictable and (2) deterministic. How the method of the present disclosure meets the third criterion that the random numbers be (3) verifiable is described in detail below.

[0119] This is R N This means that there must be a way for all network peers to independently verify that R N This is accomplished by requiring that the s itself be computed and used in the transaction's locking script. In this way, all previously secret s i 'A value is published on the blockchain as part of this script, which is calculated using the hash function Σ i s i This means that anyone can verify the randomness of the input by constructing a preimage of '. A script of the following form will generate the desired random integer R N It is proposed to be used to generate ∈{0,N-1}. <R N >=<s1'><s2'> … N '> OP_ADD…OP_ADD OP_HASH256 <n>OP_MOD Here, there are N-1 uses of the operator “OP_ADD” and N secret values.

[0120] In the application presented in this application, <R N > is used to refer to this script. Note that this script can be used for generalized secret values, including hash preimages, partial signatures, and combinations of these. Figure 1 shows how this script is used to generate random numbers.

[0121] A complete refund script for a transaction may include verifying that each preimage corresponds to the correct committed hash, that each private signature component combines with a public component to form an expected signature, and that each supplied value came from a correct player [Appendix 2].

[0122] Combined Methods

[0123] The methods presented so far are robust against malicious parties attempting to influence the outcome of the generated random numbers. However, there are many ways in which the hashing and signing methods may be extended and combined to increase the security and unpredictability of the generated random numbers.

[0124] The simplest combination of the two methods is that each player creates a hash value Y i and signature Sig P i , a random value r i ', and their public keys P i The oracle then publishes the random value

number

[0125] If it is instead desired to extend one of the two methods individually, multiple oracles may be called and the player may each generate multiple hash values ​​Y i or secondary r i For example, if two oracles are called using a hashing method, the random number R N teeth

number

[0126] By invoking several oracles, there is no risk that the oracles can somehow be corrupted by a malicious user. Extending this to multiple oracles reduces the risk that all the oracles will collude, at the expense of a larger computational and time overhead. Note that these methods ensure that only a single oracle needs to be authentic for random numbers to be generated securely and unpredictably.

[0127] Application Examples

[0128] Use cases are described for the method of random number generation described in this application. The first application is in the context of a blockchain lottery involving N players, considered in both scenarios with and without a party acting as the "house". The second application is to an N-sided Satoshi Dice game, where players participate in a simple game of chance with a house. More general uses of using blockchain to generate random numbers are possible.

[0129] wealth lottery

[0130] The associated public key P i Consider a group of N players, with i∈{1,N}, ∀i∈{1,N}. A lottery involving these players is constructed and the lottery fund is allocated to a randomly selected public key P W is locked to the owner.

[0131] The structure of the lottery is three transactions: (i) Start Transaction (ii) Oracle Transactions (iii) Lottery withdrawal transactions The lottery fund will be W It calls one oracle for secure generation of random numbers used to lock down

[0132] In such a lottery, each player is guaranteed to have an equal chance of winning N×x bitcoins with a probability of 1 / N, where x is the initial purchase value of the lottery ticket. Another possibility is that the "house" may be included as part of the lottery, allowing the winning party to collect the lottery fund if they do not claim their prize. In this case, each player has the possibility of winning r+(N×x) bitcoins with probability 1 / (N+1), where r is the house's purchasing contribution.

[0133] Start Transaction

[0134] 1. Each player contributes a common value of x Bitcoin to the initiating transaction as a purchase of a blockchain lottery ticket. This transaction has N inputs and 1 output and represents the digital point of sale of a blockchain lottery ticket for all participants.

[0135] 2. In addition to the purchase, each player includes as input the public values ​​present in the standard OP_DROP statement. This value depends on the random number generation method to be used.

[0136] In this implementation, since a signature method is used, the value supplied is a random value r i ' and this is that i 'Signature Sig P whose ingredients are kept secret i '=(r i ',s i ').

[0137] 3. Finally, each player sends his / her public key P i and the corresponding signature Sig P i =(r i ,s i ) is provided. This is done for all players until the transaction contains enough inputs to produce a single rN×x output. This output is then passed to the oracle P O is paid to the public key corresponding to

[0138] The structure of a begin transaction is shown in FIG.

[0139] Oracle Transactions

[0140] Each player reveals his or her secret i ' to the Oracle.

[0141] The oracle is agreed upon even before the initiating transaction occurs, and may be a trusted third party, a purpose-built TEE (Trusted Execution Environment, purpose-built hardware to run known code for a specific function, or some other form of oracle).

[0142] 2. The oracle generates each secondary signature, Sig P i '=(r i ',s i ') and their respective key signatures Sig P i =(r i ,s i ) is the public key P i verifies that the .ssl key corresponds to the same key pair associated with the .ssl key.

[0143] 3. The oracle constructs the transaction. This transaction uses the UTXO of the initiating transaction as its only input and locks the entire endowment of N×x Bitcoins into a single winning public key. W is a random number R generated within the locking script of this oracle transaction. N is selected randomly using

[0144] As shown below, <P W The output script of Figure 3, also denoted by >, is i It is used to randomly select the winning public key from the set of <R N > and is seeded by <R N > Calculates a random number on the fly to select the winning key. <P W >= <p1> <p2>… <P N > <R N > OP_ROLL OP_TOALTSTACK OP_DROP…OP_DROP OP_FROMALTSTACK Here, there are N-1 uses of the operator "OP_DROP" and N public keys.

[0145] The first two lines of the locking script tell the script <R N > part. Then the script simply executes the signature Sig P W The locking script for the oracle transaction simply requires the winning public key P W This prevents the prize fund from being signed by the owner of the public keys. Note that the order in which public keys appear in this locking script must be consistent with the order in which they appear in the initiating transaction, or else an oracle could manipulate the result by reordering the public keys.

[0146] House Lottery

[0147] In this application example, an N-player lottery is constructed with no party acting as the "house". It may be desirable to extend this concept to such lotteries so that funds are not simply lost or wasted in the Bitcoin ecosystem. For example, if one party wants to construct the lottery and provide the act of the house by taking on the overhead involved, such as setting up a user interface, instantiating an oracle, or recruiting participants, that party may want to be incentivized to do so. This incentive could be in the form of a timeout mechanism, such as sending the lottery's winning fund to the house. Implementing this lottery involves N players contributing x bitcoins and the house contributing r bitcoins. If the oracle transaction is modified to take the form described in Figure 4, the house may be incentivized to send the winning fund to the house after some agreed-upon timeout period ΔT E After that, you collect the entire lottery fund and use your public key P H It is possible to pay to.

[0148] In the oracle transaction in Figure 4, the locking script is modified to include a timeout failsafe that allows the party acting as the house to spend the lottery fund if the winning party does not claim their winnings before an agreed upon time. The portion of the locking script highlighted in blue allows this to be done. In this type of blockchain lottery that includes a house, each player has a chance of winning r+(N×x) bitcoins with a probability of 1 / (N+1), where r is the house's contribution. This concept of adding a house to the lottery can be extended to lotteries that do not necessarily have a winner, such as national lotteries in various countries, by including a set of public keys corresponding to the house. If one of these keys is selected, the lottery rolls over.

[0149] Refund of lottery winnings

[0150] When the oracle transaction is recorded on the blockchain, the winning public key P W The owner of may spend the lottery fund. A valid transaction of this type is shown in Figure 5.

[0151] The unlocking script for this transaction will be the signature SigP W When unlocking funds held by an oracle transaction, this input to the redemption transaction (scriptSig) is executed together with the locking script (scriptPubKey) of the previous oracle-constructed transaction. The combination of these two scripts is shown in Figure 6, where the winning player enters the winning public key P W We demonstrate that it is possible to spend a lottery fund of N × x Bitcoins by simply providing a signature corresponding to

[0152] N-sided Satoshi Dice

[0153] A second application of the method of the present application is a game with a dealer and one player, where the game is equivalent to the player correctly guessing the outcome of rolling N-sided dice. Obviously, this game is simply a two-participant version of the general blockchain lottery application as outlined above, where one party acts as the dealer and the other as the player.

[0154] In this scenario, the following steps describe how the game is played.

[0155] 1. A player makes a guess c∈{0,N-1}. This guess is c = H(X P ) mod N It is calculated as:

[0156] 2. The initiating transaction is Y from the player. P =H(X P )and, The preimages are input parameters for determining the outcome of trial T, which represents the rolling of the N-sided Satoshi dice. D =H(X D ) This transaction includes both the amount x Bitcoins to be paid to the oracle and wagered by the player, and the winning payout R Bitcoins to be wagered by the dealer.

[0157] 3. Original image p and X D is sent to the oracle using a secret value sharing technique, such as that outlined in WO 2017 / 145016. The oracle then returns the public key P W Construct a transaction that locks on the

[0158] This is done in the same way as in a regular lottery, except that only one public key P belongs to the player, and N-1 public keys D i ∀i∈{1,N-1} belongs to the dealer. The result T of the roll of the Satoshi dice is calculated in the locking script, T=H(X P +X D ) mod N It is calculated by:

[0159] 4. If c = T, the player can withdraw the prize fund x + R bitcoins by spending the output of the oracle transaction. Otherwise, the prize fund is withdrawable by the dealer.

[0160] As per the discussion presented earlier in this application, the random number R N We have successfully generated a hashing scheme for :=T, which satisfies criteria (1)-(3) and has been used to determine the outcome of a game of chance. Note that the hashing methods described above may be more suitable for the present application, as they allow the guesses to be more easily adapted to the player's preferences.

[0161] On average, a player can choose at most N arbitrary preimages X P hashes of x may be calculated before arriving at the player's desired guess, which may then be committed to the game. A game of chance set up in this way gives the player a 1 / N chance of winning x+R bitcoins, where the associated payoff R may be a function of x.

[0162] Seeding other generators

[0163] It has been shown above how random numbers can be securely generated in a script and using the Bitcoin blockchain protocol. In the presented lottery application example, it is proposed to use these random numbers for their immediate function in the transaction, rather than using them elsewhere, i.e. for some off-chain purpose.

[0164] The method described in this application generalizes to the simplest case of generating random numbers through a secure, consensus-based, transparent protocol. For example, if a single party or organization wants to generate random numbers to seed an off-chain process, they may do so using one or more of the methods presented in this document. The party then simply constructs a transaction flow similar to that used for the lottery application, but does not associate a bulk endowment with the global inputs and outputs of the process. In this way, the party can create a mechanism, a seed (i.e., a secret value s i '), and the results are all transparently recorded in the blockchain public ledger. N or sequence S R A blockchain may be used to generate the

[0165] Turning now to FIG. 7, an illustrative simplified block diagram of a computing device 2600 is provided that may be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. For example, the computing device 2600 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. 7, the computing device 2600 may include one or more processors (collectively designated 2602) with one or more levels of cache memory and a memory controller that may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and persistent storage 2610. As shown, the main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used for storage of information, such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0166] The processor 2602 may also be in communication with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0167] The bus subsystem 2604 may provide a mechanism for allowing various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0168] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface to receive data from the computing device 2600 and transmit data from it to other systems. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that it may be possible to transmit data to and receive data from the device while the data technician is at a remote location, such as a data center.

[0169] The user interface input devices 2612 may 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, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0170] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used to present a user interface, for example, to facilitate user interaction with applications that execute the described processes and variations thereof, when such interaction may be appropriate.

[0171] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM or DVD or Blue-Ray) drives with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in this disclosure, as well as data associated with transactions and blocks as described in this disclosure.

[0172] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 may include another device that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. The device may thus be configured to convert optical signals into electrical signals that may be transmitted through the ports that connect the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 depicted in FIG. 7 is intended only as a specific example to illustrate a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system depicted in FIG. 7.

[0173] It should be noted that the above mentioned embodiments illustrate rather than limit the present disclosure, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be interpreted as limiting the claims. Words such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. As used herein, "comprises" means "includes or consists of" and "comprising" means "including or consisting of". A reference to an element in the singular does not exclude the reference in the plural of such elements and vice versa. The present disclosure may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0174] appendix

[0175] 1. DER Encoding the Signature

[0176] [Table 1]

[0177] 2. Verification script

[0178] i. Preimage verification

[0179] The following script processes the supplied preimage X as an internal process. i Each of the precommitted hash values ​​Y i This can be used to verify that <Verify 1> = <y1> <x1>OP_SHA256 OP_EQUAL… <Y N > <X N > OP_SHA256 OP_EQUAL

[0180] ii. Signature Verification

[0181] The following script also processes the code with a secondary signature, Sig P i ' and the initial signature Sig P i Each of these has a public key P i This can be used to verify that <Verify 2> = <p1>OP_DUP<Sig P1> OP_SWAP OP_CHECKSIG<s1'><r1'> OP_CAT OP_SWAP OP_CHECKSIG… <p1>OP_DUP <Sig P N > OP_SWAP OP_CHECKSIG N '> <r N '> OP_CAT OP_SWAP OP_CHECKSIG [Explanation of symbols]

[0182] 2600 Computing Devices 2602 Processor 2604 Bus Subsystem 2606 Storage Subsystem 2608 Main memory 2610 Persistent Storage 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 DRAM 2620 ROM​ < / y1> < / p1> < / n> ​

Claims

1. 1. A processor-executed method for implementing lottery using a blockchain, comprising: receiving first data from each of a plurality of first participant devices, the first data comprising at least one respective first data item; combining a plurality of said first data items to generate second data; applying at least one one-way function to at least a portion of the second data to generate third data, the or each one-way function being adapted to receive input data and to generate output data based on the input data, the input data being not inferable from the output data and the one-way function; selecting an item from a plurality of items based on the third data, wherein at least one of the first plurality of participant devices has access to the selected item, and the at least one of the first plurality of participant devices includes a winner of the lottery; constructing a blockchain transaction to be recorded in the blockchain, the blockchain transaction including a prize fund for the lottery; Equipped with the third data is generated within a locking script of the blockchain transaction such that the locking script locks the prize fund of the lottery to the selected item; The method, wherein the blockchain transaction is redeemable by a script that includes the first data item.

2. The method of claim 1 , wherein the first data is received from the first participant device in an encrypted format.

3. 3. The method of claim 1 or 2, further comprising receiving fourth data comprising at least one respective fourth data item from each of a plurality of the first participant devices, wherein the or each fourth data item is generated by applying at least one one-way function to the or each first data item corresponding to the first participant device.

4. The method of claim 3 , further comprising transmitting the fourth data to a plurality of the first participant devices.

5. 5. The method according to claim 1, wherein at least one of the one-way functions is a hash function.

6. The method of any one of claims 1 to 5, wherein at least one of the one-way functions associates a public key and a private key of each public-private key pair of a cryptosystem.

7. The method of claim 6 , wherein the cryptosystem is an elliptic curve cryptosystem.

8. 8. The method of claim 1, wherein at least one said first data item comprises at least a portion of a respective first data signature.

9. 9. The method of claim 8, wherein at least one of the first data items includes at least a portion of a respective first digital signature, the portion being based on a private key and an ephemeral key.

10. 10. The method of claim 9, further comprising receiving at least one respective second digital signature from each of a plurality of the first participant devices, wherein the second digital signature is signed with the same private key as the corresponding first digital signature.

11. 11. The method of claim 9 or 10, further comprising receiving fifth data comprising a respective fifth data item from each of a plurality of the first participant devices, the fifth data item being part of a corresponding first digital signature, the first digital signature being constructed by combining the fifth data item with the corresponding first data item.

12. The method of claim 11 , further comprising transmitting the fifth data to a plurality of the first participant devices.

13. 13. The method of claim 11 or 12, wherein at least one said fifth data item comprises at least a part of a respective first digital signature based on an ephemeral key.

14. 14. The method of claim 1, further comprising the step of transmitting the first data to a plurality of the first participant devices subsequent to generating the third data.

15. The method of claim 1 , wherein execution of the script regenerates the third data from the first data items.

16. 16. The method of claim 1, wherein the third data is generated by a plurality of the one-way functions.

17. 17. The method of claim 1, wherein the third data is generated by repeated application of at least one of the one-way functions.

18. The method of claim 1 , wherein the third data is generated by a plurality of second participant devices.

19. The method of claim 1 , wherein the selecting comprises selecting a public key of a cryptosystem public-private key pair, and wherein at least one of the participant devices has access to a private key of the pair.

20. 1. A system comprising: The processor and a memory are provided. A system, wherein the memory includes computer-executable instructions that, upon execution by the processor, cause the system to perform a method according to any one of claims 1 to 19.

21. A non-transitory computer-readable storage medium having stored thereon computer-executable instructions that, when executed by the processor of a computer system, cause the computer system to perform the method of any one of claims 1 to 19.

Images