Elliptic curve arithmetic in scripts

Abstract

A computer-implemented method may perform elliptic curve operations performed with blockchain transactions. A first script is generated that includes a modular inversion script. The modular inversion script is configured to obtain a target integer x, a modulus value p, and a pair of indices of an element of an additive chain that identifies a pair of preceding elements that, when summed, equals the element of the additive chain. The modular inverse is generated by exponentiating x to a reduced modulus (p-2) using the additive chain. For each element of the additive chain for 3≦i≦l, each of the multiplier values ​​is calculated by selecting a multiplier value associated with the pair of indices and multiplying by the selected multiplier value to generate a respective multiplier value for the element. If i=l, a remainder of the multiplier value is calculated for the modulus value.

Description

[Technical field]

[0001] The present disclosure relates to a computer-implemented method for enabling elliptic curve arithmetic to be performed within a script using blockchain transactions. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly published at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, with each block including one or more transactions. Each transaction points backwards to the preceding transaction in the sequence, with the exception of so-called "coinbase transactions," which are further described below, and the sequence may span one or more blocks back to one or more coinbase transactions. Transactions submitted to the blockchain network are included in new blocks. New blocks are generated by a process often called "mining," which involves each of multiple competing nodes performing a "proof-of-work," i.e., solving a cryptographic puzzle based on a representation of a given set of ordered and verified pending transactions that are waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned by some nodes and publication of a block can be achieved by simply publishing the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to carry digital assets (i.e., any digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically process index pointers. A blockchain may also be used to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow indexing of data or storing additional user data in a transaction. There is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, and therefore more and more complex data can be incorporated. For example, this may be used to store electronic documents on a blockchain, or audio or video data.

[0004] Nodes in a blockchain network (often called “miners”) perform a distributed transaction registration and validation process, which is described further below. Briefly, during this process, nodes validate transactions and insert them into a block template for which they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, and each node can record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network, where it should be propagated. Nodes that receive a transaction can compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to enforce the same node protocol, which may include one or more conditions for a transaction to be valid. Invalid transactions are not propagated to or included in a block. Assuming the transaction is verified and thereby accepted into the blockchain, the transaction (including any user data) will remain registered and indexed as an immutable public record at each node in the blockchain network.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is regulated by the actions of competing nodes that act as agents of the network and are incentivized to report and block misconduct. Wide publication of information allows users to continuously audit node performance. Publication of simple block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In the “output-based” model (often called the UTXO-based model), the data structure of a given transaction contains one or more inputs and one or more outputs. Any usable output contains an element that specifies a quantity of a digital asset that can be derived from the transaction’s processing sequence. A usable output is sometimes referred to as a UTXO (for “unspent transaction output”). An output may further contain a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) contains a pointer (i.e., a reference) to such an output in a preceding transaction, and may further contain an unlocking script to unlock the locking script of the pointed-to output. We now consider a pair of transactions, which we will call the first and second transactions (or “target” transactions). The first transaction includes at least one output specifying a quantity of the digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input including a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network and propagated and recorded in the blockchain, one of the validity conditions applied by each node would be that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction. Another would be that the output of the first transaction has not already been redeemed by another preceding valid transaction. Any node that finds that the target transaction is invalid due to any of these conditions will not propagate it (not propagate it as a valid transaction, possibly registering an invalid transaction) and will not include it in the new block recorded in the blockchain.

[0008] Another type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of a transaction that precedes it in the sequence of past transactions, but rather by referencing absolute account balances. The current state of every account is stored and constantly updated by nodes individually to the blockchain. Summary of the Invention

[0009] Blockchain transactions contain scripts, called unlocking scripts and locking scripts. These scripts allow data (e.g., a public key) and functions (e.g., an opcode) to be recorded on the chain, and the functions act on the data when the script is executed, e.g., during transaction validation. For example, a function can be used to hash a public key to generate a public key hash.

[0010] Elliptic curves are used in many applications, for example elliptic curve cryptography (ECC), elliptic curve digital signature algorithms (ECDSA), elliptic curve Diffie-Hellman key exchanges, etc. Some of these applications, like ECDSA, are fundamentally linked to some blockchain protocol. For example, most blockchain protocols sign transactions using ECDSA signatures, which rely on private-public key pairs generated using elliptic curve points.

[0011] Elliptic curve arithmetic is the performance of certain mathematical operations on elliptic curve points, such as adding two elliptic curve points or multiplying an elliptic curve point by a scalar. A fundamental requirement of elliptic curve arithmetic is the ability to compute the modular inverse of an elliptic curve point, or more generally, the modular inverse of an integer, such as the x-coordinate of an elliptic curve point. It is recognized in this case that it would be advantageous to be able to perform elliptic curve arithmetic within a script. Hence, it is necessary to be able to compute the modular inverse of an integer within a script.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for enabling elliptic curve operations to be performed using blockchain transactions, the method being performed by a script generator, the method comprising: generating a first script for a first blockchain transaction; outputting a first script for inclusion in a first blockchain transaction; The first script includes a modular inversion script that, when executed by the script engine, obtaining a target integer (x) and a modulus value (p), where the target integer and the modulus value are mutually prime and the modulus value is a prime number; The components (a i ) index pair (s i ,t i ), the reduced modulus value having a value two less than the modulus value, and the index being a pair of preceding components of the additive chain which, when summed, results in a component (a i ), the additive chain has length l; and obtaining a modular inverse (y) of a target integer, the modular inverse being generated by exponentiating x to a reduced modulus (p-2) using additive chaining by computing a sequence of l multiplier values ​​and computing the remainder of the multiplier values ​​relative to the modulus value (p) when i=l; wherein a first multiplier value in the sequence of multiplier values ​​is equal to a target integer and a second multiplier value in the sequence of multiplier values ​​is calculated, and for each component of the additive chain for 3≦i≦l, a respective multiplier value in the sequence of multiplier values ​​is iteratively calculated, each respective multiplier value being a target integer (x) raised to the power of a component of the additive chain, and each respective multiplier value being: selecting from the stack a multiplier value associated with a preceding pair of components in an additive chain; multiplying the selected multiplier value by the selected multiplier value to generate a multiplier value for each of the components; and pushing the generated multiplier value onto the stack; The remainder of the multiplier value to the modulus value (p) is output as the modular inverse (y).

[0013] The script generator generates a first script (e.g., a locking script) for a second transaction. The script calculates the modular inverse of a target integer (x) with a modulus value (n), i.e. x -1 The modular inversion script contains at least one modular inversion script that is configured to find p mod n. If the modulus is prime (n=p), then the modular inverse of the target integer is x p-2 The modulus value can be written as p mod p. The exponentiation of an integer x up to a reduced modulus value (p-2) can be represented by an addition chain of length l, where the two preceding elements (to the current element) of the addition chain are added together to produce the current element of the addition chain. The modular inverse is calculated by computing all elements of the addition chain and finding the remainder of the final element of the addition chain with respect to the modulus value (p). The target integer and modulus value may be included as part of the first script (e.g., a locking script) or may be provided as input by a different script (e.g., an unlocking script for the second transaction). The first transaction is recorded in the blockchain. When the first script is executed (e.g., during validation of the transaction), the modular inverse of the target integer is calculated and output (e.g., to a memory such as a stack). The present disclosure improves the functionality of blockchains by allowing modular inverses of integers to be performed within a script.

[0014] An integer modular inverse may be used as part of one or more additive arithmetic operations. For example, a modular inversion script may be included as part of (or output data from) a point addition script configured to add two elliptic curve points. As another example, a modular inversion script may be used as part of a scalar multiplication script configured to multiply an elliptic curve point by a scalar.

[0015] One advantage of performing elliptic curve operations in scripts is that the calculations are immutably stored on-chain, meaning that the calculations and results cannot be changed and can be verified in the future. Another advantage is that the calculations, which are expensive in terms of processing power, are performed by the script engine that executes the script, not by the script generator. Script engines are typically implemented by entities (e.g., blockchain nodes) that have more computing resources than the script engine (e.g., users).

[0016] The first script is written in a scripting language. For example, certain blockchain protocols use a particular language called 'Script' (capital S), which is a stack-based scripting language that consists of predefined functions called opcodes. In such languages, a given opcode maps to one or more of the following operations: (a) putting an element on a stack, (b) taking an element from a stack, (c) manipulating an element on the stack, and (d) removing an element from a stack. Some stack-based languages ​​are capable of storing data in two stacks, e.g., a main stack and an alternate (alt) stack. The embodiments of the present disclosure maintain the security of the blockchain by enabling elliptic curve operations to be performed using the blockchain's existing Script language, thus avoiding the introduction of new opcodes that may increase the attack surface for attackers. [Brief description of the drawings]

[0017] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2]Figure 2 shows a schematic of some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 3 is a schematic block diagram of certain node software for processing transactions. [Figure 4] FIG. 4 is a schematic block diagram of an exemplary system for generating and executing scripts. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] 1. Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0019] Each blockchain node 104 includes a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application specific processors, and / or other devices, such as field programmable gate arrays (FPGAs), and application specific integrated circuits (ASICs). Each node also includes a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media, such as hard disks; electronic media, such as solid state drives (SSDs), flash memory, or EEPROMs; and / or optical media, such as optical disk drives.

