Computer-implemented method, system, and storage medium for blockchain

Abstract

To provide systems and methods for communication, storage, and processing of data provided by an entity over a blockchain.SOLUTION: A method includes: a step of providing a blockchain voting commitment transaction (2) redeemable by means of a first signature (σ(Am), σ(Bm)) associated with a selection (A, B) and a second signature (σ(A), σ(B)) associated with the selection; a step of providing each of a plurality of participants (Ui) with at least one share (kA,i, kB,i) of at least one respective secret value (kA, kB); and a step of submitting the blockchain voting commitment transaction (2) to a blockchain.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention generally relates to cryptographically implemented data recording and processing systems. In particular, the present invention relates to technical solutions for communicating, recording, and / or storing data provided to the system by entities by or through a blockchain. The data may represent, for example, selections, elections, feedback, and / or decisions. The present invention provides techniques for the secure storage and communication of such data between entities over a blockchain network, ensuring the integrity of the data being transferred and used after transfer. It also mitigates issues related to identifying the source of such data in the network, which may prevent authorized actions. The present invention is suitable for, but not limited to, voting, electronic feedback submission, counting applications, or other applications where data integrity, source confidentiality, and enforcement of usage quotas or limits may be important. [Background technology]

[0002] In this document, we use the term "blockchain" 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 most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and purposes of explanation, Bitcoin may be referenced herein; however, it should be noted that the present invention is not limited to the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. In this document, the term "user" can refer to a human or a processor-based resource.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks, which are made up of transactions. Each transaction is a data structure that encodes control of digital assets among 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 to which multiple blocks are chained together to create a permanent, immutable record of all transactions 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.

[0004] For a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform tasks to ensure each transaction is valid; invalid transactions are rejected by the network. A software client installed on a node performs this validation task on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must (i) be verified by the first node that receives it—once the transaction is verified, the node relays it to other nodes in the network; (ii) be added to a new block constructed by mining nodes; and (iii) be mined, i.e., added to the public ledger of past transactions. Once recorded, the data in any block cannot be retroactively changed without changing all subsequent blocks and without the collusion of a majority of the network.

[0005] A transaction involves the transfer of one or more tokens from one node to another. Tokens can represent future control over network resources. In some cases, tokens can represent assets or value, but this is not required. For example, in some cases, tokens can be understood as cryptocurrencies. However, this application is not limited to implementation in the context of cryptocurrencies, but may be understood more broadly as relating to blockchain networks for the decentralized transfer of control tokens.

[0006] A blockchain serves as a public ledger capable of recording transactions between parties in a verifiable and permanent manner. Blockchains have many properties, such as the immutability of information stored on the chain and trust established through decentralized consensus, that make them suitable for use in a variety of applications. One such application is electronic voting. It should be noted that the term "voting system" is not limited to political or administrative contexts in this application, but is used in a general sense to simply mean a system that allows selections, elections, decisions, or parameters (i.e., votes) to be transmitted, recorded, stored, processed, and / or registered in some manner. Accordingly, the present invention relates to improved communication, storage, and security of data between entities.

[0007] Many types of computer-implemented systems require that selection / decision instructions or other data be communicated over a network so that the data can be acted upon or processed in some way. In many cases, it is desirable to be able to enforce certain rules or criteria regarding the number of times a selection can be made. In other words, there may be a quota or limit on the number of times a selection or election can be made. For convenience and ease of reference only, such a system may be referred to as an "e-voting" system, but this should not be construed to limit the invention to political or administrative contexts. Alternatively, the term "data recording system" may be used to reflect the broader applicability of the invention. The invention is not limited with respect to the type or nature of the data received, recorded, and stored.

[0008] Recently, there has been growing interest in developing online technologies to design protocols for secure electronic voting. The goal of these efforts is to allow a group of users to make collective decisions based on their individual preferences, which are maintained in secret. Issues associated with electronic voting include denying another party the ability to determine a user's vote, ensuring the immutability of the vote, and providing the necessary transparency throughout the process to gain voter confidence in the process.

[0009] The introduction of blockchain as the basis for cryptocurrency protocols allows for the exploitation of the immutability and transparency properties of these distributed ledgers. In combination with useful cryptographic solutions, these ledgers offer unique opportunities for using blockchain as an effective replacement for trusted third parties, typically in electronic (server) and non-electronic voting processes.

[0010] The widespread adoption by the global community of information technologies, particularly the Internet, has inevitably led to the question of electronic voting with respect to the use of various existing services. While web-based polls are a popular method for capturing user sentiment, there is significant opposition to the use of electronic voting for elections to public offices and other related situations. In the face of this opposition, proposed systems will be tasked with overcoming various social and technical hurdles if electronic voting is to achieve further success.

[0011] Some of the desirable criteria that an electronic voting system should strive to achieve are: What is right: All votes count; that is, all valid votes are counted towards the final result, while invalid or unauthorized votes are eliminated. Privacy: Votes are not known to participants other than the voter himself. No double voting: Votes may not be submitted twice, i.e., it should be impossible for an attacker to copy a vote that has already been submitted by another voter. Eligibility: Only authorized voters can cast their votes in the protocol. Verifiability to ensure votes are properly considered.

[0012] The emergence of blockchain technology through the cryptocurrency Bitcoin provided an opportunity to leverage the attributes of blockchain in building e-voting protocols. Blockchain itself is an immutable public ledger that eliminates the need for a trusted third party to validate transactions. These characteristics are believed to be applicable to e-voting by applying and / or enabling one or more of the five criteria above.

