Computer-implemented systems and methods including public key combined authentication

Abstract

The present invention discloses a computer-implemented method. The method includes providing a blockchain transaction including a public key combination verification function. The blockchain transaction is configured to be redeemable to allow access to a resource or transfer control of a resource by providing input to the blockchain transaction, the input including: a plurality of public keys; a gradient value (λ) associated with two of the plurality of public keys; and a group public key derived from a combination of the public keys and the gradient value (λ). The blockchain transaction is configured to apply the public key verification function to the input to verify that the group public key is derived from a combination of the plurality of public keys after the transaction is successfully redeemed.

Description

Technical Field

[0001] The present disclosure relates generally to the transfer of control and / or access to resources, and more particularly to the transfer of such control and / or access using cryptographic multi-signature methods on a blockchain. Background Art

[0002] As used herein, the term "blockchain" encompasses all forms of computer-based electronic distributed ledgers. These ledgers include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. It should be noted that alternative blockchain implementations and protocols also fall within the scope of this disclosure. The term "user" herein may refer to a person or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset or resource (e.g., a tokenized item) 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 blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation. Transactions include small programs embedded in their inputs and outputs, called scripts, which specify how and by whom the output of the transaction is accessed. On some platforms, these scripts are written in a stack-based scripting language. The digital assets and resources in this article do not include encrypted virtual currencies.

[0004] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes 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 outlay (UTXO) by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to 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, the transaction must: i) be validated by the first node that receives the transaction - if the transaction is validated, this node relays it to other nodes in the network; and ii) be added to a new block that is constructed; and iii) be mined, that is, added to the public ledger of past transactions.

[0005] Digital entrepreneurs have begun to explore how to implement new systems using cryptographically secure systems and data that can be stored on blockchains. It would be very beneficial if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of blockchains (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more widely applicable.

[0006] Another area of ​​interest related to blockchain is the use of "tokens" to represent and transfer real-world entities through blockchains. Potentially sensitive or confidential items can be represented by tokens that do not have discernible meaning or value. Thus, tokens act as identifiers that allow real-world items to be referenced from the blockchain.

[0007] Blockchain transactions can utilize a built-in multi-signature protocol to restrict transactions such that M of the N total signatures need to be present as inputs to the redemption script in order to redeem the transaction. For example, a transaction can be locked using three of five multi-signatures such that the transaction can only be unlocked by using three private keys corresponding to any three of the five multi-signatures.

[0008] For the M / N (M of N) method, the opcode OP_MULTISIG takes N public keys and M signatures as input. In this example, the N public keys are stored in the redeem script itself. The opcode starts with the first signature and searches through the N public keys to test if the signature was created by that public key. It discards each key that does not match the signature. To do this, the order of the signatures must match the order in which the public keys were provided. An example of a multi-signature redemption script is as follows:

[0009] Redeem script <PubKey 1><PubKey 2>… <pubkeyn>OP_CHECKMULTISIG < / pubkeyn>

[0010] When unlocking, the following input needs to be presented:

[0011] Input <sig 1><Sig 2>…<Sig M>

[0012] As can be seen above, the size of the redemption script scales linearly with the number of signatures required, M, and the number of participants, N. Therefore, as M and N increase, the number of signatures required to redeem a transaction increases, and the number of public keys in the redemption transaction also increases. As a result, the network speed required to propagate subsequent redemption transactions and the space required to store subsequent redemption transactions increase. Furthermore, the number of operations required to merge the unlocking script of a redemption transaction with the redemption script grows linearly in N and M.

[0013] Therefore, there is a need to provide a solution for reducing the operational and storage requirements associated with the transmission, processing and storage of blockchain transactions, such as blockchain transactions utilizing multi-signature protocols and particularly blockchain transactions requiring the storage of a large number of public keys. Summary of the invention

[0014] Such an improved solution has now been devised.

[0015] According to the present disclosure, a computer-implemented method is provided, which can be described as a security method.

[0016] The method comprises the following steps: providing a blockchain transaction comprising a public key combination verification function, the blockchain transaction being configured to be redeemable to allow access to a resource or transfer control of a resource by providing input to the blockchain transaction, the input comprising: a plurality of public keys; at least one gradient value associated with respective two of the plurality of public keys; and a group public key derived from a combination of the plurality of public keys and the at least one gradient value, wherein the blockchain transaction is configured to apply the public key verification function to the input to verify that the group public key is derived from a combination of the plurality of public keys upon successful redemption of the transaction.

[0017] The method provides a means to transfer control or access to resources represented and / or controlled by multiple private keys in a secure, reliable, and publicly verifiable manner.

[0018] The method further comprises the steps of: deriving a derived public key from a known value; and, setting the derived public key as a sequence of secondary public keys, wherein the sequence of secondary public keys is a subset of the plurality of public keys.

[0019] This enables the user to convert known requirements in the method into a public key to be used by the method, thereby providing the advantage of improving the versatility of the method. A further advantage is provided that the coefficients of the sequence can be calculated in advance, thereby increasing the speed at which the method can be performed.

[0020] The method may comprise the step of applying a restriction function to the known value prior to setting the derived public key as a sequence of secondary public keys, thereby restricting the size of the subset.

[0021] This offers the advantage of further increasing the efficiency of the method.

[0022] The method may include the step of computing a public key of the plurality of public keys based at least in part on another public key of the plurality of public keys and the derived public key.

[0023] This has the advantage that it removes the requirement to store a given plurality of public keys, given that one or more of the plurality of public keys may be derived from one stored public key.

[0024] The blockchain transaction may further include: a group signature corresponding to the group public key; a Merkle root; and a Merkle path verification function, wherein the blockchain transaction is configured to be redeemable by providing the blockchain transaction with the following: a Merkle path associated with the multiple public keys; and a group private key corresponding to the group signature.

[0025] This method requires fewer processing steps to achieve a given security level, thereby providing the advantage of increasing the efficiency of the method while maintaining security.

[0026] The present disclosure also provides a system, comprising a processor; a memory, comprising executable instructions, wherein when the processor executes the executable instructions, the system is caused to perform any embodiment of the computer-implemented method described herein.

[0027] The present disclosure also provides a non-transitory computer-readable storage medium having executable instructions stored thereon. When a processor of a computer system executes the executable instructions, the computer system is caused to at least perform an embodiment of the computer-implemented method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0029] Figure 1 is a table showing data encoding for an uncompressed public key;

