Blockchain-implemented method and system

Abstract

To provide a method and a system for implementing, controlling and / or automating a task or process in order to record or express execution of a portion of logic.SOLUTION: In a method: each redeem script included in a blockchain transaction is associated with a corresponding private key; an agent communicates with a control agent that generates the redeem script; a control agent provides a basic key; a minimum number of private keys to use an output is used to sign an unlock script for further transactions; it is determined which of the plurality of associated private keys is used to sign the unlock script in order to provide an intermediate result, and a result is provided based on a comparison of parameters provided by the unlock script with intermediate results; and it attempts to use the output of the transaction more than once by providing different parameters.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to distributed ledger technology (including blockchain-related technology), and in particular to the use of blockchain in performing, controlling, and / or automating a task or process. The present invention may relate to the use of blockchain or related technology to record or represent the execution of a portion of logic. This portion of logic may be configured to implement the function of a logic gate or multiple logic gates, such as AND, XOR, NOT, OR, etc. [Background technology]

[0002] It is important to note that, for the purposes of this specification, we use the term "blockchain" for convenience and ease of reference, as it is the most widely known term currently in this context. However, the term is used herein (including in the claims) to encompass all forms of electronic, computer-based distributed ledgers, including, but not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof.

[0003] A blockchain is an electronic ledger implemented as a computer-based decentralized distributed system composed of blocks. Blocks in turn are composed of transactions. Each transaction contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks chain together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs. Scripts specify how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) run the work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Software clients installed on nodes perform this validation work on unspent transactions (UTXOs) by running their own lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and the transaction is written to the blockchain.

[0005] The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although Bitcoin is referred to herein for convenience and purposes of explanation, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations are within the scope of the present invention.

[0006] Blockchain technology is most widely known for its use in implementing cryptocurrencies. However, more recently, digital entrepreneurs have begun to explore both the use of the cryptocurrency security system on which Bitcoin is based, and the data that can be stored in the blockchain, to implement new systems. It would be highly advantageous if blockchain could be used for tasks and processes that are not limited to the cryptocurrency realm, such as automated control processes. Such solutions would be more diverse in their applications, while still being able to take advantage of the advantages of blockchain (e.g. permanent, tamper-resistant record of events, distributed processes, etc.).

[0007] Such an improved solution has been devised.According to the present invention there is therefore provided a system and method as defined in the accompanying claims. Summary of the Invention

[0008] Thus, according to the invention, a computer-implemented method may be provided. The invention may be described as a control method. The invention may control the operation of a technical process or the operation of one or more devices. Additionally or alternatively, the invention may control the execution of a blockchain script. The invention may control outputs generated by attempts to unlock lock scripts associated with transaction outputs (UTXOs). The invention may control whether outputs (UTXOs) in a blockchain transaction are unlocked. The invention may control whether a portion of cryptocurrency is transferred from one party to another via the blockchain. can be controlled.

[0009] The present invention may be constructed substantially in accordance with the embodiment shown in FIG.

[0010] The method may include providing a blockchain transaction (Tx) including a redeem script for the output, where the redeem script specifies a number of public keys. These may be cryptographic keys. They may form part of a public / private key pair. Each of the keys in the number (or "list") may be associated with a corresponding private key. Each public key may be uniquely associated with at least one possible state of the data source. Thus, the redeem script may include a list of public keys, only whose corresponding private keys may be used to spend the transaction output (TxO).

[0011] The outcome may be determined or affected by which of multiple associated private keys is used to sign the unlock script. A comparison of the private keys used to sign the script may provide an intermediate result. The comparison may be performed against a known or predefined parameter or value provided in the script. The predefined parameter or value may represent the computational agent's desire to use (or not use) the transaction output. A comparison may be made against the intermediate result of a parameter provided via the unlock script.

[0012] Thus, embodiments of the present invention may enable a blockchain transaction (Tx) to return a non-true value from a script, which may be accomplished using a parameter to verify or determine that the output of the script matches a supplied target value represented by or associated with the parameter.

[0013] The method may include the step of attempting to spend the transaction output more than once. In effect, this is double (or more) spending. Double spending is traditionally considered bad practice, as it involves attempting to transfer the same amount of cryptocurrency to different recipients. However, in this application, it is used to advantage.

[0014] Each attempt to spend may include submitting a (different) transaction to the blockchain network. Each attempt may be performed with a transaction that provides or supplies different parameters to the Redeem script. Each attempt may generate a blockchain transaction that attempts to spend the output to a different (blockchain) address.

[0015] The parameter provided by the unlock script may represent true or false. It may be a puzzle, such as a cryptographic puzzle. It may be a value embedded in a key. The method may comprise the step of extracting the value from the key.

[0016] The logic may be configured to perform an equality check or comparison. The check or comparison may compare the intermediate results to the parameters. The intermediate results may be provided by executing logic provided or embedded in the Redeem script, which may be a portion of the logic configured to emulate or provide the functionality of a logic gate. The intermediate results may be placed on / read from a stack in memory.

[0017] The method may include generating a transaction, which may include providing the transaction to a blockchain.

[0018] The transaction and / or further (usage) transactions may be generated by a computational agent. The transactions may be generated automatically (without human intervention) based on input received from sensors or other sources.

[0019] Additionally or alternatively, the Redeem Script may include portions of logic configured to provide results based on which of multiple public keys is used to sign the Unlock Script, and thus execution of logic provided within the Redeem Script may be determined or affected by which associated private key was used to sign the Unlock Script.

[0020] Additionally or alternatively, a minimum number of said private keys may be required to sign unlock scripts for further blockchain transactions to spend the outputs.

[0021] The outcome or output provided by the logic may depend on determining which (particular) private key was used to sign the unlock script. The method may include verifying the private key used to sign the unlock script against the associated public key provided in the Redeem script.

