Computer-implemented decision-making system and method

Abstract

To provide a method and a system for making a decision on a block chain.SOLUTION: The method includes receiving a first public key from a plurality of participants, by combining each first public key in association with a corresponding first secret key using cryptographic operations that have homomorphic properties, representing possible choices of participants, generating a second public key that represents a possible decision based on the combination of possible choices, and generating a third public key by communicating with the participants and generating a voting transaction corresponding to the second public key. An input to the voting transaction can be executed by a digital signature corresponding to each of the first private keys of the plurality of participants. Each first private key represents a participant's choice. An output of the voting transaction represents a decision based on the participants' choices. The method also generates a payment transaction for the transfer of the first digital asset and performs an output that requires a digital signature corresponding to the third public key corresponding to the decision of the voting transaction.SELECTED DRAWING: None

Description

[Technical Field]

[0001] The present invention relates generally to systems and methods for automated decision making, and more particularly to automated decision making via a blockchain. The present invention is particularly, but not exclusively, suitable for use in methods of voting via a blockchain. [Background technology]

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

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets 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, and these blocks are strung together to create a permanent, immutable record of all transactions written to the blockchain since its origin. Transactions contain small programs known as scripts. Scripts embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. 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 the work to ensure that invalid transactions are rejected by the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must (i) be validated by the first node that receives it, and if the transaction is valid, the node relays the transaction to other nodes in the network; (ii) be added to a new block constructed by miners; or (iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such solutions could take advantage of the benefits of blockchains (e.g., permanence, tamper-resistance of event records, decentralized processing, etc.) while further diversifying their uses.

[0006] In the case of automated decision-making, in many situations, not only will the decision depend on a set of factors, but the decision may also depend on the opinions of multiple parties. Furthermore, each party may be designated to make a choice related to one of the factors. In such situations, it is desirable that each party's choice be recorded and verified, and that the parties' individual choices are all reflected in the final decision. For example, in the case of a retail store that needs to purchase products for an upcoming season, the selection of products to purchase may come from a purchasing clerk, the selection of suppliers may come from upper management, and the total amount to be paid by the company may come from the accounting department. The final decision is a reflection of input from each of the three parties.

[0007] These multiple layers of decision making are reminiscent of a decision tree, where choices made with respect to factors corresponding to a particular level do not necessarily depend on other choices at other levels. Each unique path through the tree corresponds to a particular combination of sub-decisions. The distributed ledger (blockchain) of cryptocurrencies like Bitcoin has several features that can be useful for such decision making. The first of these is that the blockchain provides an immutable record of the actions / data contained within transactions. At the same time, the transparency of the ledger means that the respective inputs of the various parties in the decision process can be verified and confirmed.

[0008] The scripting programming language featured in cryptocurrencies like Bitcoin allows for the opportunity for sophisticated rule sets that determine the conditions under which Bitcoin transaction outputs / tokens / coins are accessed. This smart contract capability can be used to design voting systems where the successful execution of a contract depends on choices made within a multi-party decision-making protocol.

[0009] Blockchain constitutes a suitable environment where votes and opinions can be publicly and permanently recorded to avoid any kind of manipulation of votes. Despite this capability, there are many problems to solve in order to generate secure votes on blockchain. These range from preventing multiple secret ballots to maintaining user privacy and checking trust.

[0010] As an example, decentralization is a key issue for online electronic voting, and existing configurations are typically configured in a way that prevents abuse but relies on a central authority to verify and consider votes or feedback. The central authority may use different cryptographic primitives, such as blind signatures and homomorphic encryption, to add secrecy and verification of eligibility to secret ballots, for example by participants submitting their votes to a mixing authority that remixes and encrypts the votes before broadcasting to hide the link between the vote and the voter.

[0011] Decentralized encryption methods for vote submission eliminate the dependency on a central trusted authority. For example, secure multi-party computation (MPC) protocols, whose goal is to allow a collection of users to compute a function of their joint secret inputs without the need for a trusted third party, allow the parties to jointly compute their average vote privately and securely. One known protocol for the efficient computation of aggregation functions has a process that is easily transferable to the specific case of anonymous voting. This involves the use of "clusters of participants," where the clusters are structured in a tree or ring topology. A user's ballot is encrypted by a function that is also homomorphic, and the encrypted value is communicated to all other members of the same cluster. Each user computes an aggregated value and passes it to the next cluster in the case of a ring, or to the parent cluster in the case of a tree. The cumulative aggregated value is decrypted in the final or root cluster. Conflicts among the aggregated values ​​along the way are resolved by majority vote. This is supported by a clustering process that is designed so that the majority of nodes in any given cluster are honest nodes, provided there are fewer than a certain number of hostile nodes present.

[0012] The protocol is also proposed to protect voter privacy. This is achieved by introducing computationally expensive zero-knowledge proofs to verify the correctness of submitted secret ballots and the honesty of participants. A mechanism is also implemented whereby deposits can be demanded and confiscated in the event of malicious activity.

[0013] These protocols emphasize that they are based on determining a winner through majority voting. Summary of the Invention

[0014] It is therefore desirable to provide an arrangement in which the winner is determined by a unique combination of votes from a set of voters.

[0015] Thus, according to the present invention there is provided a method as defined in the accompanying claims.

[0016] According to the present invention, there is provided a method of making a decision on a blockchain, said decision being based on at least one respective selection made by each of a plurality of participants, said method comprising: receiving a respective plurality of public keys from each of a plurality of participants, each first public key representing a possible selection by the participant and related to a corresponding first private key by a cryptographic operation having homomorphic properties; combining the first public keys according to the homomorphic property to generate a plurality of second public keys, each of the second public keys representing a possible decision based on a combination of the possible choices; communicating a plurality of third public keys to each of the plurality of participants, each of the third public keys corresponding to a respective one of the second public keys; generating a first blockchain transaction, wherein an input of the first blockchain transaction is a script executable using respective digital signatures corresponding to the respective first private keys of each of a plurality of the participants, each of the first private keys representing the selections made by the participants, and an output of the first blockchain transaction is a script representing the decision based on the selections made by the participants; generating a second blockchain transaction to transfer a first digital asset, wherein execution of an output of the second blockchain transaction requires a digital signature corresponding to the third public key corresponding to the decision of the first blockchain transaction; A method may be provided that includes:

[0017] This provides the advantage of allowing participants to check that the decision represented by the first blockchain transaction takes into account the choices made by that participant, thereby making the decision more representative of all participants, and also allows the decision to be verified by a third public key.

[0018] The input of the first blockchain transaction may be a script accessible by a fourth public key processed by an administrator.

[0019] This provides the advantage of allowing oversight and / or control of the decision voting process.

[0020] The output of the first blockchain transaction may be a multi-signature script accessible by a digital signature corresponding to a fifth public key processed by the trustee.

[0021] This provides the advantage of allowing transactions to be in a format that is easily propagated on the blockchain.

[0022] The first private keys may be stored in a public key field of the multi-signature script.

[0023] This offers the advantage of allowing data to be stored in transactions and easily transmitted on the blockchain.

[0024] The method may further include generating a third blockchain transaction having at least one output corresponding to each input of the first blockchain transaction.

[0025] Execution of at least one output of the third blockchain transaction may require at least one digital signature corresponding to the respective first private key.

[0026] Execution of at least one output of the third blockchain transaction may require at least one private key.

[0027] This provides the advantage of connecting participants more directly with their choices and allowing parties to sign transactions independently of knowledge of choices made by other parties.

[0028] At least one output of the third blockchain transaction may be a script that applies the cryptographic operation corresponding to the first public key.

[0029] The method may further include receiving the private key from the participant in encrypted form.

[0030] If the second blockchain transaction is not executed, generating a fourth blockchain transaction to refund at least a portion of the first digital asset may further be included.

[0031] The fourth blockchain transaction may be time-locked.

[0032] The homomorphic operation may be elliptic curve scalar multiplication.

[0033] The present invention provides a processor and a memory containing executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein; A system including:

[0034] 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 methods described herein.

[0035] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0036] [Figure 1] 1 illustrates a decision tree for use in a method embodying the present invention. [Figure 2] The result set of the decision tree in Figure 2 is shown. [Figure 3] 1 shows a possible summary of public keys in a method embodying the present invention. [Figure 4] 1 illustrates a blockchain transaction from a method embodying the present invention. [Figure 5] Figure 4 shows a commitment transaction. [Figure 6] The voting transaction in Figure 4 is shown. [Figure 7] Figure 4 shows a payment transaction. [Figure 8] Figure 4 shows a refund transaction. [Figure 9] The output script for the commitment transaction in Figure 5 is shown below. [Figure 10] 1 shows a flow chart of a method for implementing the present invention. [Figure 11] 10 illustrates a blockchain transaction according to a further embodiment of the present invention. [Figure 12] Figure 11 shows a commitment transaction. [Figure 13] 4 shows a flow chart of a further embodiment of the present invention. [Figure 14] It is a schematic diagram showing a computing environment in which various embodiments can be implemented.