[0020] The blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Rather, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where transaction in this context refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain will use one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing some amount of digital assets as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring the user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backwards to an output of a preceding transaction 152, thereby tying the transactions together.

[0021] Each block 151 also contains a block pointer 155 that points back to an earlier block 151 in the chain to define the sequential order leading to block 151. Each transaction 152 (other than coinbase transactions) contains a pointer back to the previous transaction to define the order for the sequence of transactions (sequences of NB transactions 152 are allowed to branch). The chain of blocks 151 all lead back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, rather than to a preceding transaction.

[0022] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to generate blocks 151 and store a respective copy of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term in this case is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0023] For a given current transaction 152j, its (or each) input contains a pointer that references an output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily mean the transfer of a financial asset, although that is certainly one common application. More generally, consumption can be described as consuming an output or allocating it to one or more outputs of another subsequent transaction. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily need to exist at the time the current transaction 152j is created or even sent to the network 106, but a preceding transaction 152i does need to exist and be verified in order for the current transaction to be valid. Thus, in this context, "preceding" refers to preceding in the logical order linked by pointers, and not necessarily to time of creation or transmission in the chronological order, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see discussion below regarding orphan transactions). A preceding transaction 152i may similarly be referred to as a preceding transaction or a preceding transaction.

[0024] The input of the current transaction 152j also includes an input authorisation, e.g. the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amount between multiple users or entities (one of which may be the original user or entity 103a to provide the change). In some cases, a transaction may have multiple inputs, collecting amounts from multiple outputs of one or more previous transactions and distributing them back to one or more outputs of the current transaction.

[0025] According to an output-based transaction protocol such as Bitcoin, when an entity 103, such as an individual user or an organization, wants to enact a new transaction 152j (either manually or by an automated process used by it), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient will eventually send this transaction to one or more blockchain nodes 104 of the network 106 (today usually a server or a data center, but in principle it could be other user terminals). It is also possible that the entity 103 enacting a new transaction 152j sends the transaction directly to one or more blockchain nodes 104, and in some cases not to a recipient, which is not excluded. The blockchain nodes 104 receiving the transaction check if the transaction is valid according to the blockchain node protocol applied to each blockchain node 104. A blockchain node protocol typically requires a blockchain node 104 to check that a cryptographic signature in a new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, it may include checking that a cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition set in the output of the previous transaction 152i to which the new transaction specifies, which typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked.This condition may be defined, at least in part, by a script included in the output of the preceding transaction 152i. Alternatively, it may simply be fixed in the blockchain node protocol, or it may be a combination of both. In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and thus forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0026] In the output-based model, the definition of whether a given output (e.g., UTXO) is designated (e.g., spent) is whether it is validly redeemed by the input of another forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the forward transaction 152i attempting to redeem has not already been redeemed by another transaction. Also, if it is not valid, the transaction 152j will not be propagated (unless it is flagged as invalid and propagated for a warning) and will not be recorded in the blockchain 150. This prevents double spending, where an entity tries to designate the same transaction output multiple times. On the other hand, the account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any point in time.

[0027] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves finding a "nonce" value, whereby the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, such that the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output for its input, so this search can only be performed by brute force and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0028] The first blockchain node 104 that solves the puzzle announces it to the network 106 and provides its solution as a proof, so that the proof can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that it matches the output of the hash). The first blockchain node 104 propagates the block for threshold consensus of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, pointing back to the previously generated block 151n-1 in the chain. The significant effort required to create the proof-of-work solution, for example in the form of a hash, triggers the first node 104 to intend to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it allocates the same output as a previously validated transaction or is otherwise understood as a double spend. Once created, a block 151 cannot be modified because it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. The block pointers 155 also impose a sequential order on the blocks 151. Transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, thus providing an immutable public ledger of transactions.

[0029] Note that the various blockchain nodes 104 competing to solve the puzzle at any given time can do so based on various snapshots of the pool of transactions 154 to be published at any given time, depending on when they started searching for a solution, or depending on the order in which the transactions were received. Whoever solves each puzzle first determines which transactions 152 will be included in the next new block 151n, and in what order, the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to generate blocks from the newly determined ordered pool of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve their puzzles in a very short time, one after the other, resulting in inconsistent views of the blockchain propagating between the nodes 104. In essence, whichever prong of the fork extends the longest, will be the final blockchain 150. Note that this should not impact users or agents of the network, as the same transactions will appear in both forks.

[0030] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional accepted amount of the digital asset in a new special type of transaction that distributes an additional defined amount of the digital asset (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is usually called a “coinbase transaction”, but may also be called an “initiation transaction” or a “generation transaction”. It typically forms the first transaction of a new block 151n. The proof of work triggers the node to construct a new block and to intend that this special transaction will be redeemed later according to the protocol rules. The blockchain protocol rules may require a maturation period of, for example, 100 blocks before this special transaction can be redeemed. Often, a normal (non-generation) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0031] Due to the resources involved in validating and publishing transactions, typically each of the blockchain nodes 104 takes the form of at least one server, including one or more physical server units, or even an entire data center, although in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0032] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform a respective role or roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any operation attributed to a blockchain node 104 in this case may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications, at the application layer, at a lower layer such as the operating system layer, the protocol layer, or any combination thereof.

[0033] Also connected to the network 101 are computing devices 102 of a number of entities 103 that act as consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some entities may act as storage entities that store a copy of the blockchain 150 (e.g., obtain a copy of the blockchain from a blockchain node 104).

[0034] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 since they do not perform the roles required of blockchain nodes. Rather, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting (i.e., communicating) with a blockchain node 104. Two parties 103 and their respective devices 102 are shown for illustrative purposes; a first party 103a and his / her respective computing device 102a, and a second party 103b and his / her respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 may be present and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0035] The computing device 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing device 102 of each party 103 further comprises memory, i.e., computer readable storage in the form of a non-transitory computer readable medium or media. The memory may comprise one or more memory units using one or more memory media, e.g., magnetic media such as hard disks; electronic media such as SSDs, flash memory, or EEPROMs; and / or optical media such as optical disk drives. The memory in the computing device 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any operation attributable to a given party 103 in this case may be performed using software executing on the processing device of the respective computing device 102. The computing device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

[0036] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on a suitable computer readable storage medium or media, for example downloaded from a server or provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0037] The client application 105 includes at least a "wallet" functionality, which has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104 for propagation throughout the network of blockchain nodes 104 and thus inclusion in the blockchain 150. The other is to report to each party the amount of digital assets he or she currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0038] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily a limitation; rather, any client function described herein may be implemented in a suite of two or more separate applications, for example, by interfacing via an API or by one being a plug-in to the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. While the following is described with respect to client application 105, it will be understood that this is not a limitation.

[0039] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the individual party 103 of the transaction is the recipient (or, indeed, can inspect the transactions of other parties in the blockchain 150, since in embodiments, the blockchain 150 is a public facility that provides credibility to transactions in part through public visibility). The wallet functionality on each computing device 102 is configured to form and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to validate transactions 152 according to the blockchain node protocol and to forward the transactions 152 to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0040] When a given party 103, say Alice, wants to send a new transaction 152j to be included in the blockchain 150, she forms the new transaction (using the wallet functionality in her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j satisfies certain conditions to be "valid", examples of which will be explained in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a peer transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be determined by a combination of script and node protocol.

[0041] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is “validated”), any blockchain node 104 that receives the transaction 152j will add the newly verified transaction 152 to the ordered set of transactions 154 maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j will propagate the verified transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, it will soon be propagated throughout the network 106.

[0042] Once admitted to the ordered pool 154 of pending transactions maintained by a given blockchain node 104, that blockchain node 104 will begin a race to solve a proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152 (recall that other blockchain nodes 104 may attempt to solve the puzzle based on different pools of transactions 154, but whoever gets there first will define the set of transactions contained in the latest block 151). Eventually, the blockchain node 104 will solve the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j. Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer back to previous transactions, the order of transactions is also immutably recorded.

[0043] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have competing views of which instance is "valid" before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0044] Another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not determine the amount transferred by referencing back to the UTXO of the transaction that precedes it in the sequence of past transactions, but rather by referencing the absolute account balance. The current state of every account is stored separately from the blockchain and is constantly updated by the nodes of the network. In such a system, transactions are ordered using a running transaction tally (a.k.a. "position") of the account. This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction referencing operation. Additionally, an optional data field may be signed in the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0045] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). In the following, it is described by reference to an output-based protocol or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0046] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) that can be used as a source of input 202 for another new transaction (unless the UTXO has already been redeemed). The UTXO includes a value that specifies an amount of digital assets, which represents a set number of tokens in the distributed ledger. The UTXO may also include the transaction ID of the original transaction from which it came, among other information. The transaction data structure may also include a header 201, which may include indicators of the size of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (minus the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0047] For example, suppose Alice 103a wishes to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of digital asset locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point back to some preceding (i.e., prior) transaction that still has unspent output 203 locked to Alice.

