Computer-implemented decision system and method

Abstract

A method of making a decision on a blockchain is disclosed. A first public key is received from each of a plurality of participants, each first public key representing a possible selection of the participant and being associated with a corresponding first private key by an encryption operation with homomorphic properties. The first public keys are combined to generate second public keys, each representing a possible decision based on a combination of possible selections. A third public key corresponding to the second public key is communicated to the participant. A voting blockchain transaction is generated, the input of the voting transaction being a script executable by means of a digital signature corresponding to a first private key of each of the plurality of participants, where each first private key represents a selection made by the participant. The output of the voting transaction is a script representing a decision based on the selection made by the participant. A payment blockchain transaction for transferring the first digital asset is generated, the execution of the output of the payment transaction requiring a digital signature corresponding to a third public key corresponding to the decision of the voting transaction.

Description

[0001] This application is a divisional application of the invention patent application with Chinese application number 2019800093238 (corresponding to PCT international application number PCT / IB2019 / 050179), application date January 10, 2019, and invention name “Computer-implemented decision-making system and method”. Technical Field

[0002] The present invention generally relates to systems and methods for automated decision making, and more specifically, to automated decision making via blockchain. The present invention is particularly suitable for, but not limited to, use in methods of voting via blockchain. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variations. The term "user" in this article can refer to human-based or processor-based resources.

[0004] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block so that blocks are linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its creation. Transactions contain small programs called scripts embedded in the inputs and outputs of the applet that specify how and who can access the output of the transaction.

[0005] In order for a transaction to be written to the blockchain, it must be “validated”. Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this validation work on the unspent transaction output (UTXO) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true (TRUE), then the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction – if the transaction is validated, the node relays it to other nodes in the network; ii) the transaction is added to a new block built by miners; and iii) the transaction is mined, that is, added to the public ledger of past transactions.

[0006] It would be extremely advantageous if blockchain could be used to automate tasks and processes in areas that are not limited to cryptocurrency. Such a solution would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more versatile in its applications.

[0007] In the case of automated decision making, the decision in many cases depends not only on a range of factors, but may also depend on the opinions of multiple parties. In addition, each party may be assigned to make a choice related to one of the factors. In these cases, it is desirable to record and verify the choices of each party, and it is desirable that the various choices of the multiple parties should all be reflected in the final decision made. For example, in the case of a retailer that needs to purchase products for the upcoming season, the choice of products to purchase may originate from the buyer, the choice of suppliers may come from upper management, and the total amount that the company will pay may come from the accountant. The final decision will reflect the input from each of the three parties.

[0008] These multi-layered decisions are reminiscent of decision trees, 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 specific combination of sub-decisions. The distributed ledger (blockchain) of cryptocurrencies has several features that may be useful for such decisions. The first is that blockchain provides an immutable record of the actions / data contained in a transaction. At the same time, the transparency of the ledger means that the corresponding inputs of all parties can be verified and confirmed in the decision-making process.

[0009] The scripting programming language unique to cryptocurrencies provides the opportunity for complex rule sets that determine the conditions for accessing the outputs / tokens / coins of cryptocurrency transactions. This smart contract capability can be responsible for the design of voting systems where the successful execution of a contract depends on the choices made in a multi-party decision-making protocol.

[0010] Blockchain constitutes a suitable environment in which votes and opinions can be recorded publicly and permanently to avoid any kind of vote manipulation. Despite this capability, there are still many issues that need to be addressed in order to create secure voting on the blockchain. These range from preventing multiple secret ballots from being submitted to maintaining the privacy of users and checking credentials.

[0011] For example, decentralisation is a significant challenge for online electronic voting, and often existing arrangements are built in a way that is abuse-proof but rely on a central authority to verify and consider votes or feedback. The central authority can use different cryptographic primitives such as blind signatures and homomorphic encryption to increase confidentiality and eligibility verification of secret ballots, for example by having participants send their ballots to a mixing agency that reshuffles and encrypts the ballots before broadcasting them to obscure the link between the vote and the voter.

[0012] Decentralized cryptographic methods for submitting votes eliminate the reliance on a central trusted authority. For example, secure multi-party computation (MPC) protocols, whose goal is to enable groups of users to compute functions of their joint private inputs that they wish to keep secret, without the need for a trusted third party, can allow parties to collectively compute their average votes secretly and securely. One known protocol for efficiently computing aggregate functions has a procedure that is easily converted to a specific case of anonymous voting. This involves the use of "participant clusters," where these clusters are constructed in a tree or ring topology. The user's secret vote is encrypted by an additive homomorphic function, and the encrypted value is communicated to all other members of the same cluster. Each user computes the aggregate value and passes it to the next cluster if it is a ring, or to the parent cluster if it is a tree. The accumulated aggregate value is decrypted at the final or root cluster. Differences between aggregate values ​​along the way are resolved by majority decision. This is supported by a clustering process designed so that if adversarial nodes exist and are less than a certain number, the majority of nodes in any given cluster are honest nodes.

[0013] Protocols are also proposed for protecting voter privacy, which can be 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 under which a deposit is required and can be confiscated in case of malicious behavior.

[0014] For these agreements, the emphasis is on determining the winner through majority voting. Summary of the invention

[0015] It is therefore desirable to provide an arrangement in which a winner is determined by a unique combination of votes obtained from a group of voters.

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