[0022] Advantageously, this allows the present invention to provide a greater degree of control than prior art techniques that simply require that a particular number of keys be used, rather than a particular key being used. By determining which particular key from among several is used, the present invention provides an alternative enhanced security technique that allows for a greater degree of granularity or sophistication when controlling the locking / unlocking of transaction outputs UTXOs. Thus, the present invention can be said to provide an improved cryptographic technique for controlling the transfer of portions of cryptocurrency.

[0023] The intermediate result is a Boolean value that is derived from logic provided in the Redeem Script and / or calculated by determining which key was used to sign the Unlock Script.

[0024] The logic in the Redeem script may be configured to implement the functionality of logic gates. The logic gates may be NOT, AND, OR, NOR, XOR, IMPLY, NAND, NONIMPLY, and / or XNOR gates. Thus, the present invention may be described as providing techniques that allow the functionality of the logic gates to be simulated or achieved by blockchain transactions. The portions of the script logic that emulate the logic gates may provide intermediate results.

[0025] The state of the at least one data source can be determined by a computational agent, which can be configured to monitor a condition, which can be, for example, a condition on a computing network, or a device-related condition, or a condition of an environmental factor, or any other type of quantifiable condition.

[0026] The computational agent can be in communication with a controlling computational agent, which may be referred to herein as a “controller.” Redeem scripts can be generated by the controller. One or more agents can be configured to control a process or equipment.

[0027] One, some, or all of the computational agents may have a cryptographic key, which may be referred to as an agent base key. The cryptographic key may be generated by the agent. The cryptographic key may be derived and / or received from the control unit. One or more of the keys may be generated or derived from a base or "master" key. The key generation may be performed using deterministic key generation techniques. The method may include generating or deriving further or separate keys for each possible state of the condition being monitored by the agent. The further keys may be derived from the base key using techniques described below in the section entitled "Generating Keys Using a Shared Secret".

[0028] The result provided by the logic may be a Boolean result or some other type of result. The logic may provide a result from a limited range of outcomes.

[0029] There may be at least two data sources. There may be two possible states for or associated with each data source. Each possible state may be associated with or represented by a public key. Thus, the list of public keys provided in the Redeem script may be used to define, represent, or describe all possible states that a data source may adopt or enter.

[0030] The method may include the following steps: For each of at least one data source, Associating the public keys from the plurality with possible states of the data source.

[0031] Thus, every possible state of a data source is represented by its respective public key.

[0032] In other words, each possible state of each data source may be associated with a public key, allowing the public key to be used as a (unique) identifier of that state. Thus, the keys may be carefully selected to form a mapping between each key and the possible states of the data source. This may allow the keys to act as a representation of the possible states of the data source. Analysis or determination of which private key is used to sign in the unlock script may then allow the state of the data source to be determined.

[0033] At least one data source may include a sensor. Additionally or alternatively, the data sources may include sources capable of generating and / or transmitting input signals to the computational resources or agents.

[0034] Each public key may represent a Boolean value indicating a possible state of at least one data source, for example whether a signal is received or not, or whether the temperature is above 20 degrees C.

[0035] The invention also provides a corresponding system, which may be configured to perform any embodiment of the method described above. The system may be configured to perform a method or technique substantially as shown in FIG.

[0036] The present invention provides a computer-implemented system comprising: at least one computer-based resource configured to perform the steps of any of the methods described above; A blockchain or other type of electronic ledger, or a variation of the Bitcoin ledger; This may be a distributed ledger.

[0037] At least one computer-based resource Submit the transaction to a blockchain network (which may or may not be the Bitcoin network, which may be any kind of distributed ledger); and / or Generate a transaction, and / or Digitally sign the lock script, and / or It may be configured to generate public / private cryptographic keys.

[0038] The system may be configured such that the results are used to control or influence the performance or operation of a process or equipment. The computer-based resources may be referred to as "agents."

[0039] The system can include at least one sensor or other signal / input generating component arranged / configured to provide input to at least one computer-based resource.

[0040] Any feature described in connection with one embodiment or aspect of the invention may be used in conjunction with one or more other embodiments or aspects, and any feature described in connection with a method may be applied to a system, and vice versa. [Brief description of the drawings]

[0041] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Figure 1] 1 shows a diagram of one embodiment of the present invention. [Diagram 2] An illustrative embodiment of the present invention is shown in which a number of independent computational agents perform monitoring of the external environment to provide input to logic gate transactions. [Diagram 3] 1 shows an overview of a preferred embodiment of the present invention. [Figure 4]1 illustrates an exemplary blockchain transaction in which transaction output 1 implements a NOR gate with transaction output 2 and refunds a controller, configured in accordance with an embodiment of the present invention. [Diagram 5] 1 shows an overview of another embodiment of the present invention. [Figure 6] A technique for generating an encryption key from a base key is shown. [Figure 7] A technique for generating an encryption key from a base key is shown. [Figure 8] A technique for generating an encryption key from a base key is shown. [Figure 9] A technique for generating an encryption key from a base key is shown. [Figure 10] A technique for generating an encryption key from a base key is shown. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] The present invention provides a novel and advantageous solution of using a blockchain to perform a function. The blockchain is used to provide a record of the execution of the function and / or the results of its outcome. A function can be a subroutine or procedure (i.e., a process or piece of logic) that applies to a set of inputs and returns a set of outputs. In one possible embodiment, the function can be performed "off-block", i.e., the execution of the function does not depend on the blockchain. The function is performed by a computer-based resource.

[0043] A blockchain (e.g. Bitcoin) transaction is a transfer of value that typically references previous transaction outputs as new transaction inputs and contributes all input values ​​to the new output. Transactions are not encrypted; therefore, it is possible to view and examine all transactions ever collected into a block. However, it would be highly advantageous to be able to construct blockchain transactions that act as functions, where transaction outputs are conditional or dependent on information supplied. This could enable sophisticated functionality to operate over the blockchain.