Embodiments for Implementing the Invention

[0037] <Homomorphic Property of EC Key Pair> In order to hide the user's secret value at an early stage of the proposed multi-factor multi-party (MFMP) decision protocol, the reason for using elliptic curve (EC) encryption in this application is due to the homomorphic property [6] of the secret-public key pair of EC. x1G + x2G = (x1 + x2)G x is the private key, G is the base point of the EC, and xG is the corresponding public key of x.

[0038] More generally, here, E(x) = xG, E(m + n) = E(m) + E(n) For this, there exists a homomorphic hash function (and / or cryptographic function): H(m + n) = H(m) + H(n) These homomorphic hash functions also achieve some key functions that the EC cryptographic homomorphic secret-public key relationship performs for the MFMP protocol.

[0039] Also, although addition is used in this application, the homomorphic property does not have to be for addition. That is, the contribution of this application can be achieved when the homomorphic property of the hash / cryptographic function is for other operators. As an example, the operator is multiplication, and the following is considered. H(mn) = H(m) × H(n) Here, H() is a hash / cryptographic function.

[0040] More generally, when the operator is a general operator (+ in ○), it is as follows:

Number

[0041] Therefore, in such cases, operators are applied equivalently to the design of MFMP protocols and homomorphism comes into play.

[0042] <m-of-n multi-signature script as data storage> Given that Bitcoin transactions do not have a dedicated field for storing metadata, the success of the MFMP protocol depends on finding an appropriate location to record the choices made by parties regarding the decision factors for which they are assigned responsibility.