[0013] Blockchain constitutes a suitable environment where votes and opinions can be publicly and permanently recorded, avoiding any kind of manipulation of votes. Despite this capability, there are many issues that need to be addressed to make voting secure on blockchain. This ranges from preventing multiple vote submissions to maintaining user privacy and credit checks.

[0014] Decentralization is one of the biggest problems for online electronic voting and evaluation protocols: while existing solutions are typically configured in a way that prevents fraud, they rely on a central authority to verify and consider votes and feedback.

[0015] A central authority can use various cryptographic primitives, such as blind signatures and homomorphic encryption, to add confidentiality and validation to the votes cast. Chaum's protocol participants send their votes to a mixing authority, which uses a mix-net setup to shuffle and encrypt the votes before broadcasting them, hiding the connection between the vote and the voter. This is described in detail in the following non-patent document 1. [Prior art documents] [Non-patent literature]

[0016] [Non-Patent Document 1] Chaum, DL (1981)-“Untraceable electronic mail, return addresses, and digital pseudonyms”, Communications of the ACM, 24(2), 84-90 Summary of the Invention

[0017] It is therefore desirable to provide a Bitcoin-compatible voting protocol in which voters use Bitcoin transactions to cast their vote for a preferred candidate (among two possible choices) and pledge an amount of Bitcoin or tokens to the winning candidate. The protocol utilizes a distributed key sharing scheme to facilitate the reward of candidates who win enough votes.

[0018] Thus improved solutions have been devised.

[0019] Thus, according to the present invention there is provided a method as set out in the accompanying claims.

[0020] According to the present invention, there may be provided a computer-implemented method for voting in a blockchain, the method including: providing each of a plurality of voters with at least one share of a secret value, each secret value being associated with a selection; providing a commitment transaction redeemable to reveal the winning selection by providing both (i) a first signature determinable from the secret value of the winning selection, and (ii) a second signature indicating an identifier of the winning selection; and submitting the commitment transaction to the blockchain, wherein the secret value of the winning selection is determinable using a number of voting items provided by at least one voter, each voting item including at least one share, the number exceeding a predetermined value.

[0021] By providing such a method, blockchain users can cast their votes securely in a tamper-proof first-past-the-post style voting system.

[0022] At least one voter may add at least one signed input representing a cryptocurrency to the first commitment transaction.

[0023] This provides the advantage of discouraging fraudulent or malicious participation in the voting process.

[0024] The method may further include providing a return transaction that can be implemented to return at least a portion of the cryptocurrency to the at least one voter once the locktime condition is satisfied.

[0025] This provides the advantage of a mechanism that minimizes asset loss in the absence of a winning option.

[0026] The commitment transaction may include an m-of-n multi-signature execution script, and at least one voting item may be added to the execution script.

[0027] This provides the advantage of allowing storage and public visibility of at least one voting item.

[0028] At least the voting items may be encrypted with a first public key for at least one selection.

[0029] This provides the advantage of allowing only the selected choice to decrypt the voting item and gain access to the share.

[0030] The at least one voting item may include at least one identifying item that identifies the at least one selection.

[0031] If the voting item is successfully decrypted, this provides the advantage of increasing the ease with which the shares can later be identified.

[0032] At least one voting item may include a concatenation of at least one share and at least one identification item.

[0033] The steps to provide shares to voters are: (i) the dealer entity providing the shares to the voters; and (ii) the voter generating the share; may include at least one of:

[0034] This allows for both dealer-based and dealer-less voting systems, thereby increasing the variety of voting methods.

[0035] The method may further include concealing which voters provided which voting items before submitting the commitment transaction to the blockchain.

[0036] This provides the benefit of preventing voters from being identified from their vote items, thereby increasing the security of the voting method.

[0037] The method may further include providing a redemption transaction configured to fulfill the commitment transaction.

[0038] This provides the advantage of an easy way to present the identifier of the winning choice to the voter.

[0039] The method may further include verifying the at least one share using the at least one second public key.

[0040] This provides the advantage of allowing voters to check the validity of their shares, thereby increasing the robustness of the voting method.

[0041] Multiple voters may cooperate to combine at least a subset of the shares to determine at least one second public key.

[0042] This provides the advantage of providing a means of decentralizing at least part of the voting method, thereby further increasing the versatility of the method.

[0043] Additionally or alternatively, the present invention may provide a computer-implemented method for determining a winning choice for voting in a blockchain, the method including: determining at least one share of at least one secret value from at least one voting item, each secret value being associated with a choice; determining a secret value for the winning choice using a number of shares provided by the at least one voting item, the number exceeding a predetermined value; determining a first signature from the secret value of the winning choice; and executing a commitment transaction to reveal the winning choice by providing both (i) the first signature and (ii) a second signature associated with an identifier of the winning choice.

[0044] By providing such a method, the identity of the winning choice of a voting method implemented on a blockchain can be determined and verified in a secure and transparent manner.

[0045] The present invention also provides a system, the system comprising: processor; and memory containing executable instructions; which executable instructions, when executed by a processor, cause the system to perform any embodiment of the computer-implemented method described above.

[0046] The present invention 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 one of the computer-implemented method embodiments described above.