[0044] Important aspects of the present invention include (but are not limited to) a method for generating blockchain transactions where functional inputs are represented by public keys used in the redeem script of the transaction's outputs and actual values ​​are represented by signatures associated with one or more of the public keys.

[0045] The invention is illustrated by the use case provided below, where blockchain (e.g. Bitcoin) transactions can be used to represent functions provided by logic gates, which can then be used to control some technological process or equipment.

[0046] The present invention provides a number of general purpose novel features beyond blockchain, including: The ability to create agents in response to sensors or other signal / input generators, where the agents are controlled directly from the blockchain and do not require other network access to operate; · For transactions secured by multiple signatures, the ability to determine which public keys were involved in the transaction signing process; The ability to embed a limited and distinct range of payload values ​​within the signing key that can be used to determine behavior within the Redeem script (e.g., how the code executes).

[0047] Additionally, embodiments of the present invention can utilize the elements described above to provide a logic gate (e.g., a NOR gate) where the input values ​​from A and B are embedded in or represented by the key used for signing.

[0048] <Advantages> The proposed invention offers the following advantages: · Inherently secure by design (the Bitcoin protocol does not require a trusted party); It is distributed, thus avoiding a large single point of failure and is not vulnerable to attacks; · It is easy to manage and maintain, and the Bitcoin network is straightforward to use; Not expensive (usually only small transaction fees are expected under the Bitcoin protocol); · It is global and can be used by anyone with access to the Internet at any time; · Transparent; Once data is written to the blockchain, anyone can see it; · It is immutable, once data is written to the blockchain, no one can change it; · Privacy is maintained and no personally identifiable information is involved.

[0049] In order for the present invention to work, the existing configuration and operation of the Bitcoin protocol and wallets must be acknowledged. Figure 1 shows how a standard Bitcoin transaction (TX) is constructed in accordance with one embodiment of the present invention. (Bitcoin is used for illustrative purposes only; other ledgers and associated protocols may be used and still fall within the scope of the present invention.)

[0050] <Agent configuration> One embodiment of the present invention involves the use of multiple independent (computational) agents configured to perform monitoring of the external environment to provide input to this logic gate transaction, as shown in Figure 2. Thus, the computational agents are designed to monitor some condition. The input may be received from a sensor for this purpose. For example, the agents may monitor a condition such as "Is the temperature below zero degrees Celsius?" or any other kind of testable condition. Thus, the agents may be configured to monitor the state of that observed condition.

[0051] The agents communicate with a controlling or master agent, hereafter referred to as the “controller.” The controller is configured to operate in conjunction with the blockchain protocol.

[0052] In one or more embodiments, subordinate agents (e.g., A and B) may have keys derived from the controller. However, it should be noted that it is possible for agents A and B to have their own generated keys and not derive keys from the controller. This limits the functionality that the controller can use with the keys.

[0053] In one or more embodiments, each condition being monitored has separate monitoring agents configured with their own key. From this key, they derive separate keys for the outputs from their monitored conditions (i.e., for each possible state). These values ​​can be deterministically derived from their base key. This can be done at the monitoring point, or the agents can pre-derive the values ​​(e.g., it may be more efficient for true / false sensors to simply be pre-defined). The keys may be derived from the base key using techniques described below in the section entitled "Generating Keys Using a Shared Secret."

[0054] <Agent behavior> The above described embodiments allow agents to have very tightly defined behaviors; at their basic point, they are sensors detecting a single condition and responding appropriately to that condition. The following table illustrates the behavior patterns of these agents: [Table 1]

[0055] Note that step 2 is the standard process for conducting a multi-signature transaction as known in the art. The novel steps are in steps 3 and 4, which allow the agent to embed the sensor values ​​into the signature returned by the agent.

[0056] <Data value extraction and transaction evaluation> The Redeem script in the transaction then allows efficient virtual extraction of the embedded value by the autonomous agent. However, this only works if the range of possible values ​​is known in advance. Here, an example is used in which agents A and B provide "true" / "false" values, but a wider range of values ​​can also be used with the method (e.g., 1, 2, 3, 4, 5). The key is that a unique key is used to represent each possible value or state, so that the Redeem script can determine based on what value the key was used to sign the Unlock script. However, the method does not support an infinite range of possible values, since logic provided in the Redeem script must be configured to perform this analysis.

[0057] The method works by evaluating the signature provided by the agent against its possible derived public keys, thus determining what the public keys for each possible input value (state) were when the Redeem Script was originally constructed by the control unit, and can include these in the payload of the Redeem Script.

[0058] The script does this by determining which of the public keys was used to sign the transaction in order to extract this data, and since the script is encoded to implicitly understand the value represented by the public key, the script efficiently extracts the value for use within the limited scope of the script.

[0059] Within the scope of the blockchain standard, the built-in OP_CHECKMULTISIG transaction function enables the evaluation of signatures to determine that sufficient signatures have been collected by the unlock script. However, this does not enable an explicit determination of which ones were used. Accordingly, the present invention provides a technique that uses a Tx to explicitly collate against specific keys to determine which ones were used, and thus enables implementing a great deal of complexity through the transaction, so the present invention provides an improvement over the prior art. In other words, by determining which subset of multiple keys is used in the signature process, it is possible to generate a more advanced operation through the blockchain.

[0060] For example, in the escrow function, it is possible to efficiently generate an escrow by a plurality of escrow agents, but define a script rule that requires the preparation of a signature by either the buyer and the seller, or one of the buyer and the escrow agent, or one of the buyer and the escrow agents. This is not possible with the known standard Bitcoin protocol since the standard configuration could allow both escrow agents to sign the transaction.

[0061] <Redeem Script Pseudocode> According to one embodiment of the present invention, the logic within the Redeem script may be configured as follows.

Number

[0062] <Exemplary Transaction> In the example transaction, transaction output (TxO) 1 implements a NOR gate with transaction output 2 to pay back the control unit. The transaction is shown in Figure 4.

[0063] <Redeemスクリプト> The complete Redeem script is shown below, which is then broken down into its logical components:

number

[0064] The boxed instruction code illustrates the NOR gate payload code (block 7 below) that sits above the signature manipulation logic required to put the data into a verifiable format.

[0065] In order to partition it into logical "sub-functions", the script is broken down for the reader's convenience into a sequence of blocks as shown in the table below. [Table 2-1] [Table 2-2]

[0066] <lock script> Locking scripts is a standard Pay-to-Script-Hash model. OP_HASH160<Redeem Script Hash> OP_EQUAL

[0067] <Unlock script> The required unlock script is: <sig-controller> <sig-a-used> <sig-b-used><RS Block 1> Where: <sig-a-used>is one of the following: <sig-a-true>or <sig-a-false> <sig-b-used>is one of the following: <sig-b-true>or <sig-b-false>

[0068] <Example: NOR logic gate> A NOR gate is a logic gate that implements NOT OR: if both inputs are false, the output is true, otherwise the output is false. [Table 3]

[0069] A NOR gate is implemented within a single Bitcoin transaction output that requires a control signature, as well as a signature from agent A representing either a true or false value, and another signature from agent B (also either true or false). Figure 1 gives an overview of how this NOR gate can be implemented by the Bitcoin protocol.

[0070] Alternative gates can be implemented by replacing the RB block 7 as shown in later sections.

[0071] <ANDゲート> [Table 4] [Table 5]

[0072] <NANDゲート> [Table 6] [Table 7]

[0073] <ORゲート> [Table 8] [Table 9]

[0074] <XORゲート> [Table 10] [Table 11]

[0075] <XNORゲート> [Table 12] [Table 13]

[0076] <NOTゲート> The implementation of this gate is slightly more complicated since it only has a single input. [Table 14]

[0077] As a result, the unlock script changes to:

number

[0078] A single input results in the following block modifications: [Table 15]

[0079] A number of different embodiments may be provided as described below.

[0080] <Variation 1: Generating true and false signals> This embodiment may essentially be the subject of the present invention. The above discussion allowed the unsigned transaction output (UTXO) representing a logic gate to be used only if the gate condition evaluated to true. However, in many situations it may be advantageous to use the output regardless of the actual output of the circuit (albeit with a different recipient address).

[0081] This is possible with this embodiment. Effectively, the embodiment shown in Figure 1 is modified as shown in Figure 3 to provide the invention claimed in this application. In this embodiment, there is an additional parameter provided to the Redeem script of the first transaction (Tx). This additional parameter can be a puzzle, or a value embedded in the key or explicitly provided (as in this example). This defines the desired output of the controller to use the UTXO.

[0082] Thus, with a simple logic gate, the controller may attempt to use a transaction twice with the same signature, once with a predicted true output and once with a predicted false output.

[0083] The Redeem script is extended to apply an equality check of the gate's output to the output requested by the control unit at the end of the gate computation. Thus:

[0084] If the embedded gate logic returns false, and the desired output is false, then the Redeem script evaluates to true and the UTXO can be spent; If the embedded gate logic returns true and the desired output is true, then the Redeem script evaluates to true and the UTXO can be spent; If the embedded gate logic returns true and the desired output is true, the Redeem script evaluates to false and the UTXO cannot be spent; If the embedded gate logic returns false and the desired output is true, the Redeem script will evaluate to false and the UTXO cannot be spent.

[0085] <Transformation script> The complete Redeem script is shown below. It is then broken down into its logical components for the reader's convenience. Additions from the initial solution are shown in reverse video (deletions are shown in strikethrough).

number

[0086] The instruction code in the box illustrates the NOR gate payload code that sits on top of the signature manipulation logic to put the data into a verifiable format.

[0087] <lock script> Locking scripts is a standard Pay-to-Script-Hash model. OP_HASH160<Redeem Script Hash> OP_EQUAL

[0088] <Unlock script> The unlock script for this pattern of logic gates is:

number

[0089] <Variation 2: Generation of hidden true and false signals> Variant 1 has the minor drawback that it is known (from the Redeem script) whether a true or false condition has been signaled from the script. Embedding the desired signal in the signature from the control avoids this problem. In variant 2, the control has two public keys derived from its own primary key as shown in Figure 5.

[0090] <Transformation script> The complete Redeem script is shown below. It is then broken down into its logical components. Additions from the initial solution are shown in reverse video (deletions are shown in strikethrough).

number

[0091] The instruction code in the box illustrates the NOR gate payload code that sits on top of the signature manipulation logic to put the data into a verifiable format.

[0092] <lock script> Locking scripts is a standard Pay-to-Script-Hash model. OP_HASH160<Redeem Script Hash> OP_EQUAL

[0093] <Unlock script> The unlock script for this pattern of logic gates is:

number

[0094] <Variant 3: Single Code Stack> These gates can be implemented using a single stack without using the old (alt) stack.

[0095] <Redeem Script: Overview and NOR> The complete Redeem script is shown below. This is then decomposed into logical components.

Number

[0096] The instruction code within the box exemplifies the NOR gate payload code on top of the signature operation logic to make the data in a verifiable format.

[0097] All stacks are shown in order from top to bottom.

[0098] <Lock Script> The lock script is a standard Pay-to-Script-Hash model. OP_HASH160 <Redeem Script Hash> OP_EQUAL

[0099] <Unlock Script> The unlock script for this pattern of logic gates is as follows (note the different order of the signature blocks): <sig-b-used> <sig-a-used> <sig-controller><RS Block 1> Where: <sig-a-used>teeth, <sig-a-true>or <sig-a-false>and <sig-b-used>teeth, <sig-b-true>or <sig-b-false>It is.

[0100] <Alternative gate> To implement the alternative logic gate, replace the explicit NOR code in the box with the following: [Table 16]

[0101] <Scenario: Burglar Alarm Setting (NOR Gate)> A simple example of the above embodiment utilizing a NOR gate is setting a burglar alarm.