[0017] According to the present invention, there may be provided a method for making a decision on a blockchain, wherein the decision is based on at least one corresponding selection made by each of a plurality of participants, the method comprising:-

[0018] receiving a respective plurality of first public keys from each of a plurality of participants, wherein each of the first public keys represents a possible selection of the participant and is related to a corresponding first private key by a cryptographic operation having a homomorphic property;

[0019] By means of the homomorphic property, the first public keys are combined to generate a plurality of second public keys, wherein each of the second public keys represents a possible decision based on the combination of the possible choices;

[0020] communicating a plurality of third public keys to each of the plurality of participants, wherein each of the third public keys corresponds to a respective second public key;

[0021] generating a first blockchain transaction, wherein an input of the first blockchain transaction is a script executable with a respective digital signature corresponding to a respective first private key of each of a plurality of the participants, wherein each first private key represents the selection made by the participant, and an output of the first blockchain transaction is a script representing the decision based on the selection made by the participant; and

[0022] Generating a second blockchain transaction for transferring the first digital asset, wherein execution of an output of the second blockchain transaction requires a digital signature corresponding to the third public key, the third public key corresponding to the decision of the first blockchain transaction.

[0023] This provides the advantage of enabling a participant to check whether the decision represented by the first blockchain transaction took into account the choices made by that participant, thereby making the decision more representative of all participants. It also provides the advantage of being able to verify the decision with the help of a third public key.

[0024] The input of the first blockchain transaction may be a script accessible via a fourth public key possessed by the supervisor.

[0025] This provides the advantage of enabling oversight and / or control of the voting process for decision making.

[0026] The output of the first blockchain transaction may be a multi-signature script accessible via a digital signature corresponding to a fifth public key possessed by the supervisor.

[0027] This provides the advantage of enabling transactions to be in a form that is easily propagated on the blockchain.

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

[0029] This offers the advantage of enabling data to be stored in transactions and easily transferred across the blockchain.

[0030] The method may also include generating a third blockchain transaction having at least one output corresponding to a respective input of the first blockchain transaction.

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

[0032] Execution of at least one output of the third blockchain transaction may require at least one of the first private keys.

[0033] This provides the advantage of more directly linking the participants to their choices, and enabling one party to sign a transaction independent of knowledge of the choices made by other parties.

[0034] At least one output of the third blockchain transaction may be a script applying the cryptographic operation to the first public key.

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

[0036] The method may also include generating a fourth blockchain transaction for refunding at least a portion of the first digital asset without executing the second blockchain transaction.

[0037] Fourth, blockchain transactions can be time-locked.

[0038] The homomorphic operation can be elliptic curve scalar multiplication.

[0039] The present invention also provides a system, comprising:

[0040] Processor; and

[0041] A memory comprising executable instructions that, due to execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0042] The present invention also provides a non-transitory computer-readable storage medium having executable instructions stored thereon, which, due to execution by a processor of a computer system, causes the computer system to perform at least an embodiment of the computer-implemented method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0044] Figure 1 shows a decision tree used in implementing the method of the present invention;

[0045] Figure 2 Shows Figure 1 The result set of the decision tree;

[0046] Figure 3 shows possible sums of public keys for implementing the method of the present invention;

[0047] Figure 4 Blockchain transactions from methods implementing the present invention are shown;

[0048] Figure 5 Shows Figure 4 Commitment transactions;

[0049] Figure 6 Shows Figure 4 voting transactions;

[0050] Figure 7 Shows Figure 4 Payment transactions;

[0051] Figure 8 Shows Figure 4 Refund transactions;

[0052] Fig. 9 Shows Figure 5 The output script of the commitment transaction;

[0053] Fig.10 A flow chart showing a method for implementing the present invention is shown;

[0054] Fig.11 A blockchain transaction according to another embodiment of the present invention is shown;

[0055] Fig.12 Shows Fig.11 Commitment transactions;

[0056] Fig.13 A flow chart showing another embodiment of the present invention; and

[0057] Fig.14 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0058] Homomorphism of EC key pairs

[0059] The reason why elliptic curve (EC) cryptography is utilized in this application to obfuscate user secret values ​​in the early stages of the proposed multi-factor multi-party (MFMP) decision protocol is due to the homomorphic property of EC's private-public key relationship [6].

[0060] x1G+x2G=(x1+x2)G

[0061] x is the private key, G is the base point of EC, and xG is the corresponding public key of x.

[0062] More generally, where E(x) = xG

[0063] E(m+n)=E(m)+E(n)

[0064] There exists a homomorphic hash function (and / or encryption function) for it:

[0065] H(m+n)=H(m)+H(n)

[0066] These homomorphic hash functions will also perform a key function that is an EC cryptographic homomorphic private-public key relationship for the MFMP protocol.

[0067] Moreover, although addition is used in this application, the homomorphic property does not have to be for addition, that is, if the homomorphic property of the hash / encryption function is for other operators, the contribution of this application can also be achieved. For example, if the operator is multiplication, then consider

[0068] H(mn)=H(m)×H(n)

[0069] Where H() is a hash / encryption function.

[0070] More generally, if an operator is a generic operator⊕ such that

[0071] H(m⊕n)=H(m)⊕H(n)