[0047] This application describes systems and methods that support secure, cryptographically efficient implementations of methods for encrypting, verifying, and broadcasting data items submitted to a blockchain by users. In some useful applications, users may be participants in a voting or feedback platform. In some implementations, this application provides protocols designed to prevent data submission from malicious actors, which can maintain the integrity and authenticity of results generated by the system based on received data. [Brief explanation of the drawings]

[0048] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter, which embodiments of the invention will be described, by way of example only, with reference to the accompanying drawings, in which:

[0049] [Figure 1] 1 shows a schematic diagram of the interaction of three transactions of the present invention.

[0050] [Figure 2] 1 is a table according to the present invention showing the relationship between the number of voters, the threshold number of voters required for a choice to be determined, and the degree of the polynomial.

[0051] [Figure 3] 1 shows a flow chart illustrating the present invention.

[0052] [Figure 4] Indicates a vote commitment transaction.

[0053] [Figure 5] Shows two winner-paying transactions.

[0054] [Figure 6] Indicates a refund transaction.

[0055] [Figure 7] FIG. 1 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0056] This application describes a Threshold Secret Share Voting (TSSV) system in which a group of voters are asked to make a choice between pairs of candidates, with the winning candidate receiving the xBTC committed by each voter. A winning candidate must receive both a majority of votes and a number of votes above a specified threshold. The TSSV protocol utilizes private key share distribution and is designed to allow any committed Bitcoin to be recouped if one or more participants are malicious or do not comply with the protocol's expectations.

[0057] The abbreviation "BTC" may be used as shorthand for any variation of the Bitcoin protocol and should not be construed as being limited to or representing any one particular Bitcoin-related protocol.

[0058] Secret Sharing A threshold cryptosystem is defined by a (t;n)-threshold, where n is the number of participants and t+1 is the minimum number of participants required to reconstruct the secret. A secret sharing scheme is an example of a threshold cryptosystem in which a secret k is divided among n players, such that at least t+1 participants are required to cooperate to reconstruct k. Knowledge of any t pieces of the secret k leaves k undetermined.

[0059] Shamir's secret sharing (SSS) is based on polynomial interpolation and, without loss of generality, the secret is assumed to be an element of a finite field F. The scheme involves a dealer (a dealerless version also exists) and a set of n participants U1,...,U n and an access structure A, i.e., a group of players can reconstruct the secret. This is explained in detail in the following paper: Shamir, A. (1979) “How to share a secret”, Communications of the ACM, 22(11), 612-613.

[0060] For Shamir's solution, any random secret is stored as f(0) in a t-th order polynomial f(x), and player i can calculate its share f(x i ) can only be calculated. If t+1 players out of n cooperate, they can use Lagrange polynomial interpolation to calculate f(x1),f(x2),...,f(x n ) corresponding to each share k1, k2,..., k (of key k) n can be used to reconstruct any point in f(x).

[0061] Using Lagrange polynomial interpolation, a function f(x) of degree t can be reconstructed by t+1 points.

number

[0062] If there is a dealer, the dealer simply chooses a secret a0 = k, which is assumed to be an element of a finite field of size p (p is a prime number), and then selects t-1 positive integers a1,...,a t-1are randomly selected, and these integers are expressed as polynomial f(x)=a0+a1x+a2x 2 +... Then the dealer will represent the coefficients of the n points (x i ,f(x i )) and distribute it to the participants.