[0102] In this example, Agent A is a door sensor at the service door that reports true when the door is open and false when the door is closed.

[0103] Agent B is also a door sensor, but in a safe inside the building. Agent B also communicates true when a door is open and false when a door is closed. The control unit is the central alarm system and will only set an alarm if all doors in the building are closed. The control unit therefore broadcasts a transaction to the various monitoring agents when they are asked to set an alarm. The transaction is only completed when Agent A and Agent B communicate that their respective doors are closed.

[0104] We describe below a technique for generating new keys from a base key, as described above.

[0105] <Generating a key using a shared secret> The following technique is described with reference to Figures 5-9.

[0106] Using the following techniques, keys may be securely kept or regenerated: In particular, in the case of a private key that can be used to derive a public key, the private key may be stored in fragmentation.

[0107] A user, say Alice or Bob, may hold one part of their private key, a service provider may hold a second part, and a third part may be held at a remote secure site. The private key may be reconstructed using any two of the three parts, or, more generally, the private key may be reconstructed using any m of the n parts.

[0108] If the private key is reconfigurable, it can be used to regenerate the public key at the point of use, and the private and public keys can again be discarded after use.

[0109] The separation of the private keys may be achieved using Shamir's Secret Sharing Scheme: a private-public key pair can be deterministically derived from a master key using the following method: This method allows secret values ​​to be shared by participants without transmitting them.

[0110] The system may generate participants' public keys using the subkey generation method described below.

[0111] 5 shows a system 1 including a first node 3 in communication with a second node 7 over a communications network 5. The first node 3 has an associated first processing device 23, and the second node 5 has an associated second processing device 27. The first and second nodes 3, 7 may include electronic devices such as computers, phones, tablet computers, mobile communications devices, computer servers, etc. In one example, the first node 3 may be a client (user) device and the second node 7 may be a server. The server may be a server of a digital wallet provider.

[0112] The first node 3 uses the first node master private key (V 1C ) and the first node master public key (P 1C ) The second node (7) is associated with a first asymmetric crypto pair having a second node master private key (V 1S ) and the second node master public key (P 1S ) In other words, the first and second nodes each possess an individual public-private key pair.

[0113] The first and second asymmetric cryptographic pairs of each first and second node 3, 7 may be generated during a registration process, such as registering a wallet. The public key of each node may be publicly shared across the communications network 5.

[0114] To determine a common secret (SC) in both the first node 3 and the second node 7, the nodes 3, 7 perform the steps of methods 300, 400 respectively, without communicating a secret key over the communications network 5.

[0115] The method 300 performed by the first node 3 includes obtaining at least the first node master private key (V 1C ) and the Generator Value (GV), the first node 2nd private key (V 2C The method 300 includes determining 330 a generator value (M) based on a message (M) shared between the first node and the second node, which may include sharing the message over the communication network 5, as described in more detail below. The method 300 includes determining 330 a generator value (M) based on a message (M) shared between the first node and the second node, which may include sharing the message over the communication network 5, as described in more detail below. 1S ) and the Generator Value (GV), the second node 2S The method 300 further includes determining 370 the first node second private key (V 2C ) and the second node second public key (P 2S ) to determine 380 a common secret (CS).

[0116] Importantly, the same common secret (CS) can also be determined at the second node 7 by the method 400. The method 400 determines the first node master public key (P 1C ) and the Generator Value (GV), the first node derives a second public key (P 2C ). The method 400 includes a step 430 of determining the second node master private key (V 1S ) and the Generator Value (GV), the second node 2S The method 400 further includes determining 470 a second node second private key (V 2S ) and the first node second public key (P 2C ) to determine a common secret (CS).

[0117] The communications network 5 may include a local area network, a wide area network, a cellular network, a wireless communications network, the Internet, etc. In these networks, data may be transmitted over communications media such as electrical wires, optical fibers, or radio waves and may be susceptible to eavesdropping, such as by an eavesdropper 11. The methods 300, 400 enable the first node 3 and the second node 7 to both independently determine the common secret without transmitting the common secret over the communications network 5.

[0118] Thus, one advantage is that the common secret (CS) can be determined securely and independently by each node, without the need to transmit the private key over a potentially insecure communications network 5. The common secret may also be used as (or as the basis for) the private key.

[0119] The method 300, 400 may include an additional step. The method 300 comprises: 2C ) to generate a signed message (SM1). The method 300 may further include a step 360 of transmitting the first signed message (SM1) to the second node 7 via the communication network. Meanwhile, the second node 7 may perform a step 440 of receiving the first signed message (SM1). The method 400 may further include a step 440 of transmitting the first signed message (SM2) to the second node 7 via the communication network. 2C ) and a step 460 of authenticating the first node 3 based on the result of the step of verifying the first signed message (SM1). Advantageously, this enables the second node 7 to authenticate that the intended first node (where the first signed message was generated) is the first node 3. This is because only the first node 3 knows the first node master private key (V 1C ), therefore, only the first node 3 has access to the first node second private key (V 2C ) can be determined. It should be appreciated that similarly, a second signed message (SM2) can be generated at the second node 7 and sent to the first node 3. Thus, as in a peer-to-peer scenario, the first node 3 can authenticate the second node 7.

[0120] The sharing of a message (M) between the first node and the second node may be accomplished in various ways. In one example, a message may be generated at the first node 3 and then transmitted to the second node 7 over the communication network 5. Alternatively, a message may be generated at the second node 7 and then transmitted to the first node 3 over the communication network 5. In some examples, the message (M) may be public and therefore transmitted over the insecure network 5. One or more messages (M) may be stored in a data store 13, 17, 19. One skilled in the art will appreciate that the sharing of a message may be accomplished in various ways.

[0121] Advantageously, a record that allows recreation of the common secret (CS) can be kept without the record itself having to be stored in secret or transmitted securely.