[0072] Where H() is a hash / encryption function, then in this case the operator can be equally applied to the design of a homomorphically functioning MFMP protocol.

[0073] m-of-n multi-signature script as data storage

[0074] Given that cryptocurrency transactions do not have a field dedicated to the storage of metadata, the success of the MFMP protocol depends on finding an appropriate location to record the choices made by each party regarding the decision factors for which they have been assigned responsibility.

[0075] For the proposed design of the MFMP protocol, votes are stored using encrypted scripts for n-of-m multi-signature (multisig) transactions. These multi-signature elements were initially incorporated into the encrypted script, so more than 1 key was required to authorize an encrypted transaction.

[0076] The multi-signature script of n out of m takes the following format:

[0077] OP_0Sig1 Sig2…NumSigs Pub1 Pub2 Pub3 Pub4…NumKeys OP_CHECKMULTSIG

[0078] Among them, the content NumSigs Pub1 Pub2 Pub3 Pub4...NumKeys OP_CHECKMULTSIG will be the output script <scriptpubkey>The content of OP_0Sig1 Sig2 is the input script <scriptsig>content. <scriptpubkey>Is the set of rules that allow the transaction output to be spent. <scriptsig>is satisfied <scriptpubkey>The content required. NumSigs is the number of signatures required, NumKeys is the number of possible signatures, and PubX is the public key corresponding to the signature SigX.

[0079] Although this script is intended for m-of-n signatures, the PubX element of the redeem script may be suitable for use as storage for metadata.

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

[0081] OP_0SigA SigB OP_2meta1 meta2 PubA PubB OP_4OP_CHECKMULTSIG

[0082] These metadata elements may represent a collection of encrypted votes of the parties responsible for determining specific factors of the overall decision.

[0083] As an example, a 1-of-7 multi-signature script is shown, where 5 of the 7 data elements reserved for the public key are used to store the votes and 2 are used for the genuine public key.

[0084] The script takes the following format

[0085] OP_0SigB OP_1v1v2v3v4v5PubA PubB OP_7OP_CHECKMULTSIG

[0086] Elliptic Curve Finite Field Arithmetic and OPCODE

[0087] It has been discovered that if the 200 operation code (opcode) limit of the encryption script is removed and the disabled opcodes are re-enabled, the encryption protocol can perform elliptic curve (EC) finite field arithmetic.

[0088] For clarity, an elliptic curve is a set of points described by the following equation

[0089] y 2 ≡x 3 +ax+b(mod p)

[0090] in, (mod p), and p is a prime number.

[0091] For the purposes of this application, the EC arithmetic function required within a cryptocurrency script is "scalar point multiplication This is the operation

[0092] Where n is a natural number, P is a point on the elliptic curve, and + is the addition operator for points on the EC.

[0093] Scalar multiplication further requires a specific set of EC operations Point Addition and Point Doubling.

[0094] Point addition P+Q: With this operation, we compute a new point on EC as the negation of the curve intersection point. This can be described as R=P+Q.

[0095] Point doubling P+P: Using point addition, we can calculate the point doubling of P. This can be described as R=P+P=2P.

[0096] More specifically, given two points P(x1,y1) and Q(x2,y2) on EC

[0097] P+Q=(x3,y3)

[0098] in,

[0099] x3=m 2 -x1-x2mod p

[0100] y3=m(x1-x3)-y1mod p

[0101] and

[0102]

[0103] We use the EC opcode provided for the multiplication Q = kG. The opcode is titled OP_ECPMULT. In other words, OP_ECPMULT accepts an encoded elliptic curve point and a number and performs elliptic curve multiplication on a scalar. The output is an encoded elliptic curve point.

[0104] Multi-factor and multi-party decision-making protocol

[0105] Overview

[0106] The MFMP protocol facilitates a decision system that is reminiscent of a decision tree. For a multi-factor multi-party decision tree, each level of the tree (where the root node is level 1) represents a specific "party-and-factor," and each branch from each node represents a choice made by a party with respect to a specific factor. Figure 1 A decision tree corresponding to the MFMP protocol of the present application is shown. Each node in the figure represents a "party-and-factor", and each line / edge between nodes is an option associated with a factor. For the decision tree described, there are n=3 factors (and n parties), and each factor provides m=2 options. For the MFMP protocol, m can be different for each factor if necessary or applicable.

[0107] Typically, each "square-and-factor" consists of a node U i Indicates that, i represents the factor determined by the party; for example, U A represents a party making a decision based on factor A. For each factor a, there is a set of options {k a,j :∈[0,m a ]}, where m a is the number of options. k Each node represents a possible decision or result resulting from a combination of choices made by each party. The options chosen by each party form the path leading to the result O in the decision tree. x Path.

[0108] MFMP protocols only cater for situations where the set of options for one factor remains constant regardless of the choice made by the other party. a,j }Independent of {k b,j }. For example, in Figure 1 In, regardless of U A Select k a,1 Or k A,2 , U B The available options remain as k B,1 and k B,2 . This makes the decision tree only symmetrical.

[0109] Contrary to other voting protocols (where the majority of votes determine the winner), with the MFMP protocol, a unique combination of votes determines who wins (what the outcome is). A party's "vote" is not a commitment to a specific outcome. i It is not a vote on a set of possible outcomes, but a vote on a set of possible outcomes. Figure 1 see,