[0048] The predecessor transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created together and submitted to the network 102, or even Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "predecessor" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in a sequence defined by transaction pointers specified in the transactions (e.g., which transactions point back to which other transactions). They may be equivalently replaced by "predecessor" and "successor," "ancestor" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are generated, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0049] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be satisfied by an unlocking script in the input 202 of the following transaction in order for the following transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (a payee included in the transaction). That is, the locking script defines the unlocking condition, typically including a condition that the unlocking script in the input of the following transaction contains a cryptographic signature of a party to which the preceding transaction was locked.

[0050] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called “Script” (capital S), which is used by blockchain networks. A locking script specifies what information is required to consume a transaction output 203, e.g., the conditions of Alice’s signature. An unlocking script appears in the transaction’s output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of the locking script. For example, it could include Bob’s signature. An unlocking script appears in the transaction’s input 202.

[0051] In the example shown, UTXO0 in output 203 of Tx0 is sent by the locking script [Checksig P A], which means that Alice's signature, Sig P, must be present in order for UTXO0 to be redeemed (or more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx0. Tx1's input 202 includes a pointer back to Tx0 (e.g., by using its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 in Tx0 in order to identify it among any other possible outputs of Tx0. Tx1's input 202 further includes an unlocking script that includes Alice's cryptographic signature, created by Alice by applying her private key from her key pair to a given portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by a locking script, by a node protocol, or by a combination of these.

[0052] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions set out in the locking script (which may include one or more criteria). In an embodiment, this involves concatenating two scripts: <Sig P A > <P A >||[Checksig P A ]

[0053] Here, “||” denotes concatenation, “<···>” means to put its data on top of the stack, and “[···]” is a function composed by the locking script (in this example, a stack-based language). Equivalently, the scripts may be executed one after the other (one after the other) using a common stack rather than concatenating the scripts. In any case, when executed together, the scripts will use Alice’s public key P, as included in the locking script in the output of Tx0. A , to authenticate that the unlocking script in the input of Tx1 contains Alice's signature signing the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data includes the entirety of Tx1 (thus specifying the signed portion of the data in plaintext, without requiring that individual elements be included, since they are already inherently present).

[0054] The details of authentication via public-private (key) cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message with her public key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this with the message as a signature, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that in this document, any reference to signing a particular portion of data or part of a transaction, etc., may in embodiments mean signing a hash of that portion of data or part of a transaction.

[0055] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the illustrated example, Alice’s signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to the ordered pool of waiting transactions 154. The blockchain node 104 also forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will be propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 receives the UTX referenced in the preceding transaction Tx0. O This is one of the reasons why it is important for the blockchain 150 to impose the order defined by transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately determines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0056] If the total amount specified by all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another basis for invalidity in most transaction models, and therefore such a transaction will not be propagated or included in a block 151.

[0057] Note that the UTXO-based transaction model requires that a given UTXO be spent in its entirety; it is not possible to "keep" a portion of the amount bounded by the UTXO while spending another portion. However, amounts from a UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount bounded by UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount bounded by UTXO0, she can use the remaining amount to give herself change in the second output of Tx1 or to pay someone else.

[0058] In practice, Alice would typically also need to include a fee for any Bitcoin nodes 104 that successfully included her transaction 104 in block 151. If Alice did not include such a fee, Tx0 could be rejected by the blockchain nodes 104 and thus, although technically valid, it may not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount indicated by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose that the only pointer to UTXO0 is an input to Tx1, which has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated to the node 104 that won the proof-of-work competition and produced the block containing UTXO1. However, nothing in this specification excludes that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0059] Alice and Bob's digital assets consist of the UTXOs that were locked to them in some transaction 152 somewhere on the blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number that defines the total balance of a given party 103 stored somewhere in the blockchain 150. It is the role of the wallet function in the client application 105 to bring together the value of all the various UTXOs that are locked to each party and have not yet been spent in another onward transaction. It can do so by querying a copy of the blockchain 150, such as that stored in some Bitcoin node 104.

[0060] Note that script code is often expressed generally (i.e., without using a strict language). For example, one might use an operation code (opcode) to express a particular function. “OP_...” denotes a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, generates an unspendable output of the transaction that can store data within the transaction, thereby recording the data immutably in the blockchain 150. For example, the data can include a document that is desired to be stored on the blockchain.

[0061] Typically, the input of a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs certain data. In some embodiments, for a given transaction, the signature will sign a portion of the transaction inputs and some or all of the transaction outputs. The particular portion of the outputs that are signed depends on the SIGHASH flag, which is typically a four-byte code included at the end of the signature (and thus determined at the time of signing) to select which outputs are signed.

[0062] A locking script is often called a “scriptPubKey”, referring to the fact that it typically contains the public key of the party to which each transaction is locked. An unlocking script is often called a “scriptSig”, referring to the fact that it typically provides a corresponding signature. However, more generally, it is not required that in all applications of blockchain150 the conditions under which a UTXO is redeemed include authenticating a signature. More generally, the scripting language can be used to define any one or more conditions. Thus, the more general terms “locking script” and “unlocking script” may be preferable.