[0122] <How to register 100, 200> An example of a method 100, 200 of registration is described below, where method 100 is performed by a first node 3 and method 200 is performed by a second node 7. It includes the steps of establishing first and second asymmetric cryptographic pairs for the first node 3 and the second node 7, respectively. The asymmetric cryptographic pair includes an associated private key and a public key, such as used in public key cryptography. In this example, the asymmetric cryptographic pair is generated using properties of Elliptic Curve Cryptography (ECC) and elliptic curve arithmetic.

[0123] In the methods 100, 200, this involves a first node and a second node agreeing 110, 210 on a common ECC system and using a base point (G) (Note: the base point may be referred to as a common generator, but the term "base point" is used to avoid confusion with the generator value GV). In one example, the common ECC system may be based on secp256K1, which is the ECC system used by Bitcoin. The base point (G) may be selected, randomly generated, or assigned.

[0124] Considering now the first node 3, the method 100 includes resolving 110 the common ECC system and base point (G). This may include receiving the common ECC system and base point from the second node 7 or the third node 9. Alternatively, a user interface 15 is associated with the first node 3, which allows a user to selectively provide the common ECC system and / or base point (G). In yet another alternative, one or both of the common ECC system and / or base point (G) may be randomly selected by the first node 3. The first node 3 may send a notification to the second node 7 over the communication network 5 indicating the use of the common ECC system with the base point (G), which may then resolve 210 by sending a notification indicating an acknowledgment to the use of the common ECC system and base point (G).

[0125] The method 100 includes a step of: 1C ) and the first node master public key (P 1C ), based at least in part on random integers within a specified range of tolerances in the common ECC system, 1C ), which generates the first node master private key (V 1C ) and the base point (G) based on the elliptic curve point multiplication, the first node master public key (P 1C ) P 1C =V 1C ×G (Formula 1)

[0126] Thus, the first asymmetric crypto-pair comprises: V 1C : The first node master private key, which is kept secret by the first node. P 1C : The first node master public key that will be made public.

[0127] The first node 3 uses the first node master private key (V 1C ) and the first node master public key (P 1C ) may be stored in a first data store 13 associated with the first node 3. For security purposes, the first node master private key (V 1C ) may be stored in a secure part of the first data store 13 to ensure that the key remains secret.

[0128] The method 100 includes, as shown in FIG. 6, generating a first node master public key (P 1C ) to the second node 7 via the communication network 5. The second node 7 transmits the first node master public key (P 1C ) is received 220, the first node master public key (P 1C ) may be stored 230 in a second data store 17 associated with the second node 7.

[0129] Similar to the first node 3, the method 200 of the second node 7 includes the step of determining the second node master private key (V 1S ) and the second node master public key (P 1S ) and generating 240 a second asymmetric cryptopair having a second node master private key (V 1S ) is also a random integer within the allowed range. The second node master public key (P 1S ) is determined by the following formula: P 1S =V 1S ×G (Formula 2)

[0130] Thus, the second asymmetric crypto-pair comprises: V 1S : The second node master private key, which is kept secret by the second node. P 1S : The second node master public key, which will be made publicly available.

[0131] The second node 7 may store the second asymmetric cryptographic pair in the second data store 17. The method 200 may further include storing the second node master public key (P 1S ) to the first node 3. The first node 3 also transmits the second node master public key (P 1S ) Receive 140, store 150.

[0132] It should be appreciated that in some alternatives, each public master key may be received and stored in a third data store 19 associated with a third node 9 (such as a trusted third party). This may include a third party acting as a public directory, such as a certification authority. Thus, in some examples, the first node master public key (P 1C ) may be requested and received by the second node 7 only when a common secret (CS) is requested, and vice versa.

[0133] The registration step only needs to occur once as an initial setup.

[0134] <Session start and determination of shared secret by first node 3> An example of determining the common secret (CS) is described below. The common secret (CS) may be used for a particular session, time, transaction, or other purpose between the first node 3 and the second node 7, and it may not be desirable or secure to use the same common secret (CS). Thus, the common secret (CS) may be changed between different sessions, times, transactions, etc.

[0135] The following is provided for illustration of the above mentioned secure transmission techniques.

[0136] [Generate message (M) 310] In this example, the method 300 performed by the first node 3 includes a step 310 of generating a message (M). The message (M) may be random, pseudorandom, or user defined. In one example, the message (M) is based on Unix time or a nonce (as well as any value). For example, the message (M) may be given as: Message (M) = Unix time + nonce (Equation 3)

[0137] In some examples, the message (M) is arbitrary. However, it should be understood that the message (M) may have optional values ​​(such as Unix time, etc.) that may be useful in some applications.

[0138] The method 300 includes a step 315 of sending the message (M) to the second node 7 via the communication network 3. Since the message (M) does not contain information about the private key, the message (M) may be sent over an insecure network.

[0139] [320 Determine Generator Value (GV)] The method 300 further includes determining 320 a Generator Value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. An example of a cryptographic hash algorithm includes SHA-256 to generate a 256-bit Generator Value (GV), i.e. GV = SHA-256(M) (Equation 4)

[0140] It should be understood that other hash algorithms may be used. This may include other hash algorithms in the Secure Hash Algorithm (SHA) family. Some specific examples include instances in the SHA-3 subset, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256. Other hash algorithms may include algorithms in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A specific example may include RIPEMD-160. Other hash functions may include families based on the Zemor-Tillich hash function and the Knapsack hash function.