[0043] In the proposed design of the MFMP protocol, votes are stored using the Bitcoin script of m-of-n multi-signature (multisig) transactions. These multi-signature elements are first incorporated into the Bitcoin script, thereby requiring more than one key to authorize the Bitcoin transaction.

[0044] An m-of-n multi-signature script has the following format: OP_0 Sig1 Sig2 … NumSigs Pub1 Pub2 Pub3 Pub4 … NumKeys OP_CHECKMULTSIG

[0045] where the content NumSigs Pub1 Pub2 Pub3 Pub4 … NumKeys OP_CHECKMULTSIG is the output script <scriptpubkey>and the content OP_0 Sig1 Sig2 is the input script <scriptsig>It may be of the following type. <scriptpubkey>is the set of rules for making transaction outputs available. <scriptsig>teeth, <scriptpubkey>This content is required to satisfy the following.

[0046] NumSig is the number of signatures required, NumKeys is the number of possible signatures, and PubX is the public key corresponding to signature SigX.

[0047] Although this script is intended for m-of-n signatures, the PubX elements of the Redeem script may be suitable for use as a store for metadata.

[0048] 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 has the following format: OP_0 SigA SigB OP_2 meta1 meta2 PubA PubB OP_4 OP_CHECKMULTSIG These metadata elements may represent a set of encrypted votes of the parties responsible for deciding on particular factors of the overall decision.

[0049] As an example, a 1-of-7 multi-signature script is shown, where of the seven data elements reserved for public keys, five are used to store votes and two are used to store genuine public keys.

[0050] The script has the following format: OP_0 SigB OP_1 ν1ν2ν3ν4ν5PubA PubB OP_7 OP_CHECKMULTSIG

[0051] <Elliptic curve finite field operations and opcodes> If the 200 opcode limit in the Bitcoin script were removed, and if disabled opcodes were re-enabled, the Bitcoin protocol would be known to perform Elliptic Curve (EC) Finite Field Arithmetic.

[0052] For clarity, an elliptic curve is a set of points described by: y 2 ≡x 3 +ax+b(mod p) where:

number

[0053] For the purposes of this application, the EC arithmetic function required in Bitcoin script is "point multiplication by a scalar", which is the operation:

number

[0054] Scalar multiplication also requires specific EC group operations: Point Addition and Point Doubling. Point Addition, P+Q: This operation computes a new point on EC as the negation of the intersection of the curves, which can be written as R=P+Q. Point Doubling, P+P: Using point addition, we can calculate twice the point of P. This can be written as R=P+P=2P.

[0055] More specifically, given two points P(x1,y1) and Q(x2,y2), on the EC, P+Q=(x3,y3) where: x3=m 2 -x1-x2mod p y3=m(x1-x3)-y1mod p and

number

[0056] <Multi-factor, multi-party decision protocol> <Summary> The MFMP protocol implements a decision-making system reminiscent of a decision tree. In a multi-factor, multi-party decision tree, each level of the tree (the root node is level 1) represents a particular "party-and-factor," and each branch of each node represents a choice made by a party with respect to a particular factor. Figure 1 shows a decision tree identical to the present MFMP protocol. Each node in the diagram represents a "party-and-factor," and each link / edge between nodes is an option associated with a factor. In the illustrated decision tree, there are n=3 factors (and n parties), and each factor provides m=2 options. In the MFMP protocol, m may vary from factor to factor as needed or appropriate.

[0057] In general, each "party and factor" is a node U i where i represents the factor that the party makes a decision on, e.g., U A represents a party making a decision based on factor A. For each factor a, the set of options {k a,j :∈[0,m a ]}, from which the party may choose, where m a is the number of options. k The nodes represent possible decisions, or outcomes, that result from the combination of party choices. The option chosen by each party represents an outcome O in the decision tree. X Form a path towards.

[0058] The MFMP protocol caters only to scenarios where the set of choices for factors remains the same regardless of choices made by other parties. a,j } is {k b,j }. For example, in Figure 1, k A,1 or k A,2 U A Regardless of whether selected by U B The available options for k B,1 and k B,2 This simply results in a symmetric decision tree.

[0059] Contrary to other voting protocols where a majority vote determines the winner, in the MFMP protocol, a unique combination of votes determines who wins (and what the outcome is). A "vote" by one party does not necessarily result in a particular outcome. i It is not a vote on a set of possible outcomes, but a vote on a set of possible outcomes. A K A,1 If a voter votes for O1, O2, O3, O4, then this represents a choice for the result set {O1, O2, O3, O4}. U B K B,1 This represents a choice over the result set {O1, O2, O5, O6}. U C K C,2 This represents a choice over the result set {O2,O4,O6,O8}.

[0060] The secret value combination (k A,1 ,k B,1 ,k C,2 ) is the intersection of the three sets of results O2 (see Figure 2).