[0030] Figure 2 is a table showing the stack evolution of executing an embodiment of the present disclosure;

[0031] Figure 3 is a table showing the stack evolution of executing an embodiment of the present disclosure;

[0032] Figure 4 is a table showing the relationship between M, N and script size for different multi-signature methods;

[0033] Figure 5 Two transactions embodying the present disclosure are schematically shown;

[0034] Figure 6 is a flow chart showing a series of steps embodying the present disclosure;

[0035] Figure 7 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0036] The present invention discloses a method for adding two elliptic curve points in a verification script. Given two points P 1 , P 2 and a candidate solution P 3 , this public method verifies P in the script 3 =P 1 +P 2 The present invention discloses another method, which extends the previous method to a series of point additions.

[0037] These methods can be used for signature methods for multiple participants, such as multi-signature methods. The Elliptic Curve Digital Signature Algorithm (ECDSA) protocol can be used in the method.

[0038] The elliptic curve of prime order p is defined by the following equation:

[0039] y 2 =x 3 +ax+b.

[0040] According to the group structure of the curve, the curve P 1 =(x 1 ,y 1 ) and P 2 =(x 2 ,y 2 ) to get the third point P 3 =(x 3 ,y 3 ), namely P 3 =P 1 +P 2 .

[0041] Click P 3 Defined as a point on the elliptic curve that passes through the connection P 1 and P 2 and then the line reflected around the x-axis. The formula for point addition is:

[0042] x 3 =λ 2 -x 1 -x 2 mod p

[0043] y 3 =λ(x 1 -x 3 )-y 1 mod p,

[0044] Among them, when P 1 ≠P 2 When , the gradient λ is given by the following formula:

[0045]

[0046] When P 1 =P 2 When , the gradient λ is given by the following formula:

[0047]

[0048] Among others, the secp256k1 convention is used, where the elliptic curve parameters are given by a=0 and b=7.

[0049] Applying the extended Euclidean algorithm in the script of a blockchain transaction is not practical because it requires computing modular inverses and therefore cannot perform the elliptic curve point addition defined by the above equation in the script.

[0050] The method disclosed below is used to verify that two points P 1 and P 2 Add the solution. Solution P 3 =P 1 +P 2 The computation itself is performed outside the script, while the answer is verified in the script. This reduces the computational requirements that would otherwise be imposed on the blockchain nodes.