[0063] 3. Side Channel As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 102b, respectively, may include additional communication capabilities. This additional functionality allows Alice 103a to establish (at the invitation of either party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication is often referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Sharing transactions in this manner is often referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, side channel 107 may be used to exchange some other transaction related data, such as keys, negotiated amounts or terms, data content, etc.

[0064] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or over a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, a side channel 107 as referred to anywhere in this application may include any one or more links (off-chain), i.e., separate from the blockchain network 106, over one or more networking technologies or communication media for exchanging data. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, it should be noted that when it is referred to as Alice and Bob exchanging certain information or data, etc. over the side channel 107, this does not necessarily mean that all of these data must be transmitted over exactly the same links, or even over the same type of network.

[0065] 4. Node Software FIG. 3 illustrates an example of node software 450 that runs on each blockchain node 104 of the network 106 in an example UTXO or output-based model. Note that another entity may operate the node software 450 without being classified as a node 104 in the network 106, i.e., without performing the operations required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to recognize various fields of transactions 152 and process them according to a node protocol. Transaction 152j(Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx j The protocol engine 451 also identifies the unlocking script for the Tx j Based on the pointer in the input of Tx i Identify and extract Tx i can be published on the blockchain 150, in which case the protocol engine derives the Tx i Alternatively, it is possible to extract Tx iIt is possible that Tx has not yet been published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 extracts the Tx i locates the locking script in the referenced output of and passes it to the script engine 452.

[0066] The script engine 452 therefore j The unlocking script and Tx from the corresponding input i For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same is applicable to any pair of transactions. The script engine 452 executes the two scripts together as described above, which may include placing data on and popping data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0067] By running those scripts together, the script engine 452 determines whether the unlocking script meets one or more criteria defined in the locking script, i.e., whether the locking script “unlocks” the output it is contained in. If the script engine 452 determines that the unlocking script meets one or more criteria specified in the corresponding locking script, it returns a result of “true.” Otherwise, it returns a result of “false.”

[0068] In the output-based model, a “true” result from the script engine 452 is one of the conditions for the validity of a transaction. Typically, there are also one or more further protocol-level conditions that must be satisfied as well, as evaluated by the protocol engine 451; for example, Tx j the total amount of Digital Assets specified by its Output(s) does not exceed the total amount specified by its Inputs; and i The specified output of the transaction Tx has not already been consumed by another valid transaction. The protocol engine 451 evaluates the results from the script engine 452 together with one or more protocol level conditions, and starts the transaction Tx only if they are all true. j justify. The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j Only under the condition that the TxS bit is actually verified, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to transmit the TxS bit. j Each of them can perform its own blockchain-related function on the Tx j to the node's respective set of ordered transactions 154 for incorporation into block 151; and j to another blockchain node 104 in the network 106. Optionally, in embodiments, the application level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may only choose to publish a transaction under the conditions that the transaction is valid and sufficient transaction fees remain.

[0069] Also, note that the terms "true" and "false" in this case are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or negative outcome. For example, in an account-based model, a "true" outcome can be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (where both individual outcomes are true, the overall outcome is considered to indicate true).

[0070] 5. Elliptic curve calculations in scripts FIG. 4 illustrates an example system 400 for implementing embodiments of the present disclosure. The system 400 includes a first script generator (Alice 103a), a second script generator (Bob 103b), and one or more engines in the form of blockchain nodes 104 of a blockchain network 106. It should be understood that this is merely an illustrative example, and that in general, the script generators and script engines may be implemented by any suitable entity, not just Alice 103a, Bob 103b, and the blockchain nodes 104. In some examples, the first script generator may include a function library configured to output a first script. The function library may enable a user to update one or more values ​​(e.g., modulus value, scalar value, etc.) of the first script to generate a first script specific to a particular use case.

[0071] Continuing with the example of FIG. 4, Alice 103a is configured to generate a first script for a first blockchain transaction. As shown, Alice 103a may generate the first transaction and send the first transaction to the blockchain network 106. Alternatively, Alice 103a may make the first script available to a different entity, e.g., a different user, to submit to the blockchain network 106 as part of the blockchain transaction. In the example of FIG. 4, the first script forms part of a locking script that locks the output of the first transaction. In other examples, the first script may form part of an unlocking script ("second script") of a second transaction. A blockchain node 104 of the blockchain network 106 is configured to receive the first and second transactions and execute the first script together with the second script.

[0072] 5.1. Modular Inversion The first script includes a modular inversion script. The modular inversion script is configured to generate a modular inverse of the target integer using a modulus value (or modulus value) that is relatively prime to the target integer. The target integer and the modulus value are provided as inputs to the modular inversion script. In some examples, the inputs are included in the same script as the first script, i.e., the modular inversion script. In other examples, the inputs are included in a second script of a second blockchain transaction. For example, the second script may be or form part of an unlock script of the second transaction. The second transaction may be generated by Bob 103b and submitted to the blockchain network 106, as shown in FIG. 4.

[0073] In an embodiment, the modular inversion script is configured to generate a modular inverse of the target integer if the modulus value is prime (n=p), in which case:

[0074]

number

[0075] In the following, the elements to inverse are in (0,p) and therefore positive, making it possible to use the opcode OP_MOD.

[0076] Value x p-2 mod p can be calculated using the addition chain algorithm. The addition chain for p-2 is the sequence (a1,...,a l(エル) ) such that each term in the sequence is the sum of the two preceding terms, starting with 1 and ending with p-2.

[0077] For an additive chain of a given length l, x p-2 To compute mod p, we perform l-1 modular multiplications. i Regarding the two preceding terms a si ,a ti But, a i That is, a i =a si +a ti It is. An example additive chain is:

[0078]

number

[0079]

number

[0080]

number

[0081]

number

[0082]

number

[0083] The modular inversion script also uses l multiplier values ​​m i where a first multiplier value m1 of the sequence of multiplier values ​​is equal to the target integer x and a second multiplier value m2 of the sequence of multiplier values ​​is calculated, and for each component of the additive chain for 3≦i≦l, each multiplier value m of the sequence of multiplier values ​​is calculated. i is calculated iteratively, and each multiplier value is calculated by multiplying the target integer x by the component a i The modular inversion script uses the exponential values ​​m i Each of these is divided into (1) the pair of preceding components in the summation chain (m si ,m ti ), and (2) multiplying the selected multiplier value by the respective multiplier value m i and (3) pushing the generated multiplier value onto a stack. The stack onto which the multiplier value is pushed may be an alternative stack (alt).

[0084] The modular inversion script calculates the final multiplier value m with respect to the modulus value p. l(エル)Remainder of m l(エル) mod p which is output as the modular inverse.

[0085] The second multiplier value in the sequence of multipliers is x 2 mod p It is possible to calculate it as:

[0086] The modular inversion script also i The method may be further configured to calculate a remainder for p modulo a modular value p.

[0087] Once the modular inverse has been computed, the modular inversion script may be further configured to remove each multiplier value, for 1≦i≦l−1, from the stack.

[0088] The box below shows an example point addition script [mod invert with addition chain] that adds modulus values About target integer <x>1 shows a configuration for computing and outputting the modular inverse of . The example script shown here is written in the Script scripting language, such as that used in the Bitcoin blockchain. It should be understood that the described embodiments are not limited to any particular scripting language, and that Script is used merely as an example. Other suitable scripting languages ​​may be used.

[0089]

number

[0090] In the above script, the initialization requires 8 bytes. The first loop has 9 bytes, and the second loop (finalization) has only 1 byte. This results in a script with the following size:

[0091]

number

[0092] where l is the length of the additive chain. To limit the size of the script, roughly 2.4 KB for the elliptic curve secp265k1, the length l should not be too large, specifically no more than:

[0093]

number

[0094] To achieve the above targets, suitable heuristics may be employed. The script "mod invert via branchless square and multiply" is sometimes referred to herein as "modular invert."

[0095] 5.2. Points The modular inversion script may be used to compute the modular inverse of an integer as part of performing an addition of two elliptic curve points. Let P be an odd prime number, and a, b ∈ Z p , 4a 3 -27b 2 ≠ 0. A Weierstrass elliptic curve is the set:

[0096]

number

[0097]

number

[0098] The inverse of an affine point P:=(x,y) is defined as -P:=(x,-y). All the above operations are done on Z p This is in. The most expensive operation in point addition is computing the modular inverse. In terms of size, it becomes even more expensive in scripts because we need to open the loop.

[0099] The first script may include a point addition script configured to determine a first elliptic curve point (P), a second elliptic curve point (Q), and a modulus value (p). In the script, the elliptic curve points P and Q may be expressed as (x1, y1) and (x2, y2), respectively. The point addition script is configured to output the addition (P+Q) of the first point and the second point. The addition (P+Q) is referred to herein as a first target point. In some examples, the first and / or second elliptic curve points may be obtained from a second script of a second transaction. In calculating the first target point, the point addition script is configured to calculate a lambda value λ. As shown above, λ is based on the values ​​of the numerator and denominator. The numerator and denominator are calculated in the script. That is, the point addition script calculates the inverse of the denominator and multiplies the numerator by the inverse of the denominator to calculate λ. In other words, the modulus value and target integer input to the modular inversion script are the calculated denominator and p, respectively. The calculated λ is then used by the point addition script to calculate the first target point according to Equation 4.

[0100] The point-summing script is configured to calculate the numerator and denominator according to Equation 4a and Equation 4b above depending on whether the first point and the second point are equal. The point-summing script may be configured to determine whether the first point and the second point are equal in the script. That means that the script for calculating λ needs to be included only once as part of the point-summing script. That means that the modular inversion script needs to be included only once as part of the point-summing script.

[0101] The point addition script is also configured to determine whether either the first point or the second point is equal to an identity element (φ), and only calculate λ if neither the first point nor the second point is equal to the identity element (φ).

[0102] The next box shows an example point addition script, [Add points], configured to compute and output the sum of two elliptic curve points.

[0103]

number

[0104] The script [Add points] expects a stack initialized with the five top elements, from bottom to top, y2, x2, y1, x1, p, which are the coordinates and modulus p of the points P, Q to be added. After completion, the script pops P, Q, p and returns the coordinate y of P+Q. + ,x + (in that order). The script calls the inverse subroutine only once during the generation of lambda, instead of calling it (twice) with branch statements (4a) and (4b).

[0105] More precisely, if λ:=N / D mod p, the subroutine script [Computeλ] (see below) computes (over integers) the appropriate numerator N and denominator D in branches (4a) and (4b). In the joint branch (4), it performs the modulo operation of the invert D and completes the computation of λ and P+Q. After completion, the script pushes the stack scalar λ in addition to the coordinates of P+Q.

[0106] Calculate P+Q using the script [Add points from precomputedλ] (below). The stack is assumed to be initialized with the six top elements y2, x2, y1, x1, λ, p from bottom to top. After completion, the coordinates of P and Q plus the coordinate y of the addition point P+Q are + ,x + Push,λ,p,onto the stack and consume,λ,p,. Two-point addition is governed by modular inversion complexity. Specifically, the script contains 37 opcodes, plus a subroutine:

[0107]

number

[0108] The following box shows an example script [Computeλ] that can be configured to calculate and print λ based on the numerator, denominator, and modulo values. This example script uses the modular inversion script.

[0109]

number

[0110] The following box shows an example script (Add points with precomputed λ) configured to calculate and output a target point based on a first point, a second point, and a precomputed λ value.

[0111]

number

[0112] 5.3. Point Subtraction The first script may include a point subtraction script configured to subtract one elliptic curve point from another. In some examples, the point subtraction script may include a point addition script.

[0113] The point subtraction script is configured to determine a third elliptic curve point and a modulus value. The point subtraction script is configured to negate the third elliptic curve point with the modulus value and output the result to the point addition script as either the first or second elliptic curve point. That is, the point subtraction script negates an elliptic curve point and the negated result is added to another elliptic curve point by the point addition script.

[0114] The following box shows an example point negation script [Negate point] that may be used by a point subtraction script to negate an elliptic curve point.

[0115]

number

[0116] This operation finds the inverse of a point. It is implemented for Weierstrass curves, where the negation of a point P=(x,y) is defined as -P:=(x,-y mod p). The negation point script consumes the point and pushes its negation. It expects a stack with point coordinates reduced mod p (least positive residues), so it is possible to use OP_MOD. 7 bytes are needed to negate a point.

[0117] The subtraction of two points can be performed using the Negate point and Add points scripts, which have already been described. The resulting complexity is the sum of the complexity of the two scripts:

[0118]

number

[0119] 5.4. Point doubling The modular inversion script may be used to compute the modular inverse of integers as part of performing elliptic curve point doubling, as defined above in Equation 4b.

[0120] The first script may include a point doubling script configured to obtain a fourth elliptic curve point (P) and a modulus value (p). In the script, the elliptic curve point P may be represented as (x1, y1). The point doubling script is configured to output a double of the elliptic curve point (2P). The double (2P) is referred to herein as the second target point. Note that in general, labels such as "first", "second", "third", etc. are used as arbitrary labels and do not necessarily imply the presence of an order or any other value unless the context requires otherwise. For example, the second target point may be calculated without needing to calculate the first target point. Similarly, "first" and "second", etc. may be used as labels for the same or different values, or other types of data. For example, the "first" elliptic curve point and the "third" elliptic curve point may be the same point.

[0121] In some examples, the elliptic curve point to be doubled may be obtained from a second script of a second transaction.

[0122] The point doubling script may be configured to calculate a second lambda value in a manner similar to that described above for the point addition script: the numerator and denominator are calculated (e.g., using Equation 4b), the inverse of the denominator is calculated using a modular inversion script, and then the inverse of the denominator is multiplied by the numerator to generate λ. The point doubling script is configured to calculate a second target point using a third elliptic curve point (P) and λ.

[0123] The box below shows an example point doubling script, [Double points], configured to compute and output the double of an elliptic curve point. It takes a point and a modulus, pushes the double, and consumes an argument. The doubling of points is governed by modular inverse. However, the constant is slightly smaller than for the addition of two points using [Add points]. Specifically, we have:

[0124]

number

[0125]

number

[0126] 5.5. Scalar Multiplication The first script may include a first multiplication-by-scalar (MBS) script configured to multiply a fifth elliptic curve point (P) by a scalar (k). Again, note that “fifth” is used merely as a convenient label. The first MBS script is configured to obtain a fifth elliptic curve point, a scalar value, and a modulus value. The scalar value is represented in binary or converted to binary within the script. The first MBS script is configured to use a double-and-add algorithm to calculate kP, which is referred to herein as the third target elliptic curve point.

[0127] To calculate kP, the double-and-add algorithm iteratively calculates the double as follows: i to the resulting point R if and only if the i-th bit of scalar k is set:

[0128]

number

[0129] More specifically, the first MBS script contains a series of sub-scripts that are executed in sequence. Each sub-script is associated with a respective index and contains an instance of a point doubling script (e.g., [Double point]). Recall that the point doubling script utilizes a modular inversion script.

[0130] The first of the subscripts in the sequence is configured to double the fifth elliptic curve point, i.e., to calculate D1:=2P, which is referred to as the first intermediate result. The next of the subscripts in the sequence doubles the first intermediate result, i.e., D2:=D1+D1=2 2 P, which is referred to as the second intermediate result. The process is repeated one or more times. In general, each subscript is configured to generate a respective intermediate result by doubling a preceding value, where the preceding value is either the fifth elliptic curve point (P) or the previous intermediate result (D i-1 ) is one of them.

[0131] The first MBS script is configured to calculate kP by adding up the intermediate results generated by the sub-scripts, each of which is associated with a corresponding bit (set, i.e., equal to 1) of the scalar k. In other words, if the i-th bit is set, the i-th intermediate result generated by the i-th sub-script is added to the result value. The result value may be initialized as an empty array and updated by adding each of the associated intermediate results.

[0132] The following box shows an example first MBS script, [Multiply by scalar via double - and - add], configured to compute and output a scalar multiplication of elliptic curve points. It takes a point, a scalar, and a modulus, and pushes the resulting scalar multiplication.

[0133]

number

[0134] Multiply by scalar via double - and - add uses the script shown in the box below as a subroutine to, for points R and D (doubling) on ​​an elliptic curve and scalar k, update R with or without R+D based on the value of the i-th bit of scalar k. After the subroutine executes, the top of the stack is either P (bit not set) or P+D (bit set). This leaves the scalar as the third to top element of the scalar.

[0135]

number

[0136] Here we count the number of bytes to do a scalar multiplication using double-and-add, where there are two factors, κ, the size of the modulus p of the base field, and n, the size of the scalar k (both are 256 bits long in secp256k1). The script has 9n opcodes plus a subroutine:

[0137]

number

[0138] 5.6. Scalar Multiplication - Fixed Point The first script may include a second multiplication-by-scalar (MBS) script configured to multiply a sixth elliptic curve point (P) by a scalar (k). Again, note that both "second" and "sixth" are used merely as convenient labels. The second MBS script differs from the first MBS script; that is, the first and second MBS scripts are different kinds of scripts configured to perform different functions. The second MBS script is configured to obtain a point on a given elliptic curve by a scalar using a modulus value. The scalar value is represented in binary or converted to binary within the script. Similar to the first MBS script, the second MBS script is also configured to calculate kP using a double-and-add algorithm, which is referred to herein as the fourth target elliptic curve point. However, in this case, the double D i are pre-computed rather than being calculated in the script.

[0139] The second MBS script includes a series of sub-scripts that are executed in sequence. Each sub-script is associated with a respective index and includes an instance of a point addition script (e.g., [Add points]). Each sub-script includes a pre-computed doubling of each of the sixth elliptic curve points. That is, the first sub-script includes the first doubling D1:=2P, the second sub-script includes the second doubling D2:=D1+D1=2, and so on. 2 P. Each sub-script is configured to add its respective doubling to the result using a point addition script if the corresponding bit of the scalar is set, i.e., equal to 1. In other words, the i-th sub-script adds the i-th doubling D i to the result value. The result value may be initialized as an empty array and updated by adding each of the associated doublings.

[0140] The box below shows an example second MBS script, [Multiply P by scalar], configured to compute and output a scalar multiplication of elliptic curve points. It takes a scalar and a modulus, and pushes the resulting scalar multiplication.

[0141] Compared to the doubling and adding script above, this saves a doubling:

[0142]

number

[0143]

number

[0144] 6. More scripts This section lists several scripts that may be included as part of the first script. It will be understood that these scripts are merely examples and that it is within the skill of one of ordinary skill in the art, given this disclosure, to develop equivalent scripts that perform equivalent functions. The same applies to the example scripts above. 6.1. Determine if a bit is a one or a zero. (b κ-1 Let b0 (b,...,b1) be a big-endian bit array of κ-bit integers:

[0145]

number

[0146] The byte length of λ is

number

[0147] We can check whether the i-th bit bi of λ is set to 1 using bitwise arithmetic: 1. Calculate the 8l bit representation of 1. In big endian, this is 8l-1 zeros followed by a single 1. 2. Shift the 1 bits left a total of i positions, which is equivalent to calculating 2i. (If the position index starts at 1, shift i-1 positions instead.) 3.2 i and λ. The following box shows an example script, [Is bit set], configured to take a target bit and a scalar as arguments. The first line pushes the integer 1 as an l byte array in big endian (necessary for bitwise OP_AND); OP_NUM2BIN converts to a little endian number, so we directly append a bit 1 to the right end of a (l-1)-long zero-array. The second line sets only the i-th bit of the pushed 1. The third line leaves the number res on the top of the stack, which is 2 i (Bit is set,b i =1) or 0 (bit not set, b i =0). Thinking ahead, this can be interpreted as a Boolean value to branch on in an OP_IF statement.

[0148]

number

[0149] Indicates the state of the stack after each line is executed. l(エル) is a byte array of length l (ell) representing an integer n in big endian order.

[0150]

number

[0151] The size of the script [Is bit set] is 9 bytes regardless of the size of λ.

[0152] 6.2. Point doubling It is often useful to be able to double two points P:=(x1,y1) and Q:=(x2,y2). The following example script does just that. It requires 2 bytes to double a pair of points.

[0153]

number

[0154] 6.3. Point equality Two points on an elliptic curve are equal if and only if their coordinates are the same. A script that implements this logic is given in the box below. It consumes the coordinates of the points and pushes a 1 onto the stack if the points are equal, otherwise pushes a 0. The script assumes a stack where the point coordinates have already been reduced modulo p. 5 bytes are needed to check if two points are equal.

[0155]

number

[0156] 6.4. Identity elements Let ε be an empty array. We denote the identity of the Weierstrass curve as follows: φ:=(128,ε)=(0x80,ε) where ε denotes the empty array. In some cases, script engines interpret the integer 128 as positive zero. This choice therefore ensures that the identity element is not part of the set of affine points of the curve: the zero coordinate in the script engine is given by 0x00, not 0x80.

[0157] The test of whether a given point is φ can be performed more efficiently than the equivalence of points. It is sufficient to test whether the first coordinate matches 0x80 as a byte array. See the following script [Is identity element]. The coordinates are assumed to be reduced modulo p, i.e., the coordinates are assumed to be in the range [0, p). If the point is the identity element, consume the point and push 1. Otherwise, push zero. Three bytes are required to test whether a point is the identity element of the curve.

[0158]

Number

[0159] 6.5. Modular reduction The opcode OP_MOD is implemented in the script engine by the remainder operator %. Integer division in C truncates towards zero, so % may output a negative number. That is, for -n < x < n, x = x, n OP_MOD. In other words, the output range of OP_MOD is not a residue system. Example: -2 = -5, 3 OP_MOD

[0160] Modular reduction can be implemented using the script example shown in the following box. Specifically, the range output of the script is the least residue system {0, 1,..., n - 1}. Example: 1 = -5, 3 [Reduce mod]

[0161] The script assumes that the top of the stack is x, n, outputs x mod n ∈ [0, n), and consumes the arguments. In the specific context (i.e., in the combination of the script engine OP_MOD implementation), (x % p + p) % p is calculated.

[0162]

number

[0163] 6.6. Loading the Modulus from the Alt Stack To avoid hard-coding the modulus in many high level scripts, it is possible to define the following script and keep it in the alt stack. It is assumed that the modulus has already been moved to the alt stack.

[0164]

number

[0165] 6.7. Base Change The size of scalar multiplication for any point P (unknown at the time the script is written) can be improved significantly if we assume that we know the logarithm of P in a known base G. For some fixed G, suppose P=xG, then kP=(xk)G. Therefore, what is needed is to run a fixed-point script, passing a scalar y as an argument, and computing y=xy. The example script shown in the box below does this: x:=log G Note that P is passed as a parameter. The script outputs yP. The size of the script exceeds the size of the underlying fixed-point script by 3 bytes.

[0166]

number

[0167] 7. Example Use Cases Using the EC operations in the above script, it is possible to redeem UTXO. Below are some example use cases:

[0168] 7.1. Pedersen commitments One can spend UTXO if one knows an opening m,r of the Pedersen commitment C=xG+rP specified in the locking script. The generators G and H are known. With hidden commitments, it is possible to commit to a message m from a small set. For example, m can be a string or a bit from a small public set. This can be useful in Hash Time Locked Contracts (HTLCs) when one wants the commitment scheme to hide the committed value.

[0169] In one embodiment, a script may be provided that includes two instances of the second multiplication of scalars (MBS) script described in Section 5.6 and one instance of the point addition script described in Section 5.2, and also includes a commitment point.

[0170] The script is configured to implement an MBS script to multiply H by a scalar r to compute a first elliptic curve point rH, where r is provided in the unlocking script. The script is configured to execute a second instance of a second MBS script to multiply G by a scalar m to compute a second elliptic curve point mG. The script executes a point addition script to compute the sum of rH and mG, and then calculates a candidate commitment point C. * Finally, the script is configured to verify that the calculated commitment candidate point is equal to the script's commitment point.

[0171] The following box shows an example script [Open Pedersen Commitment C] that is configured to calculate and output commitment candidate points with respect to m and r.

[0172]

number

[0173] A UTXO can only be spent if the opening for the commitment is known. The commitment C and the generators G,H are hard-coded in the locking script. The opening (m,r) is given in the unlocking script. Note that the committed message m can be as small as 1 bit. The script has the following size:

[0174]

number

[0175] Here, the curve is a base field Z of κ bits. p It is instantiated above. On secp256k1 this results in roughly a 1.5MB script. 7.2. Secret Key Puzzle Using the private key puzzle, funds can be spent only if the signing key s corresponding to the public key P := s G is revealed.

[0176] The private key puzzle can be implemented by exposing an ECDSA ephemeral key, resulting in a very lightweight locking script with just a few opcodes.

[0177] This approach requires regenerating the private key off-chain using the contents of the unlocking script. It is possible to use EC arithmetic to envision a locking script that imposes further constraints on the signing key (the solution to the puzzle).

[0178] This has application for conditional payments for goods. For example, it may be applied to outsourcing vanity addresses that do not perform off-chain computations or communication. In fact, buyer ,P buyer ), a buyer with a locking script can issue a transaction whose locking script enforces the following three conditions on the ECDSA key pair (s,P) under the unlocking script: i. Forcing P=s·G using the scripts [Multiply G by scalar] and [Are equal points] ii. A vanity address containing a pre-determined pattern d:=RIPEMD160(SHA256(P+P buyer )) to generate D, we use the input P and the hard-coded P buyer Use the script [Add points] and opcode OP_HASH160 for this. Use OP_SPLIT to check d against a hard-coded pattern.

[0179] Anyone who spends this transaction gives up the signing key s, so the buyer has the vanity address signing key s buyer +s can be derived.

[0180] A script may be provided that includes the predetermined public key, the predetermined address, an instance of the second MBS, and an instance of the point-adding script.

[0181] The script is configured to obtain the private key and the candidate address from the unlock script of the subsequent transaction. The script is further configured to input the private key into an instance of a second MBS script to generate a candidate public key. The generated candidate public key is then verified in the script to be equal to the predefined candidate key, for example using the [Are equal points] script. The script is further configured to input the candidate public key and the predefined public key into an instance of a point addition script to generate elliptic curve candidate points, and hash the generated elliptic curve candidate points to generate a candidate address. The script is configured to verify that the candidate address matches the predefined address, or that a portion of the candidate address matches a portion of the predefined address.

[0182] With secp256k1 the locking script is about 700 KB.

[0183] 7.3. Paying for Cipher Text In this case, a transaction is redeemed using knowledge of the plaintext m and the decryption key sk, which decrypts a fixed ciphertext C. The locking script contains C and implements the decryption algorithm.

[0184] It is possible to use ElGamal, but it will be understood that a group-based encryption scheme will work. Given an ElGamal ciphertext C=(C0,C1) for an elliptic curve specified by a locking script, the locking script defines C as a * :=C1-skC0, m=m * This is also implemented in EC arithmetic using fixed-point scalar multiplication and subtraction.

[0185] 8. Notes Other modifications or use cases of the disclosed techniques will be apparent to one of ordinary skill in the art given this disclosure. The scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

[0186] For example, some embodiments above are described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is a particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 can be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes can share some or all of the described features of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0187] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least some or all of the described functions of generating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without generating and publishing them (recall that these entities are not necessarily considered to be preferred Bitcoin network 106 nodes).