[0061] <Protocol details> <Supervisor> The MFMP protocol is designed to be executed by using a management entity called a Supervisor. This Supervisor is expected to be an entity where multiple-factor multiple-party decisions are made, and / or an entity given the responsibility of supervising the execution of the protocol, such as the CEO of a company. This Supervisor may also be the one who provides coins to fund the final result of the decision-making process. This Supervisor has the responsibility of constructing transactions, signing the transaction inputs when appropriate, and generating and submitting transactions to the blockchain in the appropriate order and with timely information.

[0062] The Supervisor may also explain, establish, or negotiate with each voting party a set of possible choices and corresponding results that can be made regarding decision-related factors.

[0063] <Initialization and Keys> All parties agree on a set of related parameters including the standardized elliptic curve, secp256k1, used in Bitcoin: G: A starting point on the elliptic curve with degree q: q×G = 0, q: A large prime number.

[0064] For each party assigned to a factor in the decision-making process, the party is requested to generate a set of values of their own secret k a,i where a represents a decision factor and i represents one of the set of options for that decision factor. Among this set, there are m a secret k a,i values. The k a,i values satisfy 0 < k a,i < q.

[0065] Each party is expected to keep its own respective k a,i value secret at this point in the protocol. For each k a,i value, party U a has the corresponding public key value Q a,i = k a,i Calculate G.

[0066] <Hierarchical structure and summary> Each party has its own respective public key {Q a,i } with all other parties (including the administrator). Each party agrees with the administrator which of their public keys corresponds to which element of the set of choices associated with the party's assigned factor. With the public keys from all other parties, the party computes (for each of them) all possible combinations of summing public keys, where there are n elements in the sum, and each element of the sum is the public key of a different voting party. The sum corresponds to adding the public keys along the possible paths of the decision key hierarchy (Figure 3). Also, as discussed above in the section "Homomorphism of EC Key Pairs," homomorphism functions and / or operators other than addition may be used.

[0067] From the example shown in Figure 3, the possible sums of public keys (regardless of which party does the calculation) are: O1=Q A,1 +Q B,1 +Q C,1 O2=Q A,1 +Q B,1 +Q C,2 … O7=Q A,2 +Q B,2 +Q C,1 O8=Q A,2 +Q B,2 +Q C,2 Each party is expected to keep a record of how each total is obtained. By doing this, each party a,i via your secret k a,i Which of the values ​​is a particular O i Find out what was used to obtain the result value.

[0068] For example, Party U A For factor A, if he / she chooses "1" or chooses "Q A,1 via k A,i ), his / her choice k A,i We know that the results of taking into account the above can be O1, O2, O3, and O4.

[0069] Due to the homomorphic properties of the EC private-public key relationship described above in the "Homomorphicity of EC Key Pairs" section, the result O x Note that for , there are n factors / parties, such that: O x= Q A,i +Q B,j +…+Q n,k =k A,i G+k B,j G+...k n,k G =(k A,i +k B,j +...k n,k )G nka,i a,i The sum of the values ​​is sν x Therefore, sν x =k A,i +k B,j +...k n,k and: O x =sν x G

[0070] The administrator is responsible for managing each O x A new public key / address S that should be directly associated with the result X to each voting party. This is the set of pairs {(O x ,S x )}, where the set {O x } is the set {S x}. Mathematically, it will be understood by those skilled in the art that a bijection, bijective function, or one-to-one correspondence is a function between the elements of two sets such that each element of one set is paired with exactly one element of the other set, and each element of the other set is paired with exactly one element of the first set, so that there are no unpaired elements. Public key S x may not necessarily belong to the custodian itself, but may be owned by a separate individual entrusted with carrying out the obligations relating to the results. For a person to "own" a public key, or for a public key to "belong" to a person, in this context it means that the person has knowledge of the private key corresponding to the public key.

[0071] Each party, knowing its own set of possible outcomes when voting in a particular way on a particular factor, looks at the commitment transaction and determines the O in the escrow script. x public key S with the correct options associated with the value x As a result, both public keys must sign the escrowed funds or tokens that are to be accessed. Essentially, the parties must ensure that the possible outcomes of the decision-making process are visible within the escrow output of the commitment transaction. x One of the S is correct (according to a prior agreement with the administrator) x If you are tied to a , you may choose not to offer your vote.

[0072] <Embodiment 1: Transaction and Selection Documentation> The MFMP protocol consists of four core transactions: the commitment transaction T C , payment transaction T P , refund transaction T R , and voting transaction T V , the boundaries of these four transactions are shown in Figure 4.

[0073] In Figure 4, each transaction is represented by a rectangle with rounded corners. The inputs and outputs of a transaction are shown by basic rectangles. Inputs are shown in the left half of the transaction, while outputs are shown in the right half of the transaction. The labels on the input and output rectangles are those of the public keys of the "source of coins" and "intended recipient", respectively. For example, S a is the source of funds for voting transactions and the recipient of funds for commitment transactions. In this example, a person's public key may be used as their own label. Esc output / input is an exception where an output-input is not directed to one specific address / public key, but can be accessed by different keys based on their ability to meet stated criteria.