[0051] To achieve this verification, we need to solve P 3 , and P 1 With P 2 The gradient value of the line between (denoted as λ). The calculation of λ is performed outside the script, while the verification of λ is performed inside the script.

[0052] New public key verification function detailed below <Point Add P 1 , P 2 ,λ,P 3 >Configured as: When the λ presented is P 1 With P 2 When the gradient of the line between 3 =P 1 +P 2 These two validations are implemented directly in the script and are published once the transaction is successfully redeemed.

[0053] The execution of the function consists of the following steps:

[0054] 1. Verify the value of λ by checking the following:

[0055] a) When P 1 ≠P 2 hour,

[0056] λ(x 2 -x 1 )mod p=y 2 -y 1mod p

[0057] b) When P 1 =P 2 hour,

[0058]

[0059] 2. By checking P 3 =(x 3 ,y 3 ) satisfies the following equation to verify P 3 Value

[0060] x 3 =λ 2 -x 1 -x 2 mod p and

[0061] y 3 =λ(x 1 -x 3 )-y 1 mod p.

[0062] By applying successive iterations of the public key verification function, the sum of any number n of public keys can be verified, with the only restrictions being the requirements of the blockchain protocol being used, such as the number of opcodes (201) or the byte size (10000).

[0063] The above public key verification function is used for three public keys to verify that two public keys are combined to produce a third public key. This can be extended to verify that three public keys P = P 1 +P 2 +P 3 The extension function denoted PointAddMulti is defined as follows, where the verification process verifies that P1, P2, and P3 are combined to produce P:

[0064] <Point Add Multi P 1 , P 2 , P 3 ,λ′,λ,P>:=

[0065] <Point Add P 1 , P 2 ,λ′,P′> <Point Add P′,P 3 ,λ,P>

[0066] Where P′=P 1 +P 2 , the value λ′ is P 1 With P 2 The gradient between P′ and P3 The gradient between .

[0067] In general, given n public keys P that combine to produce a public key P i , PointAddMulti can be defined as follows:

[0068] <PointAddMulti P i ,λ i , P>:=

[0069] <PointAdd P 1 , P 2 ,λ 1 , P′ 1 > <PointAddP′ 1 , P 3 ,λ 2 , P′ 2 >… <PointAdd P′ n-2 , P n ,λ n-1 ,P>

[0070] The point addition function PointAdd can be constructed using the method disclosed below.

[0071] Figure 1 The data encoding for an uncompressed public key is shown in .

[0072] Given an uncompressed public key P, the x and y coordinates can be extracted directly in the script using the operator OP_SPLIT as follows:

[0073] OP_1OP_SPLIT OP_NIP 32OP_SPLIT= <x> <y>.

[0074] Using this operation, we can get the value from the input P 3 ,λ,P 1 , P 2 Extract the x and y coordinates from:

[0075] <P 3 ><λ> <P 1 > <P 2 >→ <x 3 > <Y 3 ><λ> <x 1 > <y 1 > <X 2 > <y 2 >

[0076] It should be noted that the terms on the right hand side above may be duplicated and rearranged to produce any desired combination using basic operations.

[0077] See also Figure 2 , the first step in constructing the PointAdd function is to verify the input value λ. 1 ≠P 2 In the case of , check whether the following equation is true:

[0078] λ(x 2 -x 1 )mod p=y 2 -y 1 mod p. This is done by <Y 2 > <y 1 ><λ> <x 2 > <x 1 > as input and operates on that input using the following operations:

[0079] OP_SUB OP_MUL< / y> < / x> OP_MOD OP_3OP_ROLL OP_3OP_SUB

[0080] OP_MOD OP_EQUAL

[0081] If and only if the equation λ(x 2 -x 1 )mod p=y 2 -y 1 mod p, it returns TRUE. Figure 2 The table shows the evolution of the stack when performing the above operations.

[0082] For P 1 =P 2 In the case of , a set of operations similar to the above can be constructed to check whether the following equations hold:

[0083]

[0084] See also Figure 3 , the second step in constructing the PointAdd function is to verify P 3 The input value is P 1 +P 2 To do this, check whether each of the following equations holds:

[0085] x 3 =λ 2 -x 1 -x 2 mod p, and

[0086] y 3 =λ(x 1 -x 3 )-y 1 mod p,

[0087] Since λ has been verified, it can be used in the following calculations. To check whether the first of the two equations above holds, the following is presented as input:

[0088] <x 3 ><λ> <x 1 > <x 2 >