[0141] [First node determines second private key 330] The method 300 then determines the second node master private key (V 1C ) and the generator value (GV), the first node second private key (V 2C This involves determining 330 the first node master private key (V 1C ) and a generator value (GV). V 2C =V 1C +GV (Equation 5)

[0142] Therefore, the first node's second private key (V 2C ) is not a random value, but is instead deterministically derived from the first node master private key. The corresponding public key in the cryptographic pair, i.e., the first node second public key (P 2C ) have the following relationship: P 2C =V 2C ×G (Equation 6.1)

[0143] From equation 5 to equation 6, V 2C Substituting, we get the following equation: P 2C =(V 1C +GV)×G (Formula 7)

[0144] Here, the “+” operator represents elliptic curve point addition. Elliptic curve cryptography algebra is distributive, and Equation 7 can be expressed as follows: P 2C =V 1C ×G+GV×G (Formula 8)

[0145] Finally, (Equation 1) is substituted into (Equation 7) to obtain the following equation: P 2C =P 1C +GV×G (Formula 9.1) P 2C =P 1C +SHA-256(M)×G (Equation 9.2)

[0146] Therefore, the corresponding first node second public key (P 2C ) is the first node master public key (P 1C ) and derivable given knowledge of the message (M). As described in more detail below with respect to method 400, the second node 7 may receive the first node second public key (P 2C With such knowledge, it is possible to independently determine

[0147] [Generate 350 a first signed message (SM1) based on the message and the first node's second private key] The method 300 includes receiving a message (M) and a determined first node second private key (V 2C ) to generate 350 a first signed message (SM1). The step of generating a signed message includes applying a digital signature algorithm to digitally sign the message (M). In one example, this includes applying a first node second private key (V) to the message in an Elliptic Curve Digital Signature Algorithm (ECDSA) to obtain the first signed message (SM1). 2C Examples of ECDSA include those based on ECC systems having secp256k1, secp256r1, secp384r1, se3cp521r1.

[0148] The first signed message (SM1) is sent to the second node 7 using the corresponding first node second public key (P 2C ) This verification of the first signed message (SM1) may be used by the second node 7 to authenticate the first node 3, which is discussed below in method 400.

[0149] [Second node determines second public key 370'] The first node 3 then transmits the second node second public key (P 2S ) may be determined 370. As described above, the second node second public key (P 2S ) contains at least the second node master public key (P 1S ) and a generator value (GV). In this example, the public key is determined as a private key by elliptic curve point multiplication with the base point (G) 370, so that the second node's second public key (P 2S ) can be expressed similarly to Equation 6 as follows: P 2S =V 2S ×G (Equation 10.1) P 2S =P 1S +GV×G (Equation 10.2)

[0150] The mathematical proof of Equation 10.2 is as follows: 2C ) is the same as that described above to derive equation 9.1 for . It should be understood that the first node 3 can determine 370 the second node second public key independently of the second node 7.

[0151] [380 Determine the common secret at the first node 3] The first node 3 then transmits the first node second private key (V 2C ) and the second node second public key (P 2S ) a common secret (CS) may be determined 380 by the first node 3 according to the following formula: S=V 2C ×P 2S (Formula 11)

[0152] <Method 400 performed in second node 7> A corresponding method 400 performed in the second node 7 will now be described. It should be understood that some of these steps are similar to the steps performed by the first node 3 described above.

[0153] The method 400 includes a step 410 of receiving a message (M) from the first node 3 via the communications network 5. This may include the message (M) sent by the first node 3 in step 315. The second node 7 then determines 420 a generator value (GV) based on the message (M). The step 420 of determining a generator value (GV) by the second node 7 is similar to the step 320 performed by the first node 3 described above. In this example, the second node 7 performs this determining step 420 independent of the first node 3.

[0154] The next step is to generate the first node master public key (P 1C ) and the generator value (GV), the first node second public key (P 2C In this example, the public key is determined as a private key by elliptic curve point multiplication with the base point (G) 430′, so that the first node second public key (P 2C ) can be expressed similarly to Equation 9 as follows: P 2C =V 2C ×G (Equation 12.1) P 2C =P 1C +GV×G (Equation 12.2)

[0155] The mathematical proofs of Equations 12.1 and 12.2 are the same as those given above for Equations 10.1 and 10.2.

[0156] [Second node 7 authenticates first node 3] The method 400 may include steps performed by the second node 7 to authenticate the unconfirmed first node 3 as the first node 3. As mentioned above, this includes step 440 of receiving the first signed message (SM1) from the first node 3. The second node 7 then receives the first node second public key (P 2C ) may verify 450 the signature of the first signed message (SM1).

[0157] The verification of the digital signature may be performed according to the Elliptic Curve Digital Signature Algorithm (ECDSA) described above. Importantly, the first node's second private key (V 2C The first signed message (SM1) signed by V 2C and P 2C form a cryptographic pair, the corresponding first node second public key (P 2C ) should be correctly verified. These keys are generated by the first node master private key (V 1C ) and the first node master public key (P 1C ), verification of the first signed message (SM1) can be used as a basis for authenticating that the unconfirmed first node sending the first signed message (SM1) is the same first node 3 being registered. Therefore, the second node 7 may further perform a step (460) of authenticating the first node 3 based on the result of the step of verifying the first signed message (450).

[0158] [Second node 7 determines the shared secret] The method 400 includes a step of: 1S ) and the generator value (GV), the second node second private key (V 2S ) in a manner similar to step 330 performed by the first node 3. 2S ) is calculated by the following formula: 1S ) and a generator value (GV). V 2S =V 1S +GV (Equation 13.1) V 2S =V 1S +SHA-256(M) (Formula 13.2)

[0159] The second node 7 then derives the second node second private key (V 2S ) and the first node second public key (P 2C ) based on which a common secret (CS) may be determined480. S=V 2S ×P 2C (Formula 14)

[0160] [Certification of the common secret (CS) determined by the first node 3 and the second node 7] The common secret (CS) determined by the first node 3 is the same as the common secret (CS) determined at the second node 7. A mathematical proof that Equation 11 and Equation 14 provide the same common secret (CS) is now described.

[0161] Given the common secret (CS) determined by the first node 3, Equation 10.1 can be substituted into Equation 11 as follows: S=V 2C ×P 2S (Formula 11) S=V 2C ×(V 2S ×G) S=(V 2C ×V 2S )×G (Equation 15)

[0162] Given the common secret (CS) determined by the second node 7, Equation 12.1 can be substituted into Equation 14 as follows: S=V 2S ×P 2C (Formula 14) S=V 2S ×(V 2C ×G) S=(V 2S ×V 2C )×G (Equation 16)

[0163] Since ECC algebra is commutative, Equation 15 and Equation 16 are equivalent: S=(V 2C ×V 2S )×G=(V 2S ×V 2C )×G (Equation 17)

[0164] [Common Secret (CS) and Private Key] The common secret (CS) can now be used as a private key or as the basis for a private key in a symmetric key algorithm for secure communication between the first node 3 and the second node 7 .

[0165] The shared secret (CS) is the elliptic curve point (x S ,y S ), which may be converted to a standard key format using a standard publicly known operation agreed upon by nodes 3 and 7. For example, x S The value is AES 256 It may be a 256-bit integer that can be used as a cryptographic key, which can be further converted to a 160-bit integer using RIPEMD160 for any application that requires a 160-bit key length.

[0166] The common secret (CS) may be determined as needed. Importantly, the first node 3 does not need to store the common secret (CS) since it can be re-determined based on the message (M). In some examples, the message (M) used may be stored in a data store 13, 17, 19 (or other data store) that does not have the same level of security as required for a master private key. In some examples, the message (M) may be publicly available.

[0167] However, depending on some applications, the shared secret (CS) may be the first node master private key (V 1C ), the common secret (CS) may be stored in a first data store (X) associated with the first node.

[0168] Advantageously, this technique can be used to determine multiple common secrets, which may correspond to multiple secure private keys, based on a single master key crypto-pair.

[0169] It should be noted that the above-described embodiments do not limit the present invention, and that those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claims. The word "comprising" or "comprises" and the like does not exclude the presence of elements or steps other than those listed in any claim and the specification as a whole. In this specification, "comprises" means "includes" or "consists of", and "comprising" means "including" or "including of". The singular reference of an element does not exclude the presence of a plurality of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, or by means of a suitably programmed computer. In a device claim enumerating several means, these several means may be implemented by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage. [Explanation of symbols]

[0170] 3 First Node 5. Network 7 Second Node CS Common Secret P 1C First node master public key P 1S Second node master public key P 2C 1st node 2nd public key P 2S Second node second public key V 1C First node master private key V 1S Second node master private key V 2C 1st node 2nd private key V 2S Second node second private key < / sig-a-used> < / sig-b-used> < / sig-a-false> < / sig-a-used> < / sig-controller>

Claims

1. 1. A computer-implemented control method, comprising: providing a blockchain transaction for a blockchain network, the blockchain transaction including a redeem script for an output, the redeem script comprising: i) a plurality of public keys, each associated with a corresponding private key, each public key being uniquely associated with a possible state of at least one data source, the at least one data source including a sensor or signal generating component associated with a plurality of computing agents directly controlled by the blockchain, each of the computing agents comprising: monitoring individual possible states of the at least one data source via the sensor or signal generating component to provide an input indicative of a state of the at least one data source; Derive a separate private key for each possible state; a plurality of public keys, wherein in order to spend the output, a minimum number of the private keys must be used to sign an unlock script of a further blockchain transaction; and ii) logic comprising: determining which of the private keys will be used to sign the unlock script to provide an intermediate result; and comparing parameters provided by the unlock script to the intermediate results; and logic configured to provide a result based on the and attempting to spend the output of the blockchain transaction more than once, each attempt providing different parameters; The method includes:

2. The method of claim 1 , wherein the logic is configured to implement a function of a logic gate.

3. 3. The method of claim 2, wherein the logic gate is a NOT, AND, OR, NOR, XOR, IMPLY, NAND, NONIMPLY, or XNOR gate.

4. The method according to any of claims 1 to 3, wherein the state of said at least one data source is determined by said computing agent.

5. The method of claim 4 , wherein the computing agent is in communication with a control computing agent.

6. The method according to any of claims 1 to 5, wherein the result is a Boolean result.

7. The method according to any one of claims 1 to 6, wherein there are at least two data sources.

8. A method according to any preceding claim, wherein for each data source there are two possible states, each possible state being associated with or represented by a public key.

9. For each of the at least one data source, associating a public key of the plurality of public keys with a possible state of the data source; A method according to any preceding claim, wherein all possible states of said data sources are represented by respective public keys.

10. The method according to any of claims 1 to 9, wherein each public key represents a Boolean value indicating a possible state of said at least one data source.

11. The method according to any of claims 1 to 10, wherein the parameter is a value, or a puzzle, or a value embedded in the public key.

12. The method according to any of the preceding claims, wherein the logic is configured to perform an equality check to compare the intermediate result with the parameter.

13. The method of any of claims 1 to 12, wherein the intermediate result is a Boolean value derived from the logic provided in the Redeem Script and / or calculated by determining which key was used to sign the Unlock Script.

14. 14. The method of any of claims 1 to 13, further comprising generating or deriving one or more of the plurality of public keys and / or a private key corresponding to each one or more of the plurality of public keys from a base or master key.

15. 15. The method of claim 14, wherein generating or deriving one or more of the plurality of public keys and / or a private key corresponding to each one or more of the plurality of public keys is performed using deterministic key generation techniques.

16. 1. A computer-implemented system comprising: At least one computer-based resource configured to execute the method according to any one of claims 1 to 15; Blockchain and A system including:

17. The at least one computer-based resource includes: Submit a transaction to the blockchain network, Generate a transaction, Digitally sign the lock script, and / or generating one or more of the plurality of public keys and / or a private key corresponding to each of the one or more of the plurality of public keys; 20. The computer-implemented system of claim 16, configured to:

18. 18. A system according to claim 16 or 17, wherein the results are used to control or influence the performance or operation of a process or equipment.

19. The system of any of claims 16 to 18, further comprising at least one sensor or signal generating component arranged and configured to provide input to said at least one computer-based resource.

Images