[0188] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but not to store and / or propagate those blocks 151 to other nodes.

[0189] Moreover, more generally, any reference above to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element”, where such entity / element is configured to perform some or all of the roles of creating, issuing, propagating and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to a blockchain node 104.

[0190] It will be understood that the above embodiments have been described by way of example only. More generally, it is possible to provide a method, apparatus or program according to any one or more of the following statements:

[0191] Statement 1. 1. A computer-implemented method for enabling elliptic curve arithmetic to be performed with blockchain transactions, the method being performed by a script generator, the method comprising: generating a first script for a first blockchain transaction; outputting a first script for inclusion in a first blockchain transaction; The first script contains a modular inversion script that, when executed by the script engine, results in: obtaining a target integer (x) and a modulus value (p), where the target integer and the modulus value are mutually prime and the modulus value is a prime number; The components (a i ) index pair (s i ,t i ), where the reduced modulus value has a value two less than the modulus value, and the index identifies a pair of preceding components of the additive chain that, when summed, equals the component of the additive chain, the additive chain having a length l; and obtaining a modular inverse (y) of a target integer, the modular inverse being generated by exponentiating x to a reduced modulus (p-2) using additive chaining by computing a sequence of l multiplier values ​​and computing the remainder of the multiplier values ​​with respect to the modulus value (p) when i=l; wherein a first multiplier value in the sequence of multiplier values ​​is equal to the target integer and a second multiplier value in the sequence of multiplier values ​​is calculated, and for each component of the additive chain for 3≦i≦l, a respective multiplier value in the sequence of multiplier values ​​is iteratively calculated, each respective multiplier value being an exponentiation of the target integer (x) by a component of the additive chain, and each respective multiplier value being: selecting from a stack a multiplier value associated with a preceding pair of components in an additive chain; multiplying the selected multiplier value by the selected multiplier value to generate a multiplier value for each of the components; and pushing the generated multiplier value onto the stack; The remainder of the multiplier value to the modulus value (p) is output as the modular inverse (y).