[0089] And use the following operation to operate:

[0090] OP_3OP_ROLL OP_DUP OP_MUL OP_SWAP OP_SUB OP_SWAP

[0091] OP_MOD OP_EQUAL.

[0092] Here, p is the order of the base field of the elliptic curve.

[0093] Figure 3 The table shows the evolution of the stack when performing the above operations.

[0094] By converting the existing public key P 1 Add to the point G generated by the elliptic curve multiplied by the value S∈ The calculated public key is used to create a new public key P3, so: P3 = P1 + S·G.

[0095] S can be the original public key P 1 Create a derived public key P 3 Deterministic key.

[0096] Formula P 3 =P 1 The point addition verification of +S·G can be achieved by verifying a point addition sequence involving a fixed multiple of the generating point G.

[0097] For example, double addition can be used to decompose point addition into a series

[0098] P 3 =P 1 +s 0 G+s 1 2G+s 2 4G+s 3 8G+…+s 256 2 256 G

[0099] where s 0 , ..., s 256 ∈(0, 1} are the coefficients in the binary expansion of S as follows:

[0100] S=s 0 +s 1 2+s 2 4+s 3 8+…+s 256 2 256 .

[0101] By making the generators G, 2G, 4G, ..., 2 256 The points obtained by doubling G are common knowledge and can be pre-calculated. This means that there may be 255 separate points added that need to be verified to get the final result.

[0102] Therefore, the maximum value of 255+1=256 points can be used to verify P 3 =P 1 +S.G.

[0103] In addition to double addition, other point-addition algorithms may be used, such as sliding window or Montgomery staircase.

[0104] To make the point addition computation using the computed key more manageable, S may be restricted to a smaller range. The range may be application specific.

[0105] S may need to be The value can be taken from the 32-bit range. represents a range of 4.3 billion values. However, only 31 individual points need to be added to verify the final result. This can be achieved, for example, by starting with S in the full 256-bit range and then applying the modulus operation OP_MOD to limit that range to 32 bits. x Can be used through P x +S·G sum to blur the range.

[0106] For example, the maximum bid at a used car auction might be $16,000. The $t bid, in the form of the number 16000, can be added to the public key P 1 to obtain the additional key,

[0107] P=P 1 +t·G,

[0108] This can be verified by adding the 14 points in the script.

[0109] To understand how this is used in the bidding process, assume that the current highest bid for a car is $9,000, which is tracked by a specific UTXO. This UXTO has a redemption script:

[0110]

[0111] The following are required as input for unlocking:

[0112] <![CDATA[<Sig P> <Verification data><P 1 > <t> ]]> < / t>

[0113] Then, the point addition verification method described above can also be used to verify that P = P 1 +t·G. Note that this involves verification of 14 individual points added together. The data used for this verification is marked as "Verification Data" in the above input.

[0114] If a new bid t>9000 is provided, the UTXO can be unlocked. The new bidder must send its public key P 1 and the solution P provides to and P = P 1 +t·G. The fact that it signs the transaction with the additional key P makes it always linked to a specific t dollar bid.

[0115] As another example, consider searching for a nonce (a number) that, when hashed with a block in the blockchain (such as the current block), produces a value below a certain threshold. A unique key P = P can be created using its public key plus the first 9 digits of the nonce. 1 +(first 9 digits of nonce) · G locked transaction. For the first 9 digits of a number, there are a billion combinations. Therefore, 30 points can be added to verify the public key P. This keeps the secret key P linked to the public key and the nonce of the mined block.

[0116] The script point addition verification process described above can be used to implement an efficient way to sign transactions using M / N (M-of-N) multi-signature method, thereby realizing a more efficient and secure method for transferring control of or access to resources using blockchain.

[0117] For the M / N method, the opcode OP_MULTISIG takes N public keys and M signatures as input. The opcode starts with the first signature and searches through the N public keys to test to see if the signature was created by that public key. It discards each key that does not match the signature. To do this, the order of the signatures must match the order in which the public keys were provided.

[0118] The multi-signature redemption script is as follows:

[0119] <PubKey 1><PubKey 2> …<PubKey N> OP_CHECKMULTISIG

[0120] The following are required as input for unlocking:

[0121] <sig 1><Sig 2> …<Sig M> .

[0122] As can be seen above, the script size varies linearly with the number of signatures M required and the number of participants N.