[0074] <Commitment Transaction> Commitment transaction T C (See Figures 4 and 5) is the main transaction of the MFMP protocol, and includes as its input the coin Fu to fund one outcome representing the choice of all voting parties. These funds are assumed to come from an entity / individual entitled Administrator S. As an example, this Administrator could be the CEO or accountant / treasurer of a company, responsible for the company's finances. S a The administrator provides these funds from an address labeled .

[0075] A commitment transaction is expected to have at least two outputs. The first of these is a nominal fee that is transferred to a secondary address belonging to the custodian. This output address is used as an easy way for stakeholders to link the commitment transaction to a voting transaction that uses information stored on the blockchain. The address for these funds is a secondary address S owned by the custodian. b is.

[0076] The second output of the commitment transaction is to escrow a certain amount of coins, where the "winning" outcome of the decision tree receives (or is funded by) these escrowed coins. An output is said to be "escrowed" when the funds are not directly exclusive to a particular output address / public key, but have conditions attached to this output's Bitcoin script that cause these funds to be transferred to one of a set of possible addresses. Here, the final address to which the coins are granted depends on the criteria specified in the script being met.

[0077] This script will a,i The condition set is to only grant access to the escrowed coins if the value is available. More specifically, the criteria in the script for the selection of the output address of the escrowed funds is that the signature must match the public key O. x and S x where: O x =sν x G sν x =k A,i +k B,j +...k n,k S x The result is x A unique output address paired with

[0078] <voting transaction> Voting transaction T V (see Figures 4 and 6) is responsible for recording the choices made by the parties regarding the determinants they have signed.

[0079] This voting transaction is the S of the commitment transaction. b The output is "linked" to a commitment transaction by using it as an input to a voting transaction, where S b is a secondary address controlled by an administrator. This link serves three purposes:

[0080] T C and T V The address shared between both (voting and commitment) transactions allows the custodian to easily retrieve one of the two aforementioned transactions if the custodian finds the other transaction in the blockchain. Note that the commitment transaction is placed on the blockchain before the voting transaction. Therefore, a commitment transaction can exist on the blockchain without a voting transaction also existing, but not vice versa. Record the link. This link provides a documented link between the commitment transaction and its escrow funds and votes cast by the parties. Administrator authorization. Input S (of the voting transaction) b The custodian's address included as an input in the voting transaction gives the custodian an element of control over the vote being cast, as the custodian signing the custodian serves as a formal expression of the custodian's acceptance of the party's vote.

[0081] The vote transaction itself is expected to be constructed by the administrator and then passed to the parties, so that each party may add their vote to the transaction. a,i The field reserved for the public key in the m-of-n multi-signature script is used to store the vote in the vote transaction. This script is the output script of the vote transaction. <scriptpubkey>In Bitcoin, <scriptpubkey>It is known to those skilled in the art that the is a set of rules that governs the use of transaction outputs. <scriptsig>teeth, <scriptpubkey>This content is required to satisfy the following.

[0082] k a,i The current version of the voting transaction, including the m-of-n script containing the value, is now returned to the administrator. a,i The administrator who owns the set of values ​​is (k A,i +k B,j +...k n,k ) O from the hierarchy where G was calculated x The vote may be verified by determining whether it is equal to one of the results.

[0083] If the vote combination is verified, the administrator will send the output script of the vote transaction. <scriptpubkey>m-of-n multi-signature scripts with public key S a This is the custodian's primary public key ("address") of any transaction in which the custodian wishes to spend some of their coins in the output of a voting transaction. <scriptsig>S a It is expected to generate a signature for

[0084] An example of an output script for a voting transaction combined with the input script of a transaction that uses this output is shown below: OP_0 Sig S a OP_1k A,I k B,j k C,k PubS a OP_4OP_CHECKMULTSIG <scriptpubkey>This 1-of-4 multi-signature of contains three votes cast by the parties responsible for factors A, B, and C, and is signed by public key S a Also includes.

[0085] The current version of the voting transaction is then resent to each party. Each party verifies that his / her vote is included in the final version of the output script and signs his / her input to the transaction, representing their authorization of the voting transaction; that is, they approve that their vote is included in the voting transaction. The custodian signs his input to the voting transaction, and the voting transaction is then submitted to the blockchain.

[0086] Alternatively, each party may communicate their vote in a secure manner to the administrator, who then adds all votes to the output script of a voting transaction and then sends this transaction to the various parties for their respective input signatures.