[0063] During the Dealerless Share Distribution phase: 1. Each player U i But everyone knows x i Each x i must be unique. 2. Each player U i is a random polynomial f of degree t i Generate (x). 3. Each player U i But at each point f in the polynomial i (x j ) mod n is sent secretly (encrypted with the receiver's public key) to all other players. 4. Each player U i Each received f1(x i ),f2(x i )...,f p (x i ) (all mod n, where n is the order of the group generated by the point G on the elliptic curve), and k i =f(x i ) mod n, which is the share in the polynomial f(x) mod n.

[0064] The key element of threshold signature calculation is determining k×G, where k is the secret key and G is a point on the elliptic curve.

[0065] If f(x) is a t-th degree polynomial, then the secret k is k=Σ i∈π b i,π k i can be interpolated by, where π is the share k a ,k b ,...,k t ,k t+1is a subset of size t+1, b is the interpolation factor, and π is the share of each k i is a group of t+1 players who cooperate to compute k×G without revealing k, where k is the x=0 point in the t-th degree polynomial. Each player U i Part b i,π k i Calculate ×G All players in π add their parts together (reconstructing the secret k by Lagrange interpolation): b a,π k a ×G+b b,π k b ×G+···+b t+1,π k t+1 ×G=k×G This computational process Q=kG is referred to as Secret Share Joining.

[0066] Publicly verifiable secret sharing scheme In a TSSV protocol, it is desirable to be able to verify that voters have been given the correct secret shares. Indeed, if inconsistent shares are distributed among players, a voter's incorrect shares / votes will fail to contribute to the voter's preferred candidate. For share verification, we use the Publicly Verifiable Secret Sharing scheme, which allows voters to verify not only their own shares but also the shares of other voters. This is described in detail in the following paper: Stadler, M. (1996, May), “Publicly verifiable secret sharing” - International Conference on the Theory and Applications of Cryptographic Techniques (pp. 190-199), Springer Berlin Heidelberg.

[0067] In the PVSS method, each participant U i is the decoding function D i and the decryption function D i is the corresponding public cryptographic function E i Thus, the dealer distributes shares using a public cryptographic function and publishes them in the following format: K i =E i (k i ), i=1,...,n

[0068] The encrypted shares can therefore be publicly verified by anyone interested, as will be explained in more detail below: not only can participants verify their own shares, but anyone can verify that they received the correct shares, i.e., whether the dealer was honest or not.

[0069] The main steps of the protocol are: 1-Secret sharing: To calculate the shares and distribute them among the participants, the dealer uses the algorithm Share(k) = (k1,...,k n ) to execute the command. 2-Reconstruction: Participants perform the Recover({D i (K i The secret can be reconstructed by running the algorithm Recover such that {i∈A}=k. 3-Verify: To verify the encrypted share, the algorithm PubVerify is used. i |i∈A})=1→Recover({D i (K i )|i∈A})=u and u=k, then the dealer is honest and the shares are consistent.

[0070] The PVSS method can be interactive or non-interactive depending on the needs of the recovery phase.

[0071] Separating outputs from inputs in Bitcoin transactions The voting protocol is designed so that the transaction that pays the winning candidate also includes the vote of each individual voter. To ensure that no participant, candidate, or any outsider to the voting process knows the vote (and / or its encrypted value) of any other participant, it is important to incorporate a solution that allows each voter to provide their encrypted vote without any other participant being able to link that encrypted value to the voter's source.

[0072] This requirement is similar to that of the popular Bitcoin coin mixing solution CoinJoin, which is described in detail at Maxwell, G. (2013, August) - “CoinJoin: Bitcoin privacy for the real world” - Post on Bitcoin Forum. http: / / tinyurl.com / gn6kmx4 In CoinJoin, each participant in a group contributes and represents one of the inputs of a Bitcoin transaction; this transaction includes multiple outputs, each of which has an output address provided by the participant for that input. To enhance the secrecy of the coin-mixing process, it is important to decouple the input participants from their output addresses. To address this issue, various shuffling solutions have been proposed, where participants can provide their output addresses without any other participant or external adversary being able to associate the participant with a specific output address.

[0073] Shuffling solutions include CoinShuffle (described in detail in: T., Moreno-Sanchez, P., & Kate, A. (2014, September), “CoinShuffle: Practical decentralized coin mixing for Bitcoin” - European Symposium on Research in Computer Security (pp. 345-364), Springer International Publishing), CoinShuffle++ (described in detail in: T., Moreno-Sanchez, P., & Kate, A. (2016) - “P2P mixing and unlinkable Bitcoin transactions” NDSS'17. https: / / goo.gl / QrfMhp), and CircleShuffle.

[0074] Threshold Secret Sharing Voting Referring to Figures 1-6, methods for making decisions in a blockchain are provided. The decision may be a desired course of action, a preferred candidate in an election, or some other form of decision. Multiple participants, or voters, are provided with individual shares of a secret value associated with one or more outcomes of the decision. An outcome may be a candidate running for election. Participants then vote for their preferred outcome, choice, or candidate by providing a first or commitment transaction 2 with input 4 containing the shares associated with the outcome. Commitment transaction 2 (see Figure 4) is configured so that it can be executed only by providing both a first signature (6a, 6b) associated with an outcome and a second signature (8a, 8b) associated with that outcome. In Figures 4-6, the signature of public key X is denoted σ(X). Providing at least a threshold number of shares of the secret value makes sufficient information available to execute the second signature (8a, 8b), thereby satisfying the conditions of commitment transaction 2 and revealing the outcome and / or enacting the decision.

[0075] For the Threshold Secret Shared Voting (TSSV) protocol, a set of participants {U i Consider a situation where a user has the option to vote for one or more choices or candidates. In this example, there are two candidates, designated A and B. Each candidate has a main private-public key pair (PrivA M ,PubA M ) and (PrivB M ,PubB M )), and the public key is made available to all voters. Each voter has one vote, and a winning candidate is: Most votes, and sufficient votes above a specified threshold It is a candidate with As an example, if there are nine participants (voters), the winning candidate may be required to receive at least five votes.

[0076] In combination with their vote, voters are asked to commit (or promise) a predetermined amount of funds (e.g., Bitcoin) with their vote. The accumulated committed funds from all voters will be awarded to the winning candidate. These funds may be understood or act as rewards for the winner or disincentives for dishonest or malicious participants in the voting process.

[0077] The TSSV protocol utilizes three transactions, labeled Vote Commitment Transaction 2 (Figure 4), Winner Payout (or Fulfillment) Transaction 10 (Figure 5), and Refund Transaction 12 (Figure 6). These transactions have the following responsibilities:

[0078] Vote Commitment Transaction: A Vote Commitment Transaction (VCT)2 is a transaction that includes both the vote commitment and the Bitcoin commitment of each voter. In the proposed TSSV design, transaction2 includes inputs4 from the entire set of voters, but not all voters are required to provide a vote. VCT2 not only records the votes of all users, but also pools their Bitcoin commitments in a single output14. These votes are encrypted.

[0079] Refund Transaction: The Refund Transaction (RT)12 is a fail-safe mechanism for voters to get back their deposited funds if the candidate fails to collect the voter's accumulated Bitcoin before the specified time. The RT12 is created and signed after the user has voted and the VCT2 has been created (but not submitted).

[0080] Winner Pay Transaction: A Winner Pay Transaction (WPT) 10, or fulfillment transaction, is a transaction that pays accumulated Bitcoin to a potential winner. The potential winner will be the only one who can collect the pooled Bitcoin, the candidate, or others. Figure 5 shows two possible fulfillment transactions 10a, 10b; (a) shows fulfillment transaction 10a if Candidate A wins, and (b) shows fulfillment transaction 10b if Candidate B wins.

[0081] A visual representation of the interaction between the three transactions 2, 10, and 12, and the pooled Bitcoins, is shown in Figure 1.

[0082] A Vote Commitment Transaction (VCT)2 is a transaction that contains a user's vote. A voter is required to create a VCT for two commitments (vote and Bitcoin), and the process of creating BTC funds is the easiest to understand and is most facilitated by the Bitcoin protocol.

[0083] In the case of Bitcoin commitment, each user spends unspent BTC in a specific address they control / own, includes this as input 4 in commitment transaction 2, and signs their input 4. The voter's input 4 in commitment transaction 2 is signed only by the voter, who is assumed to have completed commitment transaction 2 along with other available details. The refund transaction 12 should also be signed by all parties. Each user is expected to commit the same amount of Bitcoin (xBTC) for their vote, but this is not required.

[0084] In the case of "voting commitment," voter U for candidate B in the context of the TSSV protocol i Vote by v i :U i Under key k BSecret Share B,i and the discriminant values ​​for candidate B. A vote is expressed as a concatenation of v i =k B,i It may be expressed in a way like ||IDCandidateB, where k B,i is key k B Of the voters U i where || represents connectivity.

[0085] v i The key share component of serves to partially allow Candidate B to claim the accumulated and committed funds of all votes if he receives enough votes. i is not necessarily embedded directly in VCT2; preferably, it is first encrypted with the public key of the candidate for whom the voter wishes to cast their vote (in this example, candidate B). The encrypted vote is then i ^ =Enc B (v i ) can be expressed as follows:

[0086] Candidate B is v i ^ When attempting to decrypt v, the component IDCandidateB serves as an indicator for the successful decryption of candidate B. The bit size of IDCandidateB is such that an improper decryption (private) key can decrypt the ciphertext v i ^ It should be large enough that it is unlikely that you can generate a value from the string || IDCandidateB.

[0087] If Bitcoin transactions do not have a dedicated field for metadata storage, the success of the TSSV protocol depends on finding a suitable place to record participants' votes. If the protocol is designed such that all votes are expressed in a single commitment transaction (VCT2), this adds some constraints on incorporating the set of voting commitments.

[0088] In the proposed design of TSSV, votes are stored using the Bitcoin script of m-of-n multi-signature transactions. The m-of-n multi-signature script adopts the following format:

[0089]

number

[0090] As an example, a 2-of-4 multi-signature script is shown, where two of the four data elements reserved for the public key are used to store metadata. The script uses the following format:

[0091]

number

[0092] As an example, a 1-of-7 multi-signature script is shown, where five of the seven data elements reserved for the public key are used to store the encrypted vote and two are used for the true public key. The script uses the following format:

[0093]

number

[0094] The use of public key elements in the m-of-n Bitcoin script requires that consideration be given to the size constraints imposed on public keys for the Bitcoin protocol. This means that the public key is v i ^ allocated to store v i ^ are of the same bit length and v i =k B,i ||Keep in mind that this is an encryption of IDCandidateB.

[0095] It should be noted that in the proposed TSSV protocol, Bitcoin Elliptic Curve Digital Signature Algorithm (ECDSA) signatures (ultimately required by the winning candidate to claim funds) require a 256-bit private key (see, for example, Private key at https: / / en.bitcoin.it / wiki / Private_key). To reconstruct the 256-bit (32-byte) private key, the key shares themselves must also be 256 bits long.

[0096] The Bitcoin protocol uses elliptic curve (EC) cryptography (256 bits long), where the public key kG is a point on the curve; each coordinate is 256 bits long. This is explained in detail in the following paper: Franco, P., 2014. Understanding Bitcoin: Cryptography, engineering and economics. John Wiley & Sons. The Bitcoin protocol allows the representation of EC public keys as compressed or uncompressed points. In the case of compressed points, only the x value of the EC point (256 bits) is stored, while in the case of uncompressed points, both the x and y values ​​are stored (each of 256 bits).

[0097] This means that if an uncompressed public key is used for m-of-n scripts, there is enough storage space for the concatenation of the 256-bit key share and the candidate ID. The 256 bits of the x-coordinate of the EC point are used for the key share k. B,i , while the other 256 bits reserved for the y value can be used to store the candidate ID.

[0098] In a voting system, it is usually desirable that a user's vote cannot be traced back to the voter. For the proposed TSSV protocol, it is necessary for voters to i ^ v exists is ^ If we simply add it to the set / list of voters, other voters will either independently or collaboratively add voter v i ^ The first voter can decide their v i ^ Consider the case where v is added to the list of votes. The second voter can easily see that the (encrypted) vote already in the list is from the first voter. This means that v i ciphertext v instead of itself i ^ This only informs the voters of i This puts malicious voters / participants in a better position to link to the

[0099] More importantly, in situations where the encryption of the votes is done with the public key of one of the two candidates, shuffling the votes prevents a candidate (A or B) from tying voters to their votes. i ^ In the situation where a candidate can decrypt the vote, it is possible for the candidate to bind voters to a vote through the collaboration of one or more voters. Note also that if there are only two candidates in a TSSV protocol, the inability of a candidate to decrypt a vote means that the vote is for the other candidate.

[0100] For this reason, the TSSV protocol requires users to cast their votes. <scriptpubkey>A shuffle solution is incorporated into the process of providing a voter with a set of encrypted votes. Examples of shuffle solutions are listed above, and any of them may be used in an instance of the TSSV protocol. The fundamental responsibility of a shuffle solution used for TSSV purposes is to allow each voter to provide their (encrypted) vote without any other voter or non-voter being able to determine which (encrypted) vote came from which voter.

[0101] Therefore, the set of encrypted votes {v1 ^ ,v2 ^ ,...,v n-1 ^ ,v n ^ } can be created without any voter or candidate (or anyone else) knowing which elements in the set come from which voter.

[0102] The TSSV protocol is designed in such a way that only the winning candidate can collect the pooled Bitcoins. This constraint is enforced by a threshold secrecy scheme, where {k i t+1 shares in the set of shares {i∈[1,n]} can be used to determine the secret k, where t is the degree of the polynomial used to compute the secret key shares.

[0103] Each of the two candidates (A and B) is assigned a public key. PubA=k A G PubB=k B G where G is a reference point on an elliptic curve (EC), and kG is an example of a "point-multiplication-by-scalar" point on EC: G is a reference point on EC, and k is a scalar value.

[0104] k A and k B The values ​​of k are unknown (to anyone, candidate or voter) in the preceding stages of the protocol. A and k B The value of k can only be determined if users submit a sufficient number of votes for a particular candidate. These user votes depend on the voter's candidate of choice. A or k B Contains key shares of k A and k B The key shares are as follows: k A ≡f(k A,1 ,k A,2 ,...,k A,n ) k B ≡f(k B,1 ,k B,2 ,...,k B,n )

[0105] As an example, a voter's voting commitment, if they choose to vote for candidate B, may be as follows: v i =k B,i ||IDCandidateB Value k B,i is key k B is the key share of voters U i The shares previously distributed to

[0106] In theory, key share distribution can be dealer-based or dealerless. In the case of dealer-based distribution, the dealer distributes k A and k B Knowing k A and k B Both parties distribute the key share. Share k B,i and share k A,i A participant involved in the ownership of may be considered a legitimate participant. This dealer cannot be one of the candidates, but must be a third party. If candidate A or B were the dealer, either candidate could sign the TSSV output, and if a malicious candidate learns all the secret keys, they could collect all the pooled funds without winning the necessary votes. In a dealerless implementation, each voter constructs their own key share. Voters share a public key PubA=k A G and PubB=k B To compute G, they collaborate using a secret covalent bond as described above.

[0107] The PVSS method is used to verify key shares by candidates and voters considering PubA and PubB. Having dealers allocate key shares provides appropriate authority control over the list of eligible voters; thus, ownership of a key share can be understood as certification of voting eligibility.

[0108] Candidate B receives enough votes (k B,i share), candidate B can obtain secret k B and uses this k when signing the output of vote commitment transaction 2. B could be used to collect pooled committed bitcoins.

[0109] For Shamir's secret sharing implementation, the polynomial degree must be chosen taking into account the number of votes and the number of voters required for a candidate to win. The winning candidate must achieve the most votes, and the number of votes received by the winning candidate must also be greater than a specified threshold. As an example, Figure 2 shows the number of votes required for a candidate to win and the polynomial degree for changes in the number of voters. The minimum votes required for a winning candidate can be higher if a larger threshold is desired. As a specific example, a government referendum may require both a majority and at least 75% of the vote for a policy proposal to be accepted.

[0110] To win the votes, the winning candidate B must provide more than 8b signatures to PubB (Figure 4). In addition to allocating public keys PubA / PubB (the corresponding private keys are split), both candidates A and B each have their own separate (main) public key PubA. m and PubB m Candidate A owns PubA. m Candidate B knows the private key for PubB m You know the private key for

[0111] The need for this extra public key is due to the fact that any set of t+1 voters can theoretically cooperate to B This is due to the fact that there is no condition for signature 6b based on the extra public key, and even more so for the private key (corresponding to the public key) known only to the candidate. For this reason, public key pubB M The winning candidate's signature 6b is also required for the winning candidate (Candidate B) to claim the accumulated funds.

[0112] With this in mind, we consider different ways in which pooled Bitcoins can be claimed in Bitcoin Scripts. <scriptpubkey>This includes a discussion of three methods of collecting payments.

[0113] The first of these rules is the subscript <scriptpubkey>is expressed in:

number

[0114] Please note the following: A copy of the signed refund transaction12 is available to all voters before the VCT2 is submitted to the blockchain. The refund transaction 12 includes an nLockTime value, which prevents the submission of the refund transaction 12 to the blockchain until a specified time point (e.g., Unix time or block height) has passed. Refund transaction 12 returns the bitcoins committed by the users to each user.

[0115] The second set of rules for claiming pooled funds in VCT2 is such that Candidate A can claim pooled funds depending on its ability to generate the two required signatures 6a and 8a (Figure 4). The subscript (shown below) is a 2-of-15 multisig, i.e., it requires signatures corresponding to two public key fields found in a set of 15 public key fields. If there are fewer than 13 voters, fewer than 15 fields may be present.

number

[0116] This subscription serves a dual purpose: the first of these obligations is to contain the encrypted votes (at most 13), and the second is to allow candidate A to claim the pooled Bitcoins by providing his public keys PubA and PubA. m It is acceptable if each signature 8a and 6a can be generated. A Signature 8a of G and PubA is k A To discover v1 ^ This is obtained using a secret value found in the value of the script. This of course depends on there being enough votes for candidate A in the script. Each vote for candidate A has a share k A,i and candidate A's public key (preferably PubA m ) is encrypted. m is the public key generated by candidate A, so candidate A should be able to generate signature 6a for this (main) public key. m Signature 6a is the responsibility of Candidate A because PubA m This is because candidate A generated PubA m The corresponding private key PrivA M Because they own it.

[0117] The third rule set is similar to the second and is intended to include an additional vote to grant or deny Candidate B the ability to claim VCT funds based on the provision of at least two signatures. This is shown below:

number

[0118] The following points should be noted: It does not matter in which of the two m-of-n subscripts the encrypted vote is found: for all v i ^ is visible to both candidates in the blockchain, and both candidates can extract v from any of candidate A's or candidate B's m-of-n subscripts in an attempt to extract their respective key shares of their respective public keys for which signatures are required. i ^ It is possible to try to decipher t+1 is the threshold of votes required for a candidate to process, and t is the degree of the polynomial used in the polynomial-based secret sharing mechanism. ·t is chosen to ensure that t+1 is the majority vote, where the vote is a choice between two candidates.

[0119] Referring to Figure 3, a flow chart illustrating a process 300 incorporating the present invention is shown. First, in step 302, a decision is made regarding the number of voters, n. Using the key agreement techniques described above, a private key, k, is generated in step 304. A Similarly, n shares are created for key k B These private keys correspond to the public keys PubA and PubB, respectively.

[0120] For each voter, k A The unique share k belonging to A,i and k B The unique share k belonging to B,i are given in step 306. Then, the voters are given k A,i They collaborate using key shares and use secret sharing to create PubA=k A Calculate G and similarly k B,i Collaborate using key shares, PubB=k B PubA and PubB are then communicated to all voters and candidates in step 310, and a key share scheme is used to verify key shares given PubA and PubB. Candidates A and B then each obtain their respective main public key PubA in step 312. m and PubB m Create each of them.

[0121] In step 314, each voter concatenates their secret share with the ID of the candidate they choose to create (v i =k B,i ||IDCandidateB) to cast a vote.

[0122] In step 316, each voter encrypts their vote with the public key of the candidate they select. For example, for candidate B, the encrypted vote would look like this:

number

[0123] In step 318, each voter contributes their vote to the list, using the shuffling technique described above to ensure there is no tie between users and their votes. Then, in step 320, voter commitment transaction 2 is created, which includes input from each voter. Each voter contributes an amount of Bitcoin xBTC.

[0124] In step 322, the output of voter commitment transaction 2, valued at nxBTC, is managed by m-of-n scripts, which assign a pubkey element to each of them for use as a store of encrypted votes. This output script of voter commitment transaction 2 is: xBTC refund for each voter Candidate A signs σ(A m ) and σ(A) to collect xBTC Candidate B signs σ(B m ) and σ(B) to collect xBTC is allowed.

[0125] Refund transaction 12 is then created, signed, and a copy is distributed to each voter in step 324. Voter commitment transaction 2 is then submitted to the blockchain.

[0126] In step 326, candidate B i ^ The decryption process attempts to decrypt the value of candidate B. i If Candidate B reveals that the second half of the i The first (first half) segment of the secret share k B,i If Candidate B receives enough votes (shares), he can sign the output. Candidate A performs essentially the same process as that performed by Candidate B.

[0127] Finally, in step 328, if no candidate can claim victory before the nLockTime of refund transaction 12, refund transaction 12 is submitted by any voter, and each voter's committed funds are returned to the voter, minus the transaction cost.

[0128] Referring now to FIG. 7, an exemplary simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. 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 other electronic computing device. As shown in FIG. 7, the computing device 2600 may include one or more processors having one or more levels of cache memory and a memory controller, which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and persistent storage 2610 (collectively labeled 2602). The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620 as shown. The storage subsystem 2606 and cache memory 2602 may be used to store information as described in detail in connection with transactions and blocks described in this disclosure. The processor 2602 may be used to provide the steps or functionality of any embodiment described in this disclosure.

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

[0130] The bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown schematically as a single bus, alternative embodiments of the bus subsystem may use multiple buses.

[0131] The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can act as an interface for receiving data from and transmitting data to other systems on the computing device 2600. For example, the network interface subsystem 2616 can allow a data technician to connect the device to a network so that the technician can send data to and receive data from the device while being located in a remote location, such as a data center.

[0132] The user interface input devices 2612 can 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 or a microphone; and other types of input devices. In general, use of the term "input device" is intended to encompass all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0133] The one or more user interface output devices 2614 can include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem can include 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, 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 can be used, for example, to provide a user interface that facilitates user interaction with applications implementing the described processes and variations thereof, where such interaction is appropriate.

[0134] The storage subsystem 1206 can provide a computer-readable storage medium for storing basic programming and data constructs capable of providing functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which, when executed by one or more processors, can provide functionality of one or more embodiments of the present disclosure, can be stored in the storage subsystem 2606. These application modules or instructions can be executed by one or more processors 2602. The storage subsystem 2606 can additionally provide a repository for storing data used in accordance with the present disclosure. The main memory 2608 and cache memory 2602 can provide volatile storage for programs and data. The persistent storage 2610 can provide persistent (non-volatile) storage for programs and data and can 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, DVD, or Blu-ray) with associated removable media, and other 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 related to transactions and blocks as described in this disclosure.

[0135] Computing device 2600 may be of any of a variety of types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include other devices that may be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, lighting connector, etc.). Devices that may be connected to computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals, which may be transmitted through ports that connect the device to computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 7 is intended as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible, having more or fewer components than those of the system described in FIG. 7.

[0136] It should be noted that the above-described embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined in the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the scope of the claim. Words such as "comprises" 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 "comprises or consists of," and "has" means "comprising or consisting of." A reference to a single element does not exclude a reference to a plurality of such elements, and vice versa. The present 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 may 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. (Appendix 1) 1. A computer-implemented method for making decisions on a blockchain, comprising: providing a first blockchain transaction fulfillable by utilizing a first signature associated with the selection and a second signature associated with the selection; providing at least one share of at least one respective secret value to each of a plurality of participants; and submitting the first blockchain transaction to the blockchain; A method comprising: (Appendix 2) 2. The method of claim 1, wherein at least one participant adds at least one signed input representing a cryptocurrency to the first blockchain transaction. (Appendix 3) 3. The method of claim 2, further comprising providing a second blockchain transaction that is executable to return at least a portion of the crypto asset to at least one participant when a locktime condition is satisfied. (Appendix 4) 4. The method of any one of claims 1-3, wherein the first blockchain transaction includes an m-of-n multi-signature execution script, and at least one share is added to the execution script. (Appendix 5) 5. The method of claim 4, wherein at least one share is encrypted with a first public key for at least one decision. (Appendix 6) 6. The method of claim 5, further comprising combining at least one share with identification data identifying the selection before encrypting with the first public key. (Appendix 7) 7. The method of claim 6, wherein the combining step includes concatenating the at least one share with the identification data. (Appendix 8) Providing the shares to the participants comprises: (i) the dealer entity offering said shares to said participants; and (ii) said participants generating said shares among themselves; 8. The method of any one of claims 1-7, including at least one of: (Appendix 9) 9. The method of any one of claims 1-8, including concealing which participants contributed which shares before submitting the first blockchain transaction to the blockchain. (Appendix 10) 10. The method of any one of claims 1-9, further comprising providing a third blockchain transaction configured to fulfill the first blockchain transaction. (Appendix 11) 11. The method of any one of claims 1-10, further comprising verifying at least one share using at least one second public key. (Appendix 12) 12. The method of claim 11, wherein the plurality of participants cooperate to combine at least a subset of shares to determine at least one of the second public keys. (Appendix 13) processor; and memory containing executable instructions; wherein the executable instructions, when executed by the processor, cause the system to perform the computer-implemented method of any one of claims 1-12. (Appendix 14) 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 one of the methods set forth in any one of appendices 1-12.< / scriptsig> < / scriptpubkey> < / scriptpubkey> < / scriptpubkey> < / scriptpubkey> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey>

Claims

1. 1. A computer-implemented method for voting in a blockchain, comprising: providing at least one share of a secret value to each of a plurality of voter computing systems, each secret value being associated with a selection of one or more options; and generating, by at least one of the plurality of voter computing systems, a commitment transaction executable to reveal a winning selection of the one or more selections by providing both a first signature ascertainable from a secret value of the winning selection and a second signature indicating an identifier of the winning selection, the commitment transaction including an m-of-n multi-signature execution script, and at least one voting item added to the execution script; and broadcasting the commitment transaction to the blockchain, wherein a secret value of the winning selection can be determined using a number of voting items provided by at least one voter computing system of the plurality of voter computing systems, each of the voting items including at least one share of the secret value, and the number of voting items exceeds a predetermined value; A method comprising:

2. 10. The method of claim 1, wherein at least one voter computing system adds at least one signed input representing a crypto asset to the commitment transaction.

3. 3. The method of claim 2, further comprising generating a return transaction configured to be effectuated to return at least a portion of the crypto asset to at least one voter computing system upon satisfaction of a locktime condition.

4. 10. The method of claim 1, wherein at least one voting item is encrypted with a first public key for at least one selection.

5. 5. The method of claim 4, wherein the at least one voting item includes at least one identifying item that identifies at least one selection.

6. 6. The method of claim 5, wherein at least one voting item comprises a concatenation of at least one share of the secret value and at least one identification item.

7. 7. The method of claim 1, wherein providing at least one share of the secret value to a voter computing system comprises: (i) a dealer entity computing system providing at least one share of the secret value to the voter computing system; and (ii) the voter computing system generating at least one share of the secret value; The method includes at least one of:

8. 8. The method of claim 1, further comprising concealing which voter computing systems provided which voting items before broadcasting the commitment transaction to the blockchain.

9. 9. The method of claim 1, further comprising providing a fulfillment transaction configured to fulfill the commitment transaction.

10. 10. The method of any one of claims 1 to 9, further comprising the step of verifying at least one share of the secret value using at least one second public key.

11. 11. The method of claim 10, wherein the plurality of voter computing systems cooperate to combine at least a subset of shares of the at least one share of the secret value to determine the at least one second public key.

12. a processor; and memory containing executable instructions; 12. A computer-implemented system comprising: said executable instructions, when executed by said processor, causing said system to perform the method of any one of claims 1-11.

13. A non-transitory computer-readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least one of the methods of any one of claims 1-11.

Images