[0123] See also Figures 4 to 6 , a Merkle tree is created where a leaf corresponds to each M / N combination of public keys, and the Merkle tree contains N select M leaves in total. Next, a redemption script is created that contains the Merkle root and requires a presentation unlocking and signature verification method for the input containing the Merkle path.

[0124] The following describes two methods for transferring control of or access to a resource. Each method has its own advantages and disadvantages.

[0125] 1. Individual signature method. This method uses each signature to sign the transaction separately and has the same functionality as multi-signature, but with a smaller script size.

[0126] 2. Group signature. This method provides a single signature for M participants in a signing group. It can be any public key agreed in advance by each set M of participants, such as a key derived from a shared key, or a key formed by summing the public keys of the group. In the latter case, an additional option for verifying that the key is the sum of the individual member keys uses the verification method described previously.

[0127] Each method has different scaling properties, such as Figure 4 The table shown summarizes what is shown.

[0128] Consider the 4 / 5 method. In this case, the Merkle tree will have 5 choices. leaves. The Merkle tree itself will be three levels deep. <r>The operation of the Merkle path is

[0129] <Verify Merkle Path> =

[0130] 6OP_PICK OP_SHA256(OP_SWAP OP_IF OP_SWAP OP_ENDIF OP_CATOP_SHA256)*3 <r>OP_EQUALVERIFY

[0131] It will return TRUE for a Merkle path of the form

[0132] <leaf><Grandparent Sib><0,1><Parent Sib><0,1> <sib><0, 1>

[0133] Among them, there is 0 when the sibling node is the left node, and there is 1 when the sibling node is the right node.

[0134] The number of Merkle paths and operations to verify them grows logarithmically with the number of choices of M from the signature set N.

[0135] In the individual signature method, each member of the group provides a personal signature for the transaction. The functionality of this method is the same as the standard multi-signature method, but the script size is reduced, making the execution of the script more efficient. The script takes the following form:

[0136] <Verify Merkle Path> <checksig>*M

[0137] It requires presentation unlock for the following inputs:

[0138] <Sig P 1 >… <Sig P M > <P 1 >… <P M > <Merkle PathP 1 , ..., P M >

[0139] The redeemer must provide as input M signatures with their corresponding public keys and the Merkle path of P.

[0140] In this method, P 1 , ..., P M The mapping to the Merkle tree leaves can be, for example, P using OP_CAT 1 , ..., P M Cascading hashing.

[0141] The key feature of this method is that each member signs a specific transaction. They do not reveal any information about their private keys to each other, and therefore the security of their private keys is not compromised.

[0142] See also Figure 4 , it can be seen that this method has favorable scaling properties compared to traditional multi-signature methods. This is most obvious when the multi-signature mechanism is at low M and large N (e.g. 5-of-1000).

[0143] In the group signature method, only one signature is required for a group of M members signing a transaction. The script takes the following form:

[0144] <Verify Merkle Path> <checksig>

[0145] It requires presentation unlock for the following inputs:

[0146] <Sig P> <Merkle Path>

[0147] Here, P is the group public key for the set of M participants.

[0148] The advantage of this method is that the size of the unlocking script is extremely small, since it only requires one signature. The number of script public key additions scales linearly with the number of participants M, so in terms of processing power, this method offers a lower cost operation than checking individual signatures.

[0149] This method requires the participants to share their private keys with each other. This means that the key pairs used in this method are one-time use key pairs, which helps to increase the security of this method. Another feature is that any member of the participants who has access to the group private key can sign any transaction they wish to make. This increases the versatility of the method. This feature is particularly needed in certain application cases. For example, a group of directors wants to activate the established final terms that have been recorded as UTXO on the blockchain. This can be activated by unlocking a specific UTXO using this method.

[0150] In the above method, an external observer will be completely unaware that this is actually a group signature method. In order to publicize the fact that the signature and the corresponding public key are associated with a group of users, the method can be modified to require verification that the group public key is the sum of the public keys of the individual participants in the script P = P 1 +…+P M This adjustment method can use the key addition authentication method described above.

[0151] In this adapted approach, the redemption script could take the following form:

[0152] <Verify Merkle Path><Point Add Multi P 1 , ..., P M ,P> <checksig>

[0153] It requires presentation unlock for the following inputs:

[0154] <Sig P>< / checksig> <Verification data> <P 1 >… <P M ><Merkle Path>

[0155] in <Point Add Multi P 1 , ..., P M , P> function is the function introduced earlier, and <verificationdata>Contains the gradients summed between each individual point.