[0087] The following should be noted: Each party uses / contributes minimal or nominal funds / coins for their input to the voting transaction. The voting transaction is more of an immutable record of the vote than a transfer of funds. In the current version of the Bitcoin protocol, the maximum number of public keys allowed in a multisignature output is 15. For this reason, the maximum number of votes (voters) that the m-of-n multisignature script described can allow is 14 (assuming one of the 15 spaces contains the administrator's public key S a (Note that this is reserved for multi-signature scripts.) More elaborate scripts, including multiple redundant m-of-n multi-signature (sub)scripts, may be constructed to incorporate more votes, but note that the maximum size of a script is 10 kilobytes [7] and the transaction cost depends on the size of the transaction. Where applicable, managers may also vote based on factors relevant to the decision.

[0088] <payment transaction> Payment transaction T P (see Figures 4 and 7) is a transaction that can successfully access the coins escrowed in the Esc output of the commitment transaction (see Figures 4 and 5). This transaction has its input script <scriptsig>It contains two signatures: the first is the public key O x It is a signature for (k A,i +k B,j +...k n,k )G=O x each k a,i are for different decision-relevant factors.

[0089] k present in the script a,i The unique binding of values ​​is the determining factor for who (the owner of the public-private key pair) can access the Esc coins. a,i The value may be retrieved from a voting transaction available on the blockchain.

[0090] The second signature in the payment transaction input script is O x Public key S, the public key of the individual assigned responsibility for managing x This does not necessarily mean that the primary custodian of the protocol (S a and S b The third signature may not be the owner of the payment transaction (e.g., the owner of the transaction), but may be any other authorized individual. Additionally, where appropriate, particularly for security / control purposes, a third signature may be required for the input script of the payment transaction, where the third signature is that of the primary custodian.

[0091] If the inputs of the payment transaction are successfully signed, the escrowed coins of the commitment transaction are distributed to the result O. x Recipient address R associated with x The payment transaction is submitted to the blockchain after the voting transaction.

[0092] <Refund transaction> The refund transaction (Figures 4 and 8) is a transaction that returns escrow funds to all parties (administrator or otherwise) that contributed funds to the commitment transaction. This is seen as a fail-safe measure in case a participant in the protocol fails to act accordingly. Importantly, this refund transaction contains an nTimeLock value that prevents it from being accepted by the blockchain until after a certain point in time (Unix time or block height) has passed.

[0093] The input script of a refund transaction contains data that can fill one of the options available in the escrowed output script of a commitment transaction. This data can be the signatures of the primary custodian (who committed the escrow funds) and other custodians. All other custodians must sign the refund transaction before the commitment transaction is submitted to the blockchain by the custodian. This ensures that in the event of a failure, the custodian can recover all committed escrow funds.

[0094] A refund transaction is an optional transaction and can only be submitted to the blockchain if the payment transaction of the MFMP protocol instance has not been submitted. Furthermore, a refund transaction can only be submitted after a specific point in time. With this in mind, the nTimeLock value of the refund transaction must be chosen such that after the commitment transaction is submitted at time T, there is enough time for: · Votes are available The voting transaction is committed to the blockchain Voting transactions are found in the blockchain A payment transaction is generated and submitted to the blockchain.

[0095] The time (range) specified to achieve all is labeled s. The nTimeLock value of a refund transaction may be at least: nTimeLock=T+s Note that the time nTimeLock value can be defined in seconds or block heights.

[0096] <Escrow-related scripts> <Output script:CommitmentTransactionEscrow> The escrow funds in a commitment transaction are expected to be "protected" by a stack-based scripting language that allows the escrow funds to be accessed / claimed / spent in a set of possible ways. Each of these ways of accessing the escrow funds has an associated set of criteria that must be met in order for the funds to be retrieved. An escrow script can essentially be viewed as representing a set of case statements, where each option in the case statement is a different way of accessing the escrow funds. Assuming there are t options, then for t-1 of these options (one criterion is associated with the refund signature), the criteria for each case are (at least) the following: ECDSA signatures are (k A,i +k B,j +...k n,k )G=O x should be generated for the public key address of and ECDSA signatures are x The public key S of someone in charge of x should be generated for

[0097] Figure 9 shows a high-level version of the Bitcoin Output Script representing the escrow case statement (featuring eight dots), where (cond_i) represents the criterion / condition that needs to be met and [Do_i] represents the action that should be performed if (cond_i) evaluates to true.

[0098] More specifically, as it relates to output scripts, the condition (cond_i) that may be used to express the need for two ECSDA signatures is that of a 2-of-2 multi-signature (sub)script: OP_2 PubO x PubS x OP_2 OP_CHECKMULTSIG ... Here, PubO x =(k A,i +k B,j +...k n,k )G and Pub S x Here is the result x is the public key of the entity assigned to

[0099] The action that each [Do_i] element of the script is asked to perform is to deposit the value 1 / TRUE on the top of the stack, assuming (cond_i) evaluates to true. Those skilled in the art will understand that Bitcoin script is a stack-based language, and that a "TRUE" value on the top of the stack after script execution is complete means that the script executed successfully.

[0100] <Input script: payment transaction> To successfully access the coins of an escrowed output of a commitment transaction, this requires the output script of the escrowed output. <scriptpubkey>is the input script for the payment transaction <scriptsig>When combined with , it requires that the combined script executes successfully, i.e., produces 1 / TRUE on the top of the stack.

[0101] At least one data element<data_i> must be included in the Input Script, which causes at least one of the if statements in the Output Script to be true, ultimately causing the combined Input and Output Script to evaluate as true.

[0102] It should be noted that,<data_i> may represent multiple fields of data.<data_i> is the three values ​​of the 2-of-2 multi-signature script, i.e. <op_0><sigO x > <sigS c > may be a combination of

[0103] It should also be noted that depending on the options considered, some redundant data may be used where appropriate.<bd_datai> may also be included in the input script.<bd_dti> , "bad data" is meant to represent data that, when processed by (cond_i), is guaranteed to produce 0 / FALSE as output.<data_i> Similarly,<bd_dti> may consist of a number of individual data elements.<bd_dti> teeth,<data_i> It is expected that the data will consist of the same number of data elements, such as

[0104] <MFMPフローチャート> FIG. 10 shows a general overview of a multi-factor multi-party voting protocol.

[0105] 11 to 13 show the configuration of a further embodiment of the present invention.

[0106] <Embodiment 2: Transaction and Selection Documentation> This embodiment differs from the multi-factor multi-party of the first embodiment in the following way: whereas the first embodiment recorded the votes of the parties as a combined set of votes included in the m-of-n multi-signature output script of the voting transaction, this embodiment asks the voting parties to disclose their votes by including their vote as an argument in the input script of the voting transaction. By doing so, this provides the advantage of connecting parties more directly to their votes and allowing parties to sign transactions independently of knowledge of the votes of other parties.

[0107] In the first embodiment, the votes of the various parties were stored in the m-of-n multi-signature script of the voting transaction. To indicate confirmation that their vote is presented and / or documented in the voting transaction, each party (e.g., parties A, B, and C in FIG. 11 ) signs their corresponding input of the voting transaction. While this signature appears as such confirmation, which vote belongs to which participant is not documented in the blockchain. This information can be useful in several scenarios. At the same time, a party cannot sign the voting transaction until all parties have contributed their votes to the m-of-n multi-signature output script.

[0108] The second embodiment introduces a variant of the multi-factor multi-party decision-making protocol of the first embodiment. The variant addresses the limitations described for party storage and validation of votes within the protocol's voting transactions. It does this by forcing parties to disclose their votes in order to access funds used as inputs to voting transactions.

[0109] To achieve this, assume there exists an opcode in Bitcoin Script that allows for Elliptic Curve (EC) "point multiplication by a scalar." This also requires that Bitcoin Script's 200 opcode limit be removed and that disabled opcodes be re-enabled. The techniques utilized in this embodiment, including the homomorphic properties of the private-public key relationship in elliptic curve (EC) cryptography, along with the proposed opcodes, have been described in detail above.

[0110] The proposed opcode of this embodiment differs from the MFMP protocol of the first embodiment in the elements of the transaction in which the vote is stored (vote), and then in "when and how" the signature can be initiated as confirmation that the vote has been submitted.

[0111] <Commitment Transaction> As in the first embodiment, the second embodiment uses four core transactions: commitment transaction T C , payment transaction T P , refund transaction T R , and voting transaction T V , the boundaries of these four transactions are shown in Figure 11.

[0112] <Commitment Transaction> The commitment transaction of this embodiment differs from that of the first embodiment in that the commitment transaction of this embodiment is expected to have at least four outputs, as shown in Figures 11 and 12. The first output is sent to a second address S belonging to the administrator. b The output addresses are used as an easy way for custodians (stakeholders) to link commitment transactions to voting transactions that utilize information stored on the blockchain. More importantly, since these outputs are inputs to voting transactions, and are inputs that require signatures, this serves as a way to grant custodians authority over voting transactions.

[0113] The second output of the commitment transaction, as in the first embodiment, is to escrow an amount of coins, where the "winning" outcome of the decision tree receives (or is funded by) these escrowed coins.

[0114] The second embodiment further differs from the first embodiment in that other outputs (of which there will be at least two) are to public addresses belonging to voting parties, e.g., parties A, B, and C in Figures 11 and 12. These outputs should be designed such that the parties are required to generate their respective votes (and signatures for public key A) in order to access the funds. As an example, if party A wants to use output A of a commitment transaction, he / she will need to include public key Q in the input script of the voting transaction. A,i =k A,i G, and therefore their vote k on the blockchain. A,i It is necessary to make public the following.

[0115] If the parties are allowed to vote in several ways related to the factors assigned to them, the output script of the commitment transaction of the voting party (e.g., Party A) <scriptpubkey>must contain several options for accessing funds, each of which is based on one of the options for the voting party. Using the multi-option (nested if-else) high-level script structure described with reference to Figure 9, the Bitcoin script for a condition (cond_i) that allows for the payment of funds from an option is as follows: <Basepoint G> OP_ECPMULT A,i > OP_EQUALVERIFY <puba>OP_CHECKSIG It can be seen that this script makes use of the opcode OP_ECPMULT proposed above in the section "Elliptic Curve Finite Field Arithmetic and Opcodes".

[0116] Since (cond_i) is satisfied, voting party A<data i> must be included. < <Sig A><k A,i >> where sig A is the signature of public key A and k A,i is Party A's vote.

[0117] Note that Party A's vote is accessed as part of processing the output of the commitment transaction.<data i> will be disclosed in

[0118] <voting transaction> The voting transaction of the second embodiment (see FIG. 11) is the S of the commitment transaction. b It is "linked" to the commitment transaction through its outputs and the outputs of the voting parties. These outputs of the commitment transaction are inputs of the voting transaction.

[0119] The voting transaction itself is expected to be constructed by the administrator and then passed to the parties, so that each party may sign its input. A party that signs its input to the voting transaction will receive its vote k a,i It should be recalled (from the commitment transaction above) that

[0120] The custodian signs his input to the voting transaction, which is then submitted to the blockchain.

[0121] Note that each party uses / contributes a minimal or nominal fee in coins for their input to the voting transaction, which is more of an immutable record of a vote than a transfer of funds.

[0122] Figure 13 shows a general overview of the multi-factor multi-party voting protocol.

[0123] Referring to FIG. 14 , an illustrative simplified block diagram of a computing device 2600 is provided that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems 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. 14 , the computing device 2600 may include one or more processors with one or more levels of cache memory and memory controller (collectively labeled 2602), which may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read-only memory (ROM) 2620, as shown. 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.

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

[0125] 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 utilize multiple buses.

[0126] The network interface subsystem 2616 may provide an interface to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may act as an interface to receive data from and send data to other systems on the computing device 2600. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can send data to and receive data from the device without having to be in a remote location, such as a data center.

[0127] User interface input device(s) 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 touchscreen 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 encompass all possible types of devices and mechanisms for inputting information into computing device 2600.

[0128] 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 include a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a flat-panel device such as a projection, or other display device. In general, use of the term "output device" is intended to encompass all possible types of devices and mechanisms for outputting information from computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with applications that perform the processes and transformations described herein, when such interaction is appropriate.

[0129] The storage subsystem 2606 may provide a computer-readable storage medium that stores the basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions), which, when executed by one or more processors, provide the 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 also provides 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 permanent storage device 2610 may provide permanent (non-volatile) storage of programs and data and may include a magnetic hard disk drive, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blue-Ray) associated with removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in this disclosure and data associated with the transactions and blocks described in this disclosure.