[0110] If U A Voting A,1 , it means select result set {O1,O2,O3,O4}

[0111] If U B Voting B,1 , it means select result set {O1,O2,O5,O6}

[0112] If U C Voting C,2 , it means select result set {O2,O4,O6,O8}

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

[0114] Protocol Details

[0115] supervisor

[0116] The MFMP protocol is designed to be executed using an overseeing entity called an overseer. It is expected that the overseer is the entity for whom multi-factor, multi-party decisions are to be made, and / or the entity responsible for the duties of overseeing the execution of the protocol, such as the CEO of a company. The overseer may also be the person who provides coins to fund the final outcome of the decision-making process. The overseer will be responsible for transaction construction, signing transaction inputs appropriately, and creating and submitting transactions to the blockchain in the proper order and in a timely manner.

[0117] The supervisor also explains, establishes, or negotiates with each voting party the set of possible choices relative to the factors relevant to the decision and the corresponding outcomes.

[0118] Initialization and keys

[0119] All parties agreed to a standardized elliptic curve for use in cryptocurrencies, secp256k1, and an associated set of parameters, including:

[0120] G - a base point on an elliptic curve of order q: q × G = 0, and

[0121] q-large prime number

[0122] For each party assigned a factor in the decision-making process, the party is required to generate a secret k a,i A set of values, where a represents a decision factor and i represents one of the options in the set for that decision factor. a Secret k a,i Value. k a,i Value makes: 0 <k a,i <q。

[0123] In the protocol, each party is expected to set its corresponding k at this point a,i The value is kept secret. For each k a,i Value, U a The corresponding public key value Q is calculated a,i =k a,i G.

[0124] Hierarchy and summation