[0192] Statement 2. In the method of statement 1, the second multiplier value in the sequence of multiplier values ​​is x 2 It can be calculated as p mod p.

[0193] Statement 3. In the method of statement 1 or statement 2, the modular inversion script may be further configured to calculate, for each generated multiplier value, a remainder of the multiplier value with respect to a modulus value (p).

[0194] Statement 4. In the manner of any preceding statement, the modular inversion script may be further configured to push the modular inverse onto a main stack.

[0195] Statement 5. In the method of any preceding statement, the modular inversion script may be further configured to remove each multiplier value, 1≦i≦l−1, from the stack.

[0196] Statement 6. In accordance with any of the preceding statements, the multiplier value may be pushed onto the alternative stack. Statement 7. In the method of any of the preceding statements, the length of the additive chain is

[0197]

number

number

[0198] Statement 8. In the method of any preceding statement, the method further comprises: including the first script in a first blockchain transaction; and submitting the first blockchain transaction to one or more blockchain nodes and / or one or more blockchain users; may also include

[0199] Statement 9. In the method of any preceding statement, outputting the first script may include transmitting the first script to one or more blockchain users.

[0200] Statement 10. In the method of any of the preceding statements, the first script includes a point addition script, the point addition script comprising: obtaining a first elliptic curve point, a second elliptic curve point, and a modulus value; and performing elliptic curve addition of the first and second elliptic curve points to output a first target elliptic curve point; wherein the point addition script includes a modular inversion script, and performing the elliptic curve addition may include calculating a first lambda value used to calculate a respective x-coordinate and a respective y-coordinate of the first target elliptic curve point, and calculating the first lambda value includes calculating a first numerator value and a first denominator value, and the point addition script is configured to cause the modular inversion script to be executed with the first denominator value set as the target integer to generate a modular inverse of the first denominator value, and the first lambda value is calculated by multiplying the first numerator value by the modular inverse of the first denominator value.