[0130] Computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device connectable to computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device connectable to computing device 2600 may include multiple ports configured to receive optical fiber connectors. Thus, the device may be configured to convert optical signals into electrical signals that are transmitted to computing device 2600 through the ports connecting the devices for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 14 is intended only 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 the system shown in FIG. 14 .

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

[0132] References Table 1 [Table 1] [Explanation of symbols]

[0133] T C Commitment Transactions T P Payment Transactions T R Refund Transaction T V Voting Transactions< / puba> ​< / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptpubkey> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey>

Claims

1. 1. A method of making decisions on a blockchain, the decisions being based on selections made by each of a plurality of participants, the method comprising: At each of the plurality of participants, generating a set of first private keys and a set of corresponding first public keys, each first private key representing a possible selection of the participants, and each first public key being generated from the corresponding first private key using a cryptographic function having a homomorphic function; providing said first set of public keys to each of the other participants and to a managing entity; receiving a respective set of first public keys from each of the other participants; calculating a plurality of second public keys, each second public key being a combination of the first public keys including only one first public key from each set of first public keys for each of the participants, each second public key corresponding to a possible decision; providing a first private key from the set of first private keys of the participant for inclusion in an output of a voting blockchain transaction, the provided first private key corresponding to a selection made by the participant; the voting blockchain transaction includes a plurality of inputs, one input corresponding to each of the participants and one input corresponding to the governing entity; a combination of private keys in a script in the output corresponding to a first one of the second public keys, the script representing a decision based on a selection made by the participant; inspecting the output of the voting blockchain transaction to check that it contains the participant-provided first private key; signing the input of each of the participants in the voting blockchain transaction; A method comprising:

2. 2. The method of claim 1, further comprising receiving from the management entity a plurality of third public keys, each third public key corresponding to a second public key, and an indication of the correspondence between the second and third public keys.

3. Prior to the step of providing the first private key, obtaining a commitment blockchain transaction, the commitment blockchain transaction having a first output corresponding to each of the custodial entities' input to the voting blockchain transaction and a second output including a pairing of corresponding second and third public keys; Inspecting the second output of the commitment blockchain transaction to check that the pairing of the corresponding second and third public keys in the second output is the same as the corresponding instruction received from the administrative entity; The method of claim 2 further comprising:

4. 4. The method of claim 3, further comprising generating the commitment blockchain transaction at the administrative entity.

5. The method further includes generating, at the administrative entity, a payment blockchain transaction for transferring the first digital asset; an input of the payment blockchain transaction corresponds to the second output of the commitment blockchain transaction; 5. The method of claim 3 or 4, wherein execution of the output of the payment blockchain transaction requires a digital signature corresponding to the third public key corresponding to the decision of the voting blockchain transaction.

6. 6. The method of claim 5, further comprising: generating, at the administrative entity, a refund blockchain transaction for refunding at least a portion of the first digital asset if the payment blockchain transaction is not executed.

7. 7. The method of claim 6, wherein the refund blockchain transaction is time-locked.

8. The method according to any one of claims 1 to 7, further comprising the step of generating the voting blockchain transaction at the administrative entity.

9. The method of any one of claims 1 to 8, wherein the script in the output of the voting blockchain transaction further includes a public key processed by the administrative entity.

10. The method of any one of claims 1 to 9, wherein the cryptographic operation is an elliptic curve scalar multiplication.

11. A computer system implementing the method according to any one of claims 1 to 10.

12. 1. A computer-implemented system comprising: a processor; a memory containing executable instructions that, upon execution by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 10; A system including:

13. 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 the method of any one of claims 1 to 10.

Images