[0125] Each party shares all corresponding public keys {Q a,i Each party agrees with the supervisor on which of its public keys corresponds to which element of the choice set associated with that party's allocation factor. Then, using the public keys from all other parties, one party (for their own individual) computes all possible combinations of summing up the 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. This sum will correspond to summing up the public keys along the possible paths of the decision key hierarchy ( Figure 3 ). In addition, as discussed above under the heading "Homomorphism of EC Key Pairs", homomorphic functions and / or operators other than addition may be used.

[0126] from Figure 3 In the example shown, the possible sums of the public keys (regardless of which party performs the calculation) are

[0127] O1=Q A,1 +Q B,1 +Q C,1

[0128] O2=Q A,1 +Q B,1 +Q C,2

[0129] …

[0130] O7=Q A，2 +Q B,2 +Q C,1

[0131] O8=Q A，2 +Q B,2 +Q C,2

[0132] It is expected that each party will record how each sum was obtained. By doing so, each party will know how to obtain a particular O i The result value uses its secret k a，i Which of the values ​​(through Q a，i ).

[0133] For example, one party U A Know that if he / she selects or has selected "1" for factor A (via Q A，1 , using k A，1 ), then considering his / her choice k A，1 The result will be O1, O2, O3 and O4.

[0134] Remember that due to the homomorphic nature of the EC private-public key relationship described above under the heading "Homomorphism of EC Key Pairs", for the result O x , there are n factors / squares

[0135] O x =Q A，i +Q B，j +…+Q n，k

[0136] =k A，i G+k B，j G+…k n，k G

[0137] =(k A，i +k B，j +…k n，k )G

[0138] n k a，i The sum of the values ​​is denoted as sv x ,therefore

[0139] sv x =k A，i +k B，j +…k n，k

[0140] And therefore

[0141] O x =sv x G

[0142] The supervisor’s responsibility is to communicate the new public key / address S to each voting party x , the public key / address S x will communicate directly with each O x The results are associated. This is equivalent to the set pair {(O x , S x )}, where the set {O x } and the set {S x } is bijective. Those skilled in the art will recognize that "in mathematics, 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 pairs with exactly one element of the other set, and each element of the other set pairs with exactly one element of the first set, so that there are no unpaired elements." Public key S x It does not necessarily belong to the supervisor himself, but can be responsible for execution and results. x A single individual has the relevant responsibilities. For a person to "possess" a public key or for a public key to "belong to" a person, in this case, it means that person knows the private key that corresponds to the public key.

[0143] If every party that knows its set of possible outcomes voted a certain way about a particular factor, then each party will check the Commitment Transaction to ensure that it matches the O in the Escrow script. x Value-related options and correct S x The public keys are paired so that both public keys require a signature in order to access the escrowed funds or tokens. Essentially, if the possible outcome of the decision process is x One of the correct S in the escrow output of the commitment transaction x A party may choose not to provide its vote if it is not relevant (pursuant to a prior agreement with the Supervisor).

[0144] Example 1 - Transaction and Selection Documents

[0145] The MFMP protocol is built on four core transactions: C 、Payment Transaction T P , Refund transaction T R and voting transaction T V The interfacing of these four transactions is as follows: Figure 4 shown.

[0146] exist Figure 4 In , each transaction is represented by a rectangle with rounded corners. The inputs and outputs of a transaction are represented by basic rectangles. Inputs are shown on the left half of the transaction, while outputs are shown on the right half. The labels for the input and output rectangles are the "source of the coin" and the public key of the "intended recipient", respectively; for example, S a Is the source of funds for voting transactions and the recipient of funds for commitment transactions. In the current case, a person's public key can be used as a label for that person. Esc outputs / inputs are an exception, as the output-input is not targeted to one specific address / public key, but can be accessed by different keys based on the ability to meet specified criteria.

[0147] Commitment Transaction

[0148] Commitment Transaction T C (See Figure 4 and Figure 5 ) is the main transaction of the MFMP protocol and includes the coin Fu as its input to fund an outcome representing the choice of all voting parties. It is assumed that these funds come from an entity / individual called supervisor S. For example, this supervisor can be the CEO or the company accountant / treasurer who is responsible for the company's finances. The address to which the supervisor provides these funds is marked as S a .

[0149] Commitment transactions are expected to have at least two outputs. The first output is a symbolic fee that is transferred to a second address that belongs to the supervisor. This output address is used as an easy way for stakeholders to link the commitment transaction to the voting transaction using information stored in the blockchain. The address of these funds is the second address S owned by the supervisor. b .

[0150] The second output of the Commitment Transaction is an escrow for a certain amount of coins - because the "winning" outcome of the decision tree will receive (or be funded by) these escrowed coins. This output is described as "escrowed" because the funds are not immediately dedicated to a specific output address / public key, but rather have the conditions of a cryptographic script attached to this output that allows these funds to be transferred to one of a set of possible addresses - where the final address awarded the coins depends on the criteria set by the script to be met.

[0151] The script makes the conditional set only necessary for the participants a,i More specifically, the criterion used in the script to select the output address for escrow funds is to provide access to the escrowed coins only when the value is available. x and S x Generate a signature where

[0152] O x =sv x G,

[0153] sv x =k A，i +k B，j +…k n,k

[0154] And, S x is and the result O x Unique output address for the pair.

[0155] Voting transactions

[0156] Voting Transaction T V (See Figure 4 and 6 ) are responsible for recording the choices made by the parties regarding the decision factors assigned to them.

[0157] By using the commitment transaction S b The output is used as the input of a voting transaction which is "chained" to a commitment transaction, where S b is a second address controlled by the Overseer. This link serves three purposes:

[0158] Link T C and T V -Having a shared address between the two transactions (the voting transaction and the commitment transaction) allows stakeholders to easily retrieve the other transaction if one of the two transactions is found on the blockchain. Note that the commitment transaction is placed on the blockchain before the voting transaction, so while the commitment transaction can exist on the blockchain without the voting transaction, the reverse is not true.

[0159] Linkage Record – This link provides a written connection between the commitment transaction and its escrow funds and the votes cast by each party.

[0160] Supervisor approval – Including the supervisor’s address as an input in the voting transaction gives the supervisor an element of oversight over the votes cast – since signing the input k b The supervisor acts as a formal representation of the votes of the parties accepted by the supervisor.

[0161] It is expected that the voting transaction itself will be constructed by the supervisor and then passed to the parties so that each party can add its own vote to the transaction. a,i The field reserved for the public key in the n-of-m multi-signature script is used to store the votes in the voting transaction. This script is used as the output script of the voting transaction <scriptpubkey>Those skilled in the art will be familiar with the fact that, for cryptocurrencies, <scriptpubkey>Is the set of rules that allow the transaction output to be spent. <scriptsig>is satisfied <scriptpubkey>Required content.

[0162] Now, we will include k a,i The current version of the voting transaction with the value of n out of m script is returned to the supervisor. a,i The supervisor of the set of values ​​will determine whether (k A,i +k B , j +…k n,k )G is equal to O from the calculated hierarchy x If the voting combination is verified, the supervisor will <scriptpubkey>, public key S a Added to the n-of-m multi-signature script of the voting transaction output script. This is the primary public key ("address") of the supervisor, and the supervisor is expected to be the primary public key of any transaction that wishes to spend any coins at the output of the voting transaction. <scriptsig>S a Generate a signature.

[0163] An example of the output script of a voting transaction combined with the input script of a transaction spending that output is shown below.

[0164] OP_0SigS a OP_1k A,i k B , j k C,k PubS a OP_4OP_CHECKMULTSIG

[0165] <scriptpubkey>This 4-of-1 multi-signature includes 3 votes cast by the parties responsible for factors A, B, and C; it also includes the public key S a .

[0166] The current version of the voting transaction is then resent to each party, and each party, upon confirming that his / her vote is included in the final version of the output script, will sign their input to the transaction, indicating their approval of the voting transaction, that is, they acknowledge that their vote is included in the voting transaction. If the supervisor signs their input to the voting transaction, the voting transaction is submitted to the blockchain.

[0167] Alternatively, each party can communicate its vote in a secure manner to an overseer, who then adds all votes to the output script of the voting transaction and then sends that transaction to each party to obtain their corresponding input signatures.

[0168] It should be noted that:

[0169] The funds / coins each party uses / contributes for their input to the voting transaction is a minimal or nominal fee. The voting transaction is meant more as an immutable record of the vote rather than a transfer of funds.

[0170] For the current version of the cryptocurrency protocol, the maximum number of public keys allowed in a multi-signature output is 15. Therefore, the maximum number of votes (voters) that the described n-of-m multi-signature script may allow is 14 (note that one of the fifteen spaces is for the public key S of the supervisor). a More complex scripts can be constructed including multiple redundant n-of-m multi-signature (sub-)scripts to incorporate more votes, but keep in mind that the maximum script size is 10 kilobytes[7] and the transaction cost depends on the size of the transaction.

[0171] Where applicable, supervisors may also vote based on factors relevant to the decision.

[0172] Payment Transactions

[0173] Payment TransactionT P (See Figure 4 and 7 ) is a successful access to the commitment transaction (see Figure 4 and Figure 5 )'s Esc output. This transaction will be in its input script <scriptsig>There are two signatures in it, the first one is the public key O x The signature of

[0174] (k A，i +k B，j +…k n，k )G=O x

[0175] And, each k a,i Targeting different decision-related factors.

[0176] k present in the script a,i A unique combination of values ​​determines who (the owner of the public-private key pair) can access the Esc coin. a,i The value should have been retrieved from the voting transaction available on the blockchain.

[0177] The second signature in the input script of the payment transaction is the public key S x The signature of public key S x Is assigned supervision O x The public key of the responsible individual. This is not necessarily the primary overseer of the protocol (S a and S b The owner of the payment transaction), but can be any other recognized individual. In addition, where applicable, especially for security / control purposes, a third signature can be specified for the input script of the payment transaction, where the third signature is the signature of the primary supervisor. If the input of the payment transaction has been successfully signed, the escrow coins of the commitment transaction can be moved to the same place as the result O x The relevant recipient address R x After the voting transaction, the payment transaction will be submitted to the blockchain.

[0178] Refund Transaction

[0179] Refund Transaction( Figure 4 and Figure 8 ) is a transaction that returns escrow funds to all parties (overseers or otherwise) who contributed funds to a commitment transaction. It is considered a fail-safe measure in case a participant of the protocol does not behave the way he should. Importantly, this refund transaction includes a nTimeLock value that prevents the blockchain from accepting it until after a certain point in time (unix time or block height) has passed.

[0180] The input script of the refund transaction includes data that satisfies one of the available options in the escrow output script of the commitment transaction. This data may be the signature of the primary overseer (the person who committed the escrow funds) and other stakeholders. All other stakeholders must sign the refund transaction before the overseer submits the commitment transaction to the blockchain. This ensures that the overseer can get back all the committed escrow funds if something goes wrong.

[0181] A refund transaction is an optional transaction and may only be submitted to the blockchain if a payment transaction for an MFMP protocol instance has not yet been submitted.

[0182] Furthermore, a refund transaction can only be submitted after a certain point in time. With this in mind, the nTimeLock value of the refund transaction must be chosen so that after the commitment transaction is submitted at time T, there is enough time for:

[0183] The number of votes to be obtained,

[0184] Voting transactions committed to the blockchain,

[0185] Voting transactions found in the blockchain,

[0186] and payment transactions created and submitted to the blockchain.

[0187] The specified time span to complete all of this is denoted by s. Therefore, the nTimeLock value for a refund transaction should be at least

[0188] nTimeLock=T+s

[0189] Please note that the time nTimeLock value can be limited in seconds or block height.

[0190] Hosting related scripts

[0191] Output Script: Commitment Transaction Escrow

[0192] The escrow funds of a commitment transaction are expected to be "protected" by a stack-based scripting language that allows for a set of possible ways to access / claim / use the escrow funds. Each of these ways to access the escrow funds has an associated set of criteria that must be met in order to get the funds back. Essentially, the escrow script can be viewed as a representation of a collection of case statements, where each option in the case statement is a different way to access the escrow funds. Assume there are t options, and for t-1 of these options (where a criterion is associated with (one or more) refund signatures), the criteria for each case should be (at least)

[0193] Will generate an ECDSA signature for the following public address:

[0194] (k A,i +k B,j +…k n,k )G=O x

[0195] as well as

[0196] Will be responsible for O x The public key S of the supervisor role x Generate an ECDSA signature.

[0197] Fig. 9 An advanced version of a cryptographic output script representing a custody case statement is shown (8 options are listed). (cond_i) represents the criteria / condition that needs to be met, and [Do_i] represents the action to be performed if (cond_i) evaluates to true.

[0198] More specifically, as it relates to the output script, the condition (cond_i) used to indicate that two ECSDA signatures are required can be a condition of a 2-of-2 multi-signature (sub)script, e.g.

[0199] OP_2PubO x PubS x OP_2OP_CHECKMULTSIG

[0200] ```

[0201] Among them, PubO x =(k A,i +k B,j +…k n,k )G, and PubS x is assigned to the result O x The public key of the entity.

[0202] Assuming (cond_i) evaluates to true, the action that each [Do_i] element of the script is required to perform is to store the value 1 / TRUE at the top of the stack. Those skilled in the art will understand that cryptocurrency script is a stack-based language, and after the script execution is completed, a "true" value at the top of the stack indicates that the script has been successfully executed.

[0203] Input script: payment transaction

[0204] In order to successfully access the coins of a commitment transaction's escrow output, this requires that the output script of the escrow output <scriptpubkey>Input script for payment transactions <scriptsig>When combined, the combined script is successfully executed, which produces 1 / TRUE at the top of the stack.

[0205] At least one data element<data_i> Must be included in the input script, which will cause at least one if-statement of the output script to be true, ultimately causing the combined input and output script to evaluate to true.

[0206] It should be noted that<data_i> Can represent multiple fields of data. For example, for a 2-of-2 multi-signature script,<data_i> Can be three values <op_0><sigO x > <sigS c >combination.

[0207] It should also be noted that, depending on the options considered, some redundant data<bd_datai> May also be included in input scripts where applicable.<bd_dti> "Bad data" is used to denote data that is guaranteed to produce 0 / FALSE as output when processed by (cond_i).<data_i> similar,<bd_dti> Can consist of multiple individual data elements. In practice, it is expected that<bd_dti> by and<data_i> The same number of data elements.

[0208] MFMP Flowchart

[0209] Fig.10 A general overview of the multi-factor multi-party voting protocol is shown.

[0210] exist Figures 11 to 13 An arrangement of another embodiment of the present invention is shown.

[0211] Example 2 - Transaction and Selection Documents

[0212] The difference between this embodiment and the multi-factor multi-party protocol of the first embodiment is that the first embodiment records the votes of each party as a combination of the set of votes included in the n-of-m multi-signature output script of the voting transaction, while this embodiment requires the voting party to disclose their votes by including the votes of the voting party as independent variables of the input script of the voting transaction. By doing so, the following advantages are provided: more directly linking a party to its vote and allowing a party to sign a transaction independently of knowing the votes of other parties.

[0213] In a first embodiment, the votes of each party are stored in an n-of-m multi-signature output script of a voting transaction. To indicate confirmation that their vote was represented and / or recorded in the voting transaction, each party (e.g., Fig.11 Each party A, B, and C) will sign the corresponding input of their voting transaction. While this signature can be seen as such a confirmation, there is no record in the blockchain of which vote belongs to which participant. In some cases, this information may be useful. At the same time, a party cannot sign a voting transaction until all parties have contributed their votes to the n-of-m multi-signature output script.

[0214] The second embodiment introduces a variation of the multi-factor multi-party decision-making protocol of the first embodiment that addresses the limitations described with respect to storage and confirmation of a party's vote in voting transactions of such a protocol. It does this by forcing the parties to disclose their votes in order to access the funds used as input to the voting transaction.

[0215] To achieve this, it is assumed that there are opcodes in the cryptographic script that allow elliptic curve (EC) "scalar point multiplication". This in turn requires removing the 200 opcode limit of the cryptographic script and re-enabling the disabled opcodes. A description of the techniques used in this embodiment is provided above in detail, including the homomorphic properties of the private-public key relationship in elliptic curve (EC) cryptography and the proposed opcodes.

[0216] The proposed protocol of this embodiment differs from the MFMP protocol of the first embodiment in that the voting element is stored in the (voting) transaction, and subsequently, "how and when" a signature can be made as confirmation that the vote has been represented.

[0217] Commitment Transaction

[0218] As in the first embodiment, the second embodiment is based on the following four core transactions: C 、Payment Transaction T P , Refund transaction T R and voting transaction T V The interfaces of these four transactions are as follows Fig.11 As indicated.

[0219] Commitment Transaction

[0220] like Fig.11 and Fig.12 As shown, the commitment transaction of this embodiment is different from that of the first embodiment in that the commitment transaction of this embodiment is expected to have at least four outputs. The first output is transferred to the second address S belonging to the supervisor. b This output address is used as an easy way for stakeholders to link commitment transactions to voting transactions using information stored in the blockchain. More importantly, it is used as a way to give overseers jurisdiction over voting transactions, as these outputs are also inputs to voting transactions, which require signatures.

[0221] The second output of the Commitment Transaction (as was the case in the first embodiment) is to hold in escrow a certain amount of coins - because the "winning" outcome of the decision tree will receive (or be funded from) these escrowed coins.

[0222] The second embodiment is different from the first embodiment in that the other outputs (at least two) belong to the voting party (for example, Fig.11 and Fig.12 These outputs are designed so that each party needs access to funds to produce their corresponding vote (and the signature of public key A). For example, if party A wants to spend the A output of the commitment transaction, he / she will have to include public key Q in the input script of the vote transaction. A,i =k A,i G's vote k A,i , thereby showing its vote k on the blockchain A,i .

[0223] Given that a party can vote in a variety of ways regarding its assigned factors, the output script of the commitment transaction of the voting party (e.g., Party A) is <scriptpubkey>Must include several options for accessing funds, each based on one of the voting party's options. Fig. 9 The structure of the multi-option (nested if-else) high-level script described, the cryptographic script for the condition (cond_i) that allows the payment of funds from option i is:

[0224] <basepoint G> OP_ECPMULT A,i >OP_EQUALVERIFY <puba>OP_CHECKSIG

[0225] As can be seen, the script makes use of the proposed opcode OP_ECPMULT discussed above under the heading “Elliptic Curve Finite Field Arithmetic and OPCODE”.

[0226] In order to satisfy (cond_i), voting party A needs to include <datai>element

[0227] 《sig A> <k A,i 》

[0228] Among them, sig A is the signature of public key A, k A,i It is the vote of Party A.

[0229] It should be noted that Party A's vote is shown in <datai>as part of the process of accessing the outputs of Party A's Commitment Transaction.

[0230] Voting transactions

[0231] The voting transaction of the second embodiment (see Fig.11 ) Through the commitment transaction S b The outputs of the voting party are "linked" to the commitment transaction. These outputs of the commitment transaction are the inputs of the voting transaction.

[0232] It is expected that the voting transaction itself will be constructed by the supervisor and then passed to the parties so that each party can sign their corresponding input. It should be recalled that (from the commitment transaction mentioned above) a party signing its input to a voting transaction is required to show the party’s vote k a,i .

[0233] The supervisor signs its input to the voting transaction and then submits the voting transaction to the blockchain.

[0234] It should be noted that the coins used / contributed by each party for its input to the voting transaction are a minimum fee or a nominal fee. The voting transaction is meant more as an immutable record of the vote rather than a transfer of funds.

[0235] Fig.13 A general overview of the multi-factor multi-party voting protocol is shown.

[0236] Now turn to Fig.14 , provides an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any of the systems shown and described above. For example, the computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Fig.14 As shown, computing device 2600 may include one or more processors (collectively referred to as 2602) with one or more levels of cache memory and memory controller, and the processor may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent storage device 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory 2602 may be used to store information, such as details associated with transactions and blocks described in the present disclosure. (One or more) processors 2602 may be used to provide the steps or functions of any embodiment described in the present disclosure.

[0237] The processor(s) 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 .

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

[0239] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface to receive data from other systems remote from the computing device 2600 and to transmit data to other systems. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network so that the data technician can transmit data to the device and receive data from the device while being located at a remote location (e.g., a data center).

[0240] The user interface input device 2612 may include one or more user input devices, such as a keyboard; a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen incorporated into a display; an audio input device such as a voice recognition system, a microphone, and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

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

[0242] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that may provide the functions of at least one embodiment of the present disclosure. When executed by one or more processors, an application (program, code module, instruction) may provide the functions of one or more embodiments of the present disclosure and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. In addition, the storage subsystem 2606 may provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage for programs and data, and may include flash memory, one or more solid-state drives, one or more magnetic hard drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM or DVD or Blue-Ray) drives with associated removable media, and other similar storage media. Such programs and data may include programs and data that are used to perform the steps of one or more embodiments as described in the present disclosure, and the data is associated with the transactions and blocks described in the present disclosure.

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

[0244] It should be noted that the above embodiments illustrate rather than limit the invention, and that a person skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprises" and "comprising" etc. do not exclude the presence of elements or steps other than those listed in any claim or in the entire specification. In this specification, "comprises" means "comprising or consisting of..." and "comprising" means "comprising or consisting of...". The singular form of an element does not exclude the plural form of such elements and vice versa. The present invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be implemented by one and the same item of hardware. The fact that certain measures are recited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

[0245] refer to

[0246] < / datai> < / datai> < / puba> ​< / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptpubkey> < / scriptpubkey> < / scriptsig> < / scriptpubkey> < / scriptsig> < / scriptpubkey>

Claims

1. A method for making decisions on a blockchain, wherein: The decision is based on at least one corresponding selection made by each of a plurality of participants, the method comprising: receiving a respective plurality of first public keys from each of a plurality of participants, wherein each of the first public keys represents a possible selection of the participant and is related to a corresponding first private key by a cryptographic operation having a homomorphic property; By means of the homomorphic property, the first public keys are combined to generate a plurality of second public keys, wherein each of the second public keys represents 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, wherein each of the third public keys corresponds to a respective second public key; Generating a first blockchain transaction, wherein an input of the first blockchain transaction is a script executable with the aid of a respective digital signature corresponding to a respective first private key of each of a plurality of the participants, wherein each first private key represents the selection made by the participant, and an output of the first blockchain transaction is a script representing the decision based on the selection made by the participant.

2. The method according to claim 1, wherein: The input of the first blockchain transaction is a script accessible by means of a fourth public key owned by the supervisor.

3. The method according to claim 1, wherein: The output of the first blockchain transaction is a multi-signature script accessible by means of a digital signature corresponding to a fifth public key possessed by the supervisor.

4. The method according to claim 3, wherein: A plurality of the first private keys are stored in a public key field of the multi-signature script.

5. The method according to any one of the preceding claims, further comprising: Generating a second blockchain transaction having at least one output corresponding to a respective input of the first blockchain transaction.

6. The method according to claim 5, wherein: Execution of at least one output of the second blockchain transaction requires at least one digital signature corresponding to the corresponding first private key.

7. The method according to claim 5, wherein: Execution of at least one output of the second blockchain transaction requires at least one of the first private keys.

8. The method according to claim 7, wherein: At least one output of the second blockchain transaction is a script that applies the cryptographic operation to the first public key.

9. The method according to any one of claims 1 to 4, further comprising: The first private key is received from the participant in encrypted form.

10. The method according to any one of claims 1 to 4, further comprising generating a third blockchain transaction for refunding at least a portion of the first digital asset.

11. The method according to claim 10, wherein: The third blockchain transaction is time-locked.

12. The method according to any one of claims 1 to 4, wherein: The cryptographic operation is elliptic curve scalar multiplication.

13. A computer system for implementing the method according to any one of the preceding claims.

14. A computer-implemented system comprising: processor; as well as A memory comprising executable instructions which, due to execution by a processor, cause the system to perform the method according to any one of claims 1 to 12.

15. A non-transitory computer-readable storage medium having executable instructions stored thereon, wherein the executable instructions, when executed by a processor of a computer system, cause the computer system to at least perform the method according to any one of claims 1 to 12.

Images