[0201] Statement 11. In the method of statement 10, the point addition script may include a first branch configured to generate a first numerator value and a second numerator value if the first and second elliptic curve points are equal and a second branch configured to generate the first numerator value and the second numerator value if the first and second elliptic curve points are not equal, and the modular inversion script is executed after either the first branch or the second branch is executed, and the modular inversion script is included once as a part of the point addition script.

[0202] Statement 12. In the method of statement 10 or statement 11, the first script may include a point subtraction script, the point subtraction script comprising: obtaining a third elliptic curve point and a modulus value; and outputting the second elliptic curve point to a point addition script; where the second elliptic curve point is generated by computing a remainder of the elliptic curve point with the modulus value and negating the result.

[0203] Statement 13. In the method of any of the preceding statements, the first script includes a point doubling script, the point doubling script comprising: obtaining a fourth elliptic curve point and a modulus value; and outputting a second target elliptic curve point by doubling the fourth elliptic curve point; wherein the point doubling script includes a modular inversion script, and performing the doubling of the fourth elliptic curve point may include calculating a second lambda value used to calculate a respective x-coordinate and a respective y-coordinate of the second target elliptic curve point, and calculating the second lambda value includes calculating a second numerator value and a second denominator value, and the point doubling script is configured to cause the modular inversion script to be executed with the second denominator value set as the target integer to generate a modular inverse of the second denominator value, and the lambda value is calculated by multiplying the second numerator value by the modular inverse of the second denominator value.

[0204] Statement 14. In the method of statement 13, the first script may include a first multiplication by scalar (MBS) script, the first MBS script comprising: obtaining a fifth elliptic curve point, a modulus value, and a first scalar value, the first scalar value being represented in binary, each bit of the binary representation being associated with a respective index; and multiplying the fifth elliptic curve point by a scalar value using a double-add algorithm to output a third target elliptic curve point; the first MBS script includes a sequence of sub-scripts executed in sequence, each sub-script associated with a respective index and including an instance of a point doubling script, a first of the sub-scripts configured to double the fifth elliptic curve point using the point doubling script and output a respective intermediate result, each of the successive sub-scripts in the sequence configured to use the point doubling script to double a respective intermediate result output by a preceding sub-script in the sequence, and the first MBS script configured to generate a third target elliptic curve point by adding together respective intermediate results generated by respective sub-scripts having respective indexes corresponding to the same respective indexes as the respective bits of the binary representation of the first scalar value that are set to 1.

[0205] Statement 15. In the method of statement 10 or any statement dependent thereon, the first script includes a second scalar multiplication (MBS) script, the second MBS script comprising: obtaining a second scalar value, the second scalar value being represented in binary, each bit of the binary representation being associated with a respective index i; and multiplying each of the fifth elliptic curve points by a second scalar value to output fourth target elliptic curve points; the second MBS script includes a sequence of sub-scripts to be executed in sequence, each sub-script being associated with a respective index i, and including an instance of a point doubling script, each sub-script being configured to perform a doubling of the second MBS script; i the second MBS script is configured to generate a fourth target elliptic curve point by adding together the respective elliptic curve points belonging to the respective sub-scripts having respective indexes corresponding to the same respective indexes as the respective bits of the binary representation of the second scalar value that are set to 1.

[0206] Statement 16. In the method of any of the preceding statements, the first script determines whether each respective bit of the binary representation of the given scalar is set to 1 by: Prints the integer 1 as l byte array in big endian order, where l is the length in bytes of the scalar; l sets each bit of the byte array to 1; and Compare each bit of a scalar with each bit of l byte array; where each bit is determined to be set to 1 if the respective bit of the scalar matches the respective bit of the l byte array.

[0207] Statement 17. In the method of any preceding statement, the first script may include a modular reduced script, the modular reduced script comprising: obtaining a respective integer x and a respective modulus value p; and outputting a modular reduction of each integer by computing (x%p+p)%p; where % is the modulus operator.

[0208] Statement 18. In the method of statement 15 or any statement dependent thereon, the first script includes a commitment point, two respective instances of a second MBS script, and a respective instance of a point addition script, the first script comprising: obtaining a first candidate scalar and a second candidate scalar, the first and second candidate scalars being included in an unlock script of a second blockchain transaction; inputting the first candidate scalar into a first respective instance of a second MBS script to generate a first elliptic curve candidate point; inputting the second candidate scalars into a second respective instance of a second MBS script to generate second elliptic curve candidate points; inputting the first elliptic curve candidate point and the second elliptic curve candidate point into respective instances of a point addition script to generate a commitment candidate point; and verifying that the commitment candidate point is equal to the commitment point; The present invention is configured to:

[0209] Statement 19. In the method of statement 15 or any of the statements subordinate thereto, the first script may include a predetermined public key and a predetermined address, and the first script may include: obtaining a private key and a candidate address, the private key and the candidate address being included in an unlock script of the second blockchain transaction; inputting the private key into a second MBS to generate candidate public keys, where each fifth elliptic curve point of the second MBS is a public key generation point; verifying that the candidate public key is equal to the predetermined public key; inputting the candidate public keys and the given public key into an instance of a point addition script to generate elliptic curve candidate points; hashing the elliptic curve candidate points with one or more hash functions to generate addresses; and verifying that the candidate address matches the predetermined address or that a portion of the candidate address matches a portion of the predetermined address; The present invention is configured to:

[0210] Statement 20. 1. A computer-implemented method for performing elliptic curve arithmetic with blockchain transactions, the method being performed by a script generator, the method comprising: Obtaining a first blockchain transaction; obtaining a second blockchain transaction; and executing the first script together with the second script to generate a modular inverse of the target integer; the first blockchain transaction includes a first script, the first script includes a modular inversion script, the modular inversion script when executed by the script engine: obtaining a target integer (x) and a modulus value (p), where the target integer and the modulus value are mutually prime and the modulus value is a prime number; The components (a i ) index pair (s i ,t i ), where the reduced modulus value has a value two less than the modulus value, and the index identifies a pair of preceding components of the additive chain that, when summed, equals the component of the additive chain, the additive chain having a length l; and outputting a modular inverse (y) of the target integer, the modular inverse being generated by computing a sequence of l multiplier values ​​and, where i=l, computing the remainder of the multiplier value relative to a modulus value (p); wherein a first multiplier value in the sequence of multiplier values ​​is equal to the target integer and a second multiplier value in the sequence of multiplier values ​​is calculated, and for each component of the additive chain for 3≦i≦l, a respective multiplier value in the sequence of multiplier values ​​is iteratively calculated, each respective multiplier value being an exponentiation of the target integer (x) by a component of the additive chain, and each respective multiplier value being: Selecting from the stack a multiplier value associated with the preceding pair of components in the additive chain; multiplying the selected multiplier value to generate a multiplier value for each of the components; and It is calculated by pushing the generated multiplier value onto the stack; The remainder of the multiplier value to the modulus value (p) is output as the modular inverse (y); The second blockchain transaction includes a second script, where the second script includes a target integer (x) and a modulus value (p).

[0211] Statement 21. The computing device includes a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code configured to operate on the processing device, the code being configured, when executed on the processing device, to perform a method according to any one of statements 1 to 20.

[0212] Statement 22. The computer program is configured to, when embodied in a computer readable storage and executed by one or more processors, perform the method of any of statements 1 to 20.< / x>

Claims

1. 1. A computer-implemented method performed by a script generator for performing elliptic curve operations performed with blockchain transactions, comprising: generating a first script for a first blockchain transaction; outputting the first script for inclusion in the first blockchain transaction; The first script includes a modular inversion script that, when executed by a script engine, obtaining a target integer (x) and a modulus value (p), the target integer and the modulus value being mutually prime and the modulus value being a prime number; The components of the additive chain (a i ) index pair (s i ,t i ), where the reduced modulus value has a value two less than the modulus value, the index identifies a pair of preceding components of the additive chain that, when summed, equals a component of the additive chain, the additive chain having a length l; and obtaining a modular inverse (y) of the target integer, the modular inverse being generated by exponentiating x to the reduced modulus (p-2) using additive chaining by computing a sequence of l multiplier values ​​and computing the remainder of the multiplier values ​​relative to the modulus value (p) where i=l; wherein a first multiplier value in the sequence of multiplier values ​​is equal to a target integer and a second multiplier value in the sequence of multiplier values ​​is calculated, and for each component of the additive chain, for 3≦i≦l, a respective multiplier value in the sequence of multiplier values ​​is iteratively calculated, each respective multiplier value being the target integer (x) raised to the power of a component of the additive chain, and each respective multiplier value being: selecting the multiplier value associated with the preceding pair of components in the additive chain from a stack; multiplying the selected multiplier value to generate a multiplier value for each of said components; and by pushing a generated multiplier value onto said stack; The remainder of the multiplier value to the modulus value (p) is output as the modular inverse (y).