[0156] Figure 5 A pair of transactions Tx1 and Tx2 are shown. Tx1 defines a UTXO with a redemption script that contains a verify Merkle path function, a PointAddMulti function customized for specific M / N requirements, and a CheckSig function. Tx2 defines a transaction that is subsequently submitted to the blockchain, which is intended to redeem Tx1's UTXO by presenting a group signature in the input, a group public key associated with the group signature, the gradient required by the PointAddMulti function, the public key of the user group, and the associated Merkle path.

[0157] Figure 6 A flow chart is shown which shows the steps taken to perform the method according to the individual signature method and the group signature method described above. Figure 6 In the example, Tx1 and Tx2 may refer to a pair of transactions used according to either method.

[0158] Now go to Figure 7 , provides an illustrative simplified block diagram of a computing device 2600 that can be used to implement 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. Figure 7 As shown, computing device 2600 may include one or more processors with one or more levels of cache and a memory controller, which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent memory 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 may be used to store information, such as details associated with transactions and blocks described in the present disclosure. Processor 2602 may be used to provide the steps or functions of any embodiment described in the present disclosure.

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

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

[0161] The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can serve as an interface for receiving data from the computing device 2600 and transmitting data to other systems. For example, the network interface subsystem 2616 can enable a data technician to connect the device to a network, so that the data technician can send data to the device and receive data from the device at a remote location (e.g., a data center).

[0162] The user interface input devices 2612 may include one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen included in 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 to the computing device 2600.

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

[0164] 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. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and cache memory may provide volatile storage for programs and data. The permanent storage 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 with associated removable media (e.g., CD-ROM or DVD or Blu-ray) and other similar storage media. This program and data may include a program for executing the steps of one or more embodiments as described in the present disclosure, and data associated with transactions and blocks as described in the present disclosure.

[0165] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, lightning connector, etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted via the port that connects the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, Figure 7 The depiction of computing device 2600 is intended only to illustrate a specific example of a preferred embodiment of the device. Figure 7 There are many other configurations with more or fewer components of the systems shown.

[0166] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure. In the claims, any figure marks in brackets shall not be interpreted as limiting the claims. The words "including" and the like do not exclude the presence of elements or steps other than those listed as a whole in any claim or the specification. In this specification, "including" means "including or consisting of...". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present disclosure may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim listing several devices, several of these devices may be embodied by the same hardware. The mere fact that certain measures are recorded in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.< / verificationdata> < / checksig> < / checksig> < / sib> < / leaf> < / r> < / r>

Claims

1. A computer-implemented method comprising the following steps: A blockchain transaction is provided, the blockchain transaction comprising a public key combination verification function, the blockchain transaction being configured to be redeemable to allow access to a resource or transfer control of a resource by providing inputs to the blockchain transaction, the inputs comprising: A plurality of public keys, each of the public keys being a point on an elliptic curve; at least one gradient value that is a gradient of a line between corresponding two public keys of the plurality of public keys; and, a group public key derived from the elliptic curve point addition of the corresponding two public keys, wherein the blockchain transaction is configured to apply the public key verification function to the input to verify that the group public key is derived from the elliptic curve point addition of the corresponding two public keys upon successful redemption of the transaction; The resources described herein do not include encrypted virtual currencies.

2. The method according to claim 1, comprising the steps of: Derive a derived public key from a known value; and, setting the derived public key as a sequence of secondary public keys, The sequence of secondary public keys is a subset of the multiple public keys.

3. The method according to claim 2, comprising the steps of: A restriction function is applied to the known value prior to performing the sequence of setting the derived public key as a secondary public key, thereby restricting the size of the subset.

4. The method according to claim 3, comprising the steps of: A public key of the plurality of public keys is calculated based at least in part on another public key of the plurality of public keys and the derived public key.

5. The method according to any one of claims 1 to 4, wherein the blockchain transaction further comprises: a group signature corresponding to the group public key; Merkel Root; and, Merkle path verification function, wherein the blockchain transaction is configured to be redeemable by providing the following to the blockchain transaction: a Merkle path associated with the plurality of public keys; and, A group private key, which corresponds to the group signature.

6. A computer-implemented system comprising: processor; and a memory comprising executable instructions, wherein when the executable instructions are executed by the processor, the system is caused to perform the computer-implemented method according to any one of claims 1 to 5.

7. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, causes the computer system to at least perform the computer-implemented method according to any one of claims 1 to 5.

Images