2. 2. The method of claim 1, wherein a second multiplier value in the sequence of multiplier values ​​is x 2 The method is calculated as mod p.

3. 2. The method of claim 1, wherein the modular inversion script is configured to calculate, for each generated multiplier value, a remainder of the multiplier value with respect to the modulus value (p).

4. 2. The method of claim 1, wherein the modular inversion script is further configured to push the modular inverse onto a main stack.

5. 2. The method of claim 1, wherein the modular inversion script is further configured to remove each multiplier value from the stack, where 1≦i≦l−1.

6. The method of claim 1 , wherein the multiplier value is pushed onto an alternative stack.

7. 2. The method of claim 1, wherein the length of the additive chain is: [0040] Limited by [0041] and hw p-2 is the Hamming weight of p-2,method.

8. 13. The method of claim 1 : Including the first script in the first blockchain transaction; and submitting the first blockchain transaction to one or more blockchain nodes and / or one or more blockchain users; The method includes:

9. 2. The method of claim 1, wherein outputting the first script comprises transmitting the first script to one or more blockchain users.

10. 2. The method of claim 1, wherein the first script comprises a point-adding script, the point-adding script comprising: obtaining a first elliptic curve point, a second elliptic curve point, and the modulus value; and performing elliptic curve addition of the first and second elliptic curve points to output a first target elliptic curve point; wherein the point addition script includes the modular inversion script, performing the elliptic curve addition includes calculating a first lambda value used to calculate respective x-coordinates and respective y-coordinates of the first target elliptic curve point, and calculating the first lambda value includes calculating a first numerator value and a first denominator value, and the point addition script is configured to cause the modular inversion script to run with the first denominator value set as the target integer to generate a modular inverse of the first denominator value, and the first lambda value is calculated by multiplying the first numerator value by the modular inverse of the first denominator value.

11. 11. The method of claim 10, wherein the point addition script includes a first branch configured to generate the first numerator value and a second numerator value if the first and second elliptic curve points are equal and a second branch configured to generate the first numerator value and the second numerator value if the first and second elliptic curve points are not equal, and the modular inversion script is executed after either the first branch or the second branch is executed, and the modular inversion script is included once as part of the point addition script.

12. 11. The method of claim 10, wherein the first script comprises a point subtraction script, the point subtraction script comprising: obtaining a third elliptic curve point, and the modulus value; and outputting the second elliptic curve point to the point addition script; wherein the second elliptic curve point is generated by computing a remainder of the elliptic curve point with the modulus value and negating the result.

13. 11. The method of claim 10, wherein the first script includes a point doubling script, the point doubling script comprising: obtaining a fourth elliptic curve point, and the modulus value; and outputting a second target elliptic curve point by doubling the fourth elliptic curve point; wherein the point doubling script includes the modular inversion script, doubling the fourth elliptic curve point includes calculating a second lambda value used to calculate respective x-coordinates and respective y-coordinates of the second target elliptic curve point, and calculating the second lambda value includes calculating a second numerator value and a second denominator value, and the point doubling script is configured to cause the modular inversion script to run with the second denominator value set as the target integer to generate a modular inverse of the second denominator value, and the lambda value is calculated by multiplying the second numerator value by the modular inverse of the second denominator value.

14. 14. The method of claim 13, wherein the first script comprises a first multiplication by scalar (MBS) script, the first MBS script comprising: obtaining a fifth elliptic curve point, a modulus value, and a first scalar value, the first scalar value being represented in binary, each bit of the binary representation being associated with a respective index; and multiplying the fifth elliptic curve point by the scalar value using a double-and-add algorithm to output a third target elliptic curve point; wherein the first MBS script comprises a sequence of sub-scripts executed in sequence, each sub-script associated with a respective index and comprising an instance of the point doubling script, a first of the sub-scripts configured to double the fifth elliptic curve point using the point doubling script and output a respective intermediate result, each of successive sub-scripts in the sequence configured to use the point doubling script to double the respective intermediate result output by a preceding sub-script in the sequence, and the first MBS script configured to generate the third target elliptic curve point by adding together respective intermediate results generated by respective sub-scripts having respective indexes corresponding to the same respective indexes as respective bits of a binary representation of the first scalar value that are set to 1.

15. 11. The method of claim 10, wherein the first script includes a second multiplication of scalar (MBS) script, the second MBS script comprising: obtaining a second scalar value, the second scalar value being represented in binary, each bit of the binary representation being associated with a respective index i; and multiplying each fifth elliptic curve point by the second scalar value to output a fourth target elliptic curve point; The second MBS script includes a sequence of sub-scripts executed in sequence, each sub-script being associated with a respective index i and including an instance of a point doubling script, each sub-script being configured to: i the second MBS script is configured to generate the fourth target elliptic curve point by adding together respective elliptic curve points belonging to respective sub-scripts having respective indices corresponding to the same respective indices as respective bits of the binary representation of the second scalar value that are set to 1.

16. 2. The method of claim 1, wherein the first script determines whether each respective bit of a binary representation of a given scalar is set to 1 by: output the integer 1 as l byte array in big endian order, where l is the length in bytes of said scalar; Setting each bit of the l byte array to 1; and comparing each bit of the scalar with each bit of the l byte array; wherein the respective bit is determined to be set to 1 if a respective bit of the scalar matches a respective bit of the l byte array.

17. 2. The method of claim 1, wherein the first script comprises a modular reduced script, the modular reduced script comprising: obtaining a respective integer x and a respective modulus value p; and outputting a modular reduction of each of said integers by computing (x%p+p)%p; where % is a modulus operator.

18. 16. The method of claim 15, wherein the first script includes a commitment point, two respective instances of a second MBS script, and a respective instance of the point addition script, the first script comprising: obtaining a first candidate scalar and a second candidate scalar, the first and second candidate scalars being included in an unlock script of a second blockchain transaction; inputting the first candidate scalar into a first respective instance of the second MBS script to generate a first elliptic curve candidate point; inputting the second candidate scalars into a second respective instance of the second MBS script to generate second elliptic curve candidate points; inputting the first elliptic curve candidate point and the second elliptic curve candidate point into respective instances of the point addition script to generate a commitment candidate point; and verifying that the commitment candidate point is equal to the commitment point; The method is configured to:

19. 16. The method of claim 15, wherein a first script includes a predetermined public key and a predetermined address, the first script comprising: obtaining a private key and a candidate address, the private key and the candidate address being included in an unlock script of a second blockchain transaction; inputting the private key into the second MBS to generate candidate public keys, wherein a fifth elliptic curve point of each of the second MBSs is a public key generation point; verifying that the candidate public key is equal to the predetermined public key; inputting the candidate public keys and the given public key into an instance of the point addition script to generate elliptic curve candidate points; hashing the elliptic curve candidate points with one or more hash functions to generate candidate addresses; and verifying that the candidate address matches the predetermined address or that a portion of the candidate address matches a portion of the predetermined address; The method is configured to:

20. 1. A computer-implemented method performed by a script generator for performing elliptic curve operations performed with blockchain transactions, comprising: obtaining a first blockchain transaction that includes a first script; Obtaining a second blockchain transaction; and executing the first script together with a second script to generate a modular inverse of a target integer; the first script comprises a modular inversion script, the modular inversion script, when executed by a script engine, obtaining a target integer (x) and a modulus value (p), the target integer and the modulus value being mutually prime and the modulus value being a prime number; The components of the additive chain (a i ) index pair (s i ,t i ), where the reduced modulus value has a value two less than the modulus value, the index identifies a pair of preceding components of the additive chain that, when summed, equals a component of the additive chain, the additive chain having a length l; and outputting a modular inverse (y) of the target integer, the modular inverse being generated by computing a sequence of l multiplier values ​​and computing the remainder of the multiplier value relative to the modulus value (p) where i=l; wherein a first multiplier value in the sequence of multiplier values ​​is equal to a target integer and a second multiplier value in the sequence of multiplier values ​​is calculated, and for each component of the additive chain, for 3≦i≦l, a respective multiplier value in the sequence of multiplier values ​​is iteratively calculated, each respective multiplier value being the target integer (x) raised to the power of a component of the additive chain, and each respective multiplier value being: selecting the multiplier value associated with the preceding pair of components in the additive chain from a stack; multiplying the selected multiplier value to generate a multiplier value for each of said components; and by pushing a generated multiplier value onto said stack; the remainder of the multiplier value to the modulus value (p) is output as the modular inverse (y); The second blockchain transaction includes a second script, the second script including the target integer (x) and a modulus value (p).

21. a memory including one or more memory units; and a processing device comprising one or more processing units; 21. A computing device comprising: said memory storing code configured to operate on said processing device, said code configured to cause said processing device to perform a method according to any one of claims 1 to 20.

22. A computer program embodied in a computer readable storage configured to cause one or more processors to carry out a method according to any one of claims 1 to 20.

Images