Non-native blockchain signatures

Abstract

A computer-implemented method for enabling a non-native blockchain signature to be verified in a script, the method being performed by a first party and comprising the steps of: obtaining a second blockchain transaction, where the second blockchain transaction references the first blockchain transaction; generating a first signature based on at least the second blockchain transaction, where a first private key used to generate the first signature is set equal to one; generating a second signature based on the first signature, where the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; including the first signature and the second signature in the unlocking script for verification when the unlocking script of the second blockchain transaction is executed together with the locking script of the first blockchain transaction; and causing the second blockchain transaction to be released to the blockchain network.

Description

[Technical field]

[0001] The present disclosure relates to methods for verifying non-native blockchain signatures within a script and methods for using non-native blockchain signatures for verification within a script. [Background technology]

[0002] Blockchain refers to a form of distributed data structure, where a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain comprises a chain of blocks of data, where each block comprises one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to a previous transaction in the sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves multiple nodes each competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved by publishing only the block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to carry digital assets (i.e., a number of digital tokens), to order a set of journal entries in a virtualized ledger or register, to receive and process timestamp entries, and / or to time-order index pointers. A blockchain may also be utilized to overlay additional functionality onto the blockchain. For example, a blockchain protocol may allow for the storage of additional user data or indexes to data in a transaction. Since there is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, increasingly complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data in the blockchain.

[0004] The nodes of a blockchain network (often called "miners") implement a decentralized transaction registration and validation process, which is described in more detail below. In summary, during this process, nodes validate transactions and insert them into a block template, and the nodes attempt to identify a valid proof-of-work solution for that block template. Once a valid solution is found, a new block is disseminated to other nodes in the network, thus allowing each node to record a new block on the blockchain. To have a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends it to one of the nodes of the network so that it can be disseminated. 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 implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated or incorporated into a block. Assuming the transaction is validated and therefore accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of invalid transactions is performed by the activities of competing nodes, who act as agents of the network and have an incentive to report and prevent fraud. Public disclosure of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every spendable output comprises an element that specifies an amount of a digital asset that is derivable from a preceding sequence of transactions. A spendable output may be referred to as a UTXO (an “unspent transaction output”). An output may further comprise a locking script that specifies a condition for further redemption of the output. A locking script is a predicate that defines the condition required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) may comprise a pointer (i.e., a reference) to such output in a preceding transaction and further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, which we call a first transaction and a second transaction (or a “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to an 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 to be disseminated and recorded in the blockchain, one validity criterion applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not disseminate the transaction (possibly registering an invalid transaction, but as a valid transaction) and will not include the transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of all accounts is stored and periodically updated by nodes, separate from the blockchain. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] D. Galindo and F. D. Garcia, "A Schnorr-Like Lightweight Identity-Based Signature Scheme", Africacrypt, Gammarth, 2009 [Non-Patent Document 2] L. Ducas, E. Klitz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler and D. Sthehle, "CRYSTALS-Dilithium: A Lattice-Based Digital", IACR Transactions on Cryptographic Hardware and Embedded Systems, 2017 [Non-Patent Document 3] T. Prest, P.-A. Fouque, J. Hoffstein, P. Kirchner, V. Lyubashevsky, T. Pornin, T. Ricosset, G. Seiler, W. Whyte and Z. Zhang, "Falcon: Fast-Fourier Lattice-based" [Non-Patent Document 4] J. Ding, M.-S. Chen, A. Petzoldt, D. Schmidt, B.-Y. Yang, M. Kannwischer and J. Patarin, "Rainbow, a New Multivariable Polynomial" [Non-Patent Document 5] D. Boneh, X. Boyen and E. Goh, "Hierarchical Identity Based Encryption with Constant Size Ciphertext", EUROCRYPT, Aahrus, 2005 [Non-Patent Document 6] ASCraig Gentry, "Hierarchical ID-based cryptography", ASIACRYPT, Queenstown, 2002 Summary of the Invention [Problem to be solved by the invention]

[0010] Digital signatures are cryptographic primitives that provide authentication and integrity of messages. They are typically computed using a private signing key and verified using a public verification key. Digital signatures are a fundamental aspect of most, if not all, blockchain protocols. They are used, among other things, to sign transactions. Most blockchain protocols have a native digital signature scheme. For example, the Bitcoin blockchain utilizes ECDSA signatures. A native signature in the context of blockchain is a signature that can be verified in a script using a dedicated verification function (e.g., opcode) to verify the signature. For example, the Bitcoin protocol uses the OP_CHECKSIG opcode or a variant thereof to verify ECDSA signatures. A native signature can also be defined as a signature that, when verified by a dedicated function, causes a dedicated function (or more precisely, a script engine) to generate a signed message based on the actual transaction data and verify the signature based on the generated message. In other words, the native signature verification function verifies the native signature by constructing a candidate message using the actual transaction data (for which the signature verification function is available) and verifying the signature based on the constructed candidate message. Native signatures provide integrity of the signed message by verifying the native signature based on a message that is constructed from the actual transaction data (i.e., the consume transaction and possibly the referenced transactions).

[0011] Although native signature schemes are fundamental to a given blockchain protocol, their functionality is limited. It is therefore desirable to be able to use other non-native signature schemes on the blockchain. However, because native signature schemes only allow a scripting engine to construct messages, the integrity of non-native signatures cannot be verified. In the context of blockchain, this means that the integrity of spending transactions that include the signature cannot be guaranteed. Thus, a challenge remains as to how to improve the functionality of blockchains by utilizing non-native signatures while still ensuring that the integrity of signed transactions continues to be guaranteed. [Means for solving the problem]

[0012] According to one aspect disclosed herein, a computer-implemented method for enabling a non-native blockchain signature to be verified in a script is provided, the method being performed by a first party and comprising: obtaining a second blockchain transaction, where the second blockchain transaction references the first blockchain transaction; generating a first signature based on at least the second blockchain transaction, where a first private key used to generate the first signature is set equal to one; generating a second signature based on the first signature, where the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; including the first signature and the second signature in an unlocking script for verification when an unlocking script of the second blockchain transaction is executed together with a locking script of the first blockchain transaction; and causing the second blockchain transaction to be released to a blockchain network.

[0013] A first party obtains (e.g., generates or receives) a second transaction. The second transaction has an input that references the first transaction, i.e., an unspent transaction output of the first transaction. The first party signs a message based on the second transaction to generate a first signature. The first signature is a signature native to the blockchain, e.g., an ECDSA signature. The private key used to generate the first signature is set to 1, i.e., the private key is equal to the number 1, which means that its generation and verification are very computationally efficient.

[0014] The first party then signs the message based on the first signature to generate a second signature. The second signature is not native to the blockchain. For example, if the first signature is an ECDSA signature, the second signature is not an ECDSA signature. The signature scheme of the second signature can be arbitrary. The first party includes both the first and second signatures in an unlocking script of the input of the second transaction. When the unlocking script is executed, the first signature is verified, and therefore the integrity of the second transaction is guaranteed. The second signature provides the benefits of whichever scheme is chosen. In general, the second signature scheme can provide authenticity of the message being signed. Thus, the combination of the first and second signatures provides both authenticity and integrity of the second transaction.

[0015] According to one aspect disclosed herein, a computer-implemented method of verifying a non-native blockchain signature in a script is provided, the method comprising: generating a first blockchain transaction performed by a second party and comprising a locking script, the locking script comprising a first verification script and a second verification script, wherein when the locking script of the first blockchain transaction is executed together with an unlocking script of the second blockchain transaction, the first verification script is configured to verify the first signature based on a first public key corresponding to a first private key set equal to one, and the second verification script is configured to verify the second signature, wherein the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; and causing the first blockchain transaction to be submitted to a blockchain network.

[0016] The second party verifies the first transaction. The first transaction has an output that includes a locking script. The locking script includes two verification scripts. The first verification script is configured to, when executed, cause the script engine to verify a native signature, e.g., an ECDSA signature. This verification involves the script engine constructing a candidate version of the signed message (i.e., a message based on at least the second transaction) and validating the first signature based on the candidate message and a public key. The public key corresponds to the number 1. The second verification script is configured to verify the non-native signature. When the second verification script is executed, the script engine does not construct a candidate message based on the second transaction. If the script execution passes, the integrity of the second transaction is verified (by a valid native signature), as in the case of a non-native signature.

[0017] In some embodiments, the non-native signature can be an identity-based signature. An identity-based signature (IBS) is a type of digital signature that eliminates the need for a public verification key. Instead, only the identity of the signer (along with the message and any public parameters) is required for signature verification. These embodiments allow the integrity of the second transaction to be guaranteed, and also provide authenticity of the transaction since the second non-native signature is bound to the identity of the first party.

[0018] In general, any non-native signature scheme may be used, thus improving the blockchain by taking advantage of the advantages associated with a particular signature scheme.

[0019] To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be embodied, reference will be made, by way of example only, to the accompanying drawings in which: [Brief description of the drawings]

[0020] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 1 is a schematic block diagram of a system for performing verification of non-native blockchain signatures. [Figure 4A] FIG. 2 illustrates generally the use of dummy signatures to generate and verify identity-based signatures. [Figure 4B] FIG. 2 illustrates generally the use of dummy signatures to generate and verify identity-based signatures. [Figure 5A] FIG. 2 illustrates a schematic diagram of using a dummy signature to generate and verify a general signature. [Figure 5B] FIG. 2 illustrates a schematic diagram of using a dummy signature to generate and verify a general signature. [Figure 6] FIG. 1 illustrates a schematic diagram of using identity-based signatures to revoke on-chain certificates. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] 1. Exemplary System Overview 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 arranged 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 the other blockchain nodes 104.

[0022] Each blockchain node 104 comprises a peer computer device, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing device comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. The memory may comprise one or more memory units utilizing one or more memory media, for example, 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.

[0023] The blockchain 150 comprises a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of a number of blockchain nodes 104 in a distributed network 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. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing some quantity of digital assets as assets, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and redeem or spend). Each input points to the output of a preceding transaction 152, thereby linking those transactions together.

[0024] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes 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, not to a preceding transaction.

[0025] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its respective 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 "memory pool." This term in this specification 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 not obligated to accept other transactions that attempt to consume the same output.

[0026] In a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, which specifies that this output is to be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consumption may be described as spending an output or allocating an output to one or more outputs in another forward transaction. In general, a preceding transaction may be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152i is created or even sent to the network 106, but a preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to preceding in logical order linked by pointers, and not necessarily to time of creation or transmission in chronological order, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may also be referred to as an ancestor transaction or a predecessor transaction.

[0027] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the amount of the input among multiple users or entities (one of which can be the original user or entity 103a to give the remaining amount). In some cases, the transaction can also have multiple inputs to collect together amounts from multiple outputs of one or more preceding transactions and redistribute one or more outputs of the current transaction.

[0028] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to define a new transaction 152j (either manually or by an automated process used by the party), the defining party transmits the new transaction from his computer terminal 102 to a recipient. The defining party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are usually servers or data centers, but in principle could be other user terminals). It is not excluded that the party 103 defining the new transaction 152j can transmit the transaction directly to one or more of the blockchain nodes 104 and in some instances not to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that a cryptographic signature or other authorization of a participant 103 included in the input of the new transaction 152j matches a condition defined in the output of a preceding transaction 152i that the new transaction consumes (or "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of a previous transaction 152i that is connected to the input of the new transaction. 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 by the blockchain node protocol alone, or it may be by a combination of these. In either 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 forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0029] In an output-based model, the definition of whether a given output (e.g., UXTO) is allocated (e.g., spent) is whether it has already been 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 preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if not valid, the transaction 152j is not disseminated (unless it is flagged as invalid and disseminated for a warning) or recorded in the blockchain 150. This prevents double spending, such as when a transactor attempts to allocate the output of the same transaction more than once. On the other hand, an 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 given time.

[0030] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, aided by "proof of work", in a process commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The 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 comprises looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool 154 of outstanding transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain number of leading zeros. Note that this is just one specific type of proof of work puzzle, other types are not excluded. The nature of a hash function is that it has an unpredictable output with respect to its input. This search therefore consumes a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle, as it can only be performed by brute force.

[0031] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof that can be easily verified later by other blockchain nodes 104 in the network (given the solution to the hash, it is simple to verify that the output of the hash thereby satisfies the conditions). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and therefore enforce the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. This large amount of effort, e.g. in the form of a hash, required to create the proof-of-work solution is indicative of the first node's 104 intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (otherwise known as double-spend). Once created, blocks 151 cannot be altered because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in blocks that are ordered at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0032] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be competing to solve the puzzle based on different snapshots of the pool of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may arise, which are situations in which two blockchain nodes 104 solve a puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. That is, whichever tip of the fork has grown longer will be the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0033] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an additional acceptable amount of digital assets in a new special type of transaction (rather than an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional defined amount of digital assets. This special type of transaction is usually called a "coinbase transaction", but may also be called an "initiation transaction" or "generation transaction". It usually forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow the protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is discussed below.

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

[0035] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 according to the blockchain node protocol. It will be understood that any activity attributable to this specification for the blockchain node 104 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, or at a lower layer such as the operating system layer or protocol layer, or any combination thereof.

[0036] Also connected to the network 101 are computer devices 102 of each of a number of participants 103 acting 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 or recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0037] Some or all of the participants 103 may be connected as part of a different network, for example a network superimposed on the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system including the blockchain network 106. However, these users are not blockchain nodes 104, as they do not perform the role required of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150, by connecting to (i.e., communicating with) the blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but for convenience they are not shown. Each participant 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 to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0038] The computing device 102 of each participant 103 comprises a respective processing device comprising 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 participant 103 further comprises a memory in the form of a non-transitory computer readable medium, i.e. computer readable storage. This memory may comprise one or more memory units utilizing one or more memory media, e.g. magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 arranged to execute on the processing device. It will be understood that any activity attributable to this specification for a given participant 103 may be implemented using software executed on the processing device of the respective computing device 102. The computing device 102 of each participant 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given participant 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0039] The client application 105 may initially be provided to the computing equipment 102 of any given participant 103 on a suitable computer-readable storage medium, for example downloaded from a server, or may be 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.

[0040] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, approve (e.g. sign) and send transactions 152 to one or more Bitcoin nodes 104 so that they can be disseminated across the network of blockchain nodes 104 and included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered across the blockchain 150 that belong to the party in question.

[0041] NOTE: Although various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example interfacing via an API or one plugging into 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. The following is described with respect to client application 105, but it will be understood that this is not limiting.

[0042] 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 function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or in an embodiment, actually investigate other parties' transactions in the blockchain 150, since the blockchain 150 is a public entity that provides credit for transactions in part due to public visibility). The wallet function of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As mentioned above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward them to disseminate the transactions 152 throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol, and together implement a given transaction model. 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.

[0043] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then transmits the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may 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, the blockchain node 104 handles the new transaction 152j according to the blockchain node protocol and its respective role. This comprises first verifying whether the newly received transaction 152j satisfies some condition for being "valid", an example of which will be discussed in more detail shortly. In some transaction protocols, the condition for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0044] Provided that the newly received transaction 152j passes the test to be considered as valid (i.e., it is "validated"), every blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of transactions maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j disseminates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be disseminated throughout the network 106.

[0045] Once granted access to the ordered pool 154 of outstanding transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the 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 be trying to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 solves 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 immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0046] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views of which instance is "valid" before an 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 an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it accepts it and discards (i.e., treats as invalid) the instance it first accepted (i.e., the instance not published in block 151).

[0047] An alternative 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 defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored and periodically updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0048] 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 a basic data structure of the blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. Note that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it may also be implemented on other exemplary blockchain networks.

[0049] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO comprises a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also comprise, among other information, a transaction ID for the transaction from which the UTXO originates. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes 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 (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 issued to the node 104.

[0050] Suppose Alice 103a wants to create a transaction 152j that transfers a target amount of digital assets to Bob 103b. In Figure 2, Alice’s new transaction 152j is written as “Tx 1 " It will be named. Tx 1takes the amount of digital assets locked in Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is denoted in FIG. 2 as “Tx 0 " It will be named. Tx 0 and Tx 1 are just arbitrary names. They are 0 does not necessarily mean that this is the first transaction on blockchain 151, 1 It does not mean that Tx is the next transaction in the pool 154. 1 may point to any preceding (i.e., ancestor) transaction that still has unconsumed outputs 203 locked to Alice.

[0051] Preceding transaction Tx 0 Alice creates a new transaction Tx 1 When Tx is created, or at least when she sends it to the network 106, it may already have been validated and included in a block 151 of the blockchain 150. It may already have been included in one of the blocks 151 at that point, or it may still be waiting in the ordered set 154, in which case it will be included in a new block 151 shortly. Alternatively, Tx 0 and Tx 1 , may be compiled together and sent to the network 106, or, if the node protocol allows for buffering of "orphan" transactions, Tx 0 Tx 1The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence as defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may be equally replaced by "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") is not 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. It may be discarded or buffered for some time to wait for the parent, depending on the node protocol and / or node behavior.

[0052] Preceding transaction Tx 0 One of the one or more outputs 203 of 0 Each UTXO comprises a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and thus for the redemption of the UTXO to be successful. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines the unlocking conditions, which typically comprise a condition that the unlocking script in the input of the subsequent transaction comprises a cryptographic signature of the party to which the preceding transaction is locked.

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

[0054] Thus, in the example shown, Tx 0 UTXO in output 203 0 UXTO 0 To be able to redeem (strictly speaking, UTXO 0 For any subsequent transaction attempting to redeem the token to be valid, Alice's signature Sig P A Locking script that requires [Checksig P A ]. [Checksig P A ] is the public key P from Alice’s public-private key pair. A Contains a representation (i.e., a hash) of Tx 1 The input 202 of the Tx 1 (For example, its transaction ID, TxID 0 Pointed to by TxID 0 In the embodiment, the whole transaction Tx 0 A pointer to the Tx 1 The input 202 of the Tx 0 UTXO from all other possible outputs of 0 To identify the Tx 0 UTXO within 0It has an index that identifies the Tx 1 The input 202 further includes an unlocking script that comprises Alice's cryptographic signature, which is created by Alice applying her private key from the key pair to a predetermined 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 may be defined by the locking script, or by the node protocol, or by a combination of these.

[0055] New transaction Tx 1 When the arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script meets the conditions defined in the locking script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] Here, "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" are functions to be included in the locking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. Either way, when executed together, the scripts will be executed in the order Tx 0 Alice's public key P, as included in the locking script in the output of A Using Tx 1 The input of Tx authenticates that the unlocking script contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data is 1(Thus, there is no need to include a separate element that specifies the signed portion of the data in plaintext, since it is already there).

[0056] The details of public-private cryptographic authentication are familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as the signature onto the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or transaction, etc., may in embodiments mean signing a hash of that piece of data or transaction.

[0057] Tx 1 The unlocking script in Tx 0 If one or more conditions specified in the locking script of 1 If provided and authenticated in Tx 1 This means that the blockchain node 104 considers Tx 1 The blockchain node 104 also notifies one or more other blockchain nodes 104 in the network 106 of the transaction Tx 1 , so that it is disseminated throughout the network 106. 1 Once validated and included in the blockchain 150, it is consumed as Tx 0 UTXO from 0 Define Tx 1Note that Tx can only be valid when consuming an unconsumed transaction output 203. If an attempt is made to consume an output that has already been consumed by another transaction 152, then Tx 1 is invalid even if all other conditions are met. Therefore, the blockchain node 104 0 It is also necessary to ascertain whether a referenced UTXO in has already been spent (i.e., has already formed valid inputs into another valid transaction). This is one reason why it is important for the blockchain 150 to impose a prescribed ordering on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately what defines whether a UTXO is spent is whether the UTXO has already formed valid inputs into another valid transaction in the blockchain 150.

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

[0059] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" part of the amount defined in the UTXO as being spent while another part is being spent. However, the amount from the UTXO can be split among multiple outputs of subsequent transactions. For example, Tx 0 UTXO in 0 The amount defined in is Tx 1 Therefore, if Alice receives a UTXO 0If she does not want to give Bob the full amount defined in Tx 1 The remainder of the second output can be given to yourself or paid to another party.

[0060] In practice, Alice should normally also include a fee for any Bitcoin nodes 104 that succeed in including her transaction 104 in block 151. If Alice does not include such a fee, Tx 0 may be rejected by a blockchain node 104 and therefore not disseminated and included in the blockchain 150, even if technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to do so). In some protocols, transaction fees do not require a unique separate output 203 (i.e., do not require a separate UTXO). Instead, any difference between the total amount pointed to 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, a UTXO 0 A pointer to Tx 1 is the only input to the Tx 1 is the only output UTXO 1 Let us assume that we have UTXO. 0 The amount of digital assets specified in 1 If the difference is greater than the amount specified in 1 However, it is not necessarily precluded that a transaction fee may alternatively or additionally be explicitly specified in its own one of the UTXOs 203 of transaction 152.

[0061] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, the assets of a given party 103 are spread across the UTXOs of various transactions 152 across the blockchain 150. There is no one number stored anywhere on the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function of the client application 150 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, further transaction. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0062] Note that script code is often expressed generally (i.e., without using a strict language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to 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, produces a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0063] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and some or all of the transaction outputs. The specific parts of the outputs to sign depend on the SIGHASH flag, which is normally a 4-byte code included at the end of the signature (and thus fixed at the time of signing) to select which outputs are signed.

[0064] A locking script is sometimes referred to as a "scriptPubKey", referring to the fact that the locking script typically comprises the public key of the party for which the respective transaction is locked. An unlocking script is sometimes referred to as a "scriptSig", referring to the fact that the unlocking script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for allowing a UTXO to be redeemed comprises authenticating a signature. More generally, a scripting language may be used to define any condition or conditions. Thus, the more general terms "locking script" and "unlocking script" are sometimes preferred.

[0065] 3. Side Channels As shown in FIG. 1, each of the client applications on each of Alice's computing device 102a and Bob's computing device 120b may each include additional communication capabilities. This additional functionality allows Alice 103a to establish (at the urging 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 apart from the blockchain network. Such communication may be 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 (yet) in the blockchain network 106 or reaching the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way may be 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, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0066] 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 107 may be established over a different network, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referred to anywhere herein may comprise any one or more links over one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links may be referred to as the side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data, etc., over the side channel 107, this does not necessarily imply that all such data must be transmitted over exactly the same links, or even over the same type of network.

[0067] 4. Cryptographic Primitives 4.1 Elliptic Curves In general, the embodiments described herein may use any suitable elliptic curve. For example, the embodiments may be a prime field,

[0068]

number

[0069] Across y 2 =x 3 +ax+b mod p Using an elliptic curve (EC) of the form Δ:=-16(4a 3 +27b 2) ≠ 0 mod p. An example of such a curve is secp256k1, used in Bitcoin. The degree of this curve is denoted by n.

[0070] A point P on an elliptic curve

[0071]

number

[0072] Multiplication of is expressed as a·P, which is a P = P + P + … P where + is elliptic curve addition. Note that from now on, the mod n notation will be omitted and all arithmetic operations on integers will be assumed to be done modulo n.

[0073] 4.2 Digital Signatures In a digital signature environment, each party has a unique private signing key that is used for signing and a corresponding public verification key that is used for signature verification. Digital signature schemes include four polynomial-time algorithms: Setup

[0074]

number

[0075] : Security parameters

[0076]

number

[0077] Generates a global parameter param for KeyGen(param): Generate a private key sk. A public verification key vk is derived from the private key and published to all parties. Sign(m,sk;r) Sign the message m using the private signing key sk and the randomness r to obtain a signature σ. Verify(m,σ,vk) It outputs 1 if the signature σ is a valid signature on the message m, meaning that it was computed using the private key corresponding to the public key vk, otherwise it outputs 0.

[0078] The running time of an algorithm is bounded by a polynomial on the size of the input to the algorithm (T(n)=O(n)). k ), the algorithm is said to be polynomial-time, which is often a necessary condition for practical algorithm implementation.

[0079] 4.3 Public Key Infrastructure Public key cryptography (PKC) often allows secret sharing in a symmetric key environment. However, the problem remains how to ensure that the public key of a party, say Alice 103a, really belongs to Alice. If that public key is inadvertently corrupted, or if some malicious party is able to replace Alice's public key with their own, that party would be able to decrypt all messages addressed to Alice. If the malicious party then encodes messages with Alice's real public key, she would never notice anything wrong. The malicious party can be passive and only read the messages, or they can completely or partially change them. This attack is called a man-in-the-middle attack. There is no easy way for other parties to distinguish between Alice's real key and the malicious party's key. In general, Alice's public key PKC is Alice is at least 256 bits of a random-looking string. For 128-bit AES security, the public key size is 256 bits for schemes based on elliptic curves and 3072 bits for RSA schemes (signing or encryption). Other schemes may use keys of different sizes.

[0080] To address this problem, a public key infrastructure (PKI) is often used. A digital certificate consisting of Alice's public key and a message containing her identifier is created by a certification authority (CA). It is then hashed and signed by the CA. A certification authority is a trusted third party whose public key is known and fully trusted by all parties. Therefore, any party can easily verify that the certificate is actually signed by the CA. The CA is responsible for ensuring that Alice's public key actually belongs to Alice. If Alice can prove, using a certificate from a known CA, that her public key belongs to her, she can then issue certificates to others as well as receive messages encrypted using her public key. Browsers have certificates for many CAs pre-installed. Any of these certificates act as a basis of trust for any https server. If the certificate offered by the server does not have a valid basis of trust for a CA, the browser will warn the user that it cannot verify that the certificate belongs to the https server they are visiting.

[0081] A known standard for certificates is called x.509. It is Certificate version Validity period (start and end times of validity period) Certificate issuer Public key type, length and value Usage (can the certificate be used to sign other certificates?) Hash types and values ​​etc. ·subject Contains fields for.

[0082] Suppose Alice's private key is compromised during its validity period. The CA needs to warn other users not to use the corresponding public key. One way is to have a Certificate Revocation List. This is a blacklist of all revoked certificates maintained by the CA. In practice, an authentication protocol may involve many authentication entities: Registration Authorities, Revocation Authorities, Root Certificate Authorities, Certificate Authorities. Every entity has a designated role. The complexity of this architecture leads to many security breaches. It is preferable to avoid this architecture, which can be achieved using Identity Based Cryptography.

[0083] 4.4 Identity-Based Signatures An identity-based signature is a digital signature that requires only the message, the identity, and some public information to verify the validity of the signature. This contrasts with standard digital signatures, where each signer requires an additional personal public verification key. The original purpose of identity-based mechanisms is to eliminate the need for a CA without being vulnerable to attacks such as man-in-the-middle attacks.

[0084] In identity-based encryption, an identity can be any string of bits. The original idea of ​​replacing PKI with identity-based encryption was to identify every user with a unique string of bits. Good examples of identities are email addresses, phone numbers, or social security numbers. The latter are not very useful as everyday identities and often reveal personal information, but can be useful for state identification of individuals, e.g. for tax and social security purposes.

[0085] Identity-Based Encryption is very flexible about what the identity can be, and as a result has many indirect applications, including oblivious transfer, blind IBE, IBE from hierarchical IBE, wicked IBS (and IBE), wildcarded IBS (and IBE), attribute-based encryption, etc.

[0086] There are multiple ways to achieve identity-based signatures. For example, one such scheme is called Hierarchical Identity-based Encryption (HIBE). This technique has the advantage of providing security proofs in standard models, particularly using the BBG construction. The main drawback of using HIBE is the use of bilinear maps, which are powerful computational mechanisms but are also computationally intensive. Most schemes utilize bilinear maps, which are heavy computational functions. An alternative scheme that may be used in some embodiments is described in D. Galindo and FD Garcia, "A Schnorr-Like Lightweight Identity-Based Signature Scheme," Africacrypt, Gammarth, 2009. This construction avoids the use of bilinear maps, is based on double Schnorr signatures, and is secure in the random oracle model.

[0087] 4.5 Key Escrow IBS algorithms typically involve a private key being calculated by a trusted third party, the Private Key Generator (PKG), based on a master private key msk. The private key (also called the user private key) is then given to the user. There is no guarantee that the PKG will not use the private key later. It is also possible for the PKG to arbitrarily recreate the private key. If the msk used to create the private key of a participant is compromised, a thief can create a new key, even for an identity that already holds a user private key. This omnipotent entity is known as a key escrow. Even when the PKG is trusted, it is a single point of failure from the attacker's point of view. It is worth noting that key escrow is sometimes considered a feature for governments or law enforcement agencies, as it provides a means for them to obtain the criminals' secrets.

[0088] Still, there remains a significant challenge to be able to create encryption or signing algorithms that prevent this key escrow. There have been several attempts to prevent this, for example by using several separate PKGs or by involving the user in the key generation. The former is vulnerable to PKG collusion, while the latter leads to a situation where further information is needed to allow verification (or encryption in IBE) of each user identity. Thus, the latter approach is no longer identity-based, and that further information is effectively a public key. As mentioned, identity-based encryption means that the identity and public parameters are sufficient to encrypt a message. Adding extra stuff for each identity is neither a public parameter nor part of the identity. Thus, this scheme is not identity-based.

[0089] However, key escrow can be avoided in a practical way by using a Hardware Security Module (HSM) that stores the master private key in such a way that an outsider cannot affect the key or any of the computations. The HSM then generates user private keys in an isolated environment.

[0090] 5. Verifying Non-native Signatures The embodiments of the present disclosure relate to verifying non-native blockchain signatures. A native signature is a signature used to sign a transaction according to a blockchain protocol. For example, in Bitcoin, the native signature scheme is the Elliptic Curve Digital Signature Algorithm (ECDSA). A native signature ensures the integrity of the signed transaction because when the blockchain scripting engine validates a signature, it constructs a message based on the consuming transaction (and possibly the consumed transaction) and verifies that the signature is a valid signature on the constructed message. Most blockchain protocols have a dedicated function (e.g., an opcode) to verify a native signature.

[0091] Non-native signature schemes contrast with native signature schemes in that a valid transaction requires a non-native signature. Similarly, validating a non-native signature does not force the script engine to construct a candidate message based on consumed data and then validate the non-native signature based on the constructed message.

[0092] FIG. 3 illustrates an exemplary system 300 for verifying using a non-native signature. The system 300 includes a first party (Alice 103a), a second party (Bob 103b), and one or more nodes 104 of a blockchain network 106. In some embodiments, the system 300 also includes a key generator 301. Note that for convenience only, the first and second parties are referred to as Alice 103a and Bob 103b, respectively. More generally, the first party may be configured to perform some or all of the activities described with respect to FIGS. 1 and 2 as being performed by Alice 103a and / or Bob 103b. Similarly, the second party may be configured to perform some or all of the activities described with respect to FIGS. 1 and 2 as being performed by Alice 103a and / or Bob 103b.

[0093] Bob 103b is configured to generate a first transaction having an output (and associated locking script) that requires two signatures to be unlocked. The first of those signatures must be of a signature scheme native to the blockchain, e.g., ECDSA for Bitcoin. The first signature scheme may use a private key and a public key, where the private key is an integer and the public key is an elliptic curve point. Other blockchains may have different native signature schemes. The native signature ensures the integrity of the signed message, which is based on at least a second transaction that consumes (allocates) the output of the first transaction. The locking script comprises a first verification script configured to verify the native signature. When the scripting engine (e.g., operated by node 104) executes the first verification script, it is configured to build a message candidate based on at least the second transaction and verify that the native signature is valid for the candidate and the public key. The public key corresponds to a private key set to the number 1. Thus, the native signature is required to have been generated with a private key set equal to the number 1. The public key may be included as part of the first verification script. Alternatively, the public key may be included in the unlocking script of the second transaction. In an example where the native signature is ECDSA, the first verification script is configured to verify the ECDSA signature. For example, the first verification script may comprise at least one of an OP_CHECKSIG opcode, an OP_CHECKSIGVERIFY opcode, an OP_CHECKMULTISIG opcode, and an OP_CHECKMULTISIGVERIFY opcode.

[0094] The second signature belongs to a different, non-native signature scheme. In general, the second signature may belong to any signature that can be verified in the script. The second signature scheme may use integers for the private key and elliptic curve points for the public key. Alternatively, the private and public keys may take different forms. The second verification script is configured to verify the second signature based on the first signature or on the message comprising the first signature. More precisely, the script engine is configured to verify, when executing the second verification script, that the second signature is a valid signature for the message based on the first signature.

[0095] Bob 103b is configured to cause a first transaction to be submitted to the blockchain network 106. For example, Bob 103b may submit a first transaction to the blockchain network 106. Bob 103b may additionally send the first transaction to Alice 103a.

[0096] Now referring to Alice 103a, Alice 103a is configured to obtain (e.g., generate or receive) a second transaction having an input that references an output of the first transaction. Alice 103a generates a native signature based on the second transaction (and in some examples, the first transaction). The private key used to generate the native signature is set equal to 1, making the generation and verification of the native signature computationally efficient. This private key is also referred to herein as the "first private key." In some examples, such as when the signature is an ECDSA signature, the ephemeral key used to generate the native signature is also set equal to 1. Alice 103a then generates a second signature, and the signed message is based on the first signature. The first signature and the second signature are included in an unlocking script of an input of the second transaction. Alice 103a then submits the second transaction to the blockchain network 106 or to a different entity (e.g., Bob 103b) for submission to the blockchain network 106.

[0097] In some examples, the second signature scheme is an identity-based signature scheme. Any suitable identity-based signature scheme may be used. In these examples, the second verification script is configured to verify that the second signature is a valid identity-based signature.

[0098] As part of the identity-based signature scheme, Alice 103a may have an identifier. Alice's identifier may include one or more of her name, address, date of birth, email address, username, passport number, driver's license number, national insurance number, etc. Alice 103a also has a user private key. The user private key is generated based on Alice's identifier. The user private key is also referred to herein as a "second private key." In some examples, Alice 103a generates her unique user private key. In other examples, Alice's user private key is generated by the key generator 301. For example, Alice's user private key may be generated based on a master private key known only to the key generator 301. Alice 103a may also have control over the master private key used to generate her user private key. In some examples, Alice 103a also has a user public key. The user public key may comprise one or more public parameters of the signature scheme, for example as described in Section 6.1.

[0099] Alice 103a may be configured to generate an identity-based signature based on the first signature, her identifier, and her user private key. In some examples, the identity-based signature is also based on her user public key. The second verification script may be configured to verify the identity-based signature based on Alice's identifier and the first signature. In some examples, the user public key may also be required to verify the identity-based signature. At least one of the identifier and the user public key may be included in the locking script of the first transaction. Similarly, at least one of the identifier and the user public key may be included in the unlocking script of the second transaction. When the identifier is included in the unlocking script of the second transaction, the second verification script may be configured to verify that the identifier is included in the unlocking script, for example, by hashing the identifier and verifying that it matches the hash of the identifier in the second verification script.

[0100] As mentioned, the user public key comprises one or more public parameters. The parameters include a prime number (p), an elliptic curve point generator (P) of the degree of the prime number, a first hash function (H 1 ), the second hash function (H 2 ). The user public key may comprise one or more additional parameters. The user private key may be generated by computing a first random value (r) and then computing a first elliptic curve point using the first random value and a generator, e.g., R=r·P. The first elliptic curve point is a first value of the user private key. A second value of the user private key is then generated based on a first hash generated by hashing the first elliptic curve point, the master private key (z), the first value of the user private key and a first identifier (id) with a first hash function, e.g., y=r+z×H. 1 (R||id) mod p. Then, the user private key is usk id =(y,R). Note that "first", "second", etc. are used as names only and do not necessarily imply an order. As discussed, the user private keys may be generated by Alice 103a or by the key generator 301, depending on who controls the master private key.

[0101] An identity-based signature may comprise three values ​​called signature values: A first signature value may be calculated based on a second random value (a) and a generator, e.g., A=a·P. A second signature value may be calculated based on the second random value, a first value of the user private key, and a second hash by hashing the first identifier, the first signature value, and the first signature (m), e.g., b=a+y×H. 2 (id||A||m). The third signature value is equal to the first value of the user private key. Then the identity-based signature is of the form σ=(A,b,R).

[0102] The second verification script may be configured to verify the identity-based signature by calculating a first verification value and a second verification value, each based on the identity-based signature, and determining whether the values ​​are equal. The first verification value is a function of the first signature value (σ 1 ), the first hash (c), and the second hash (d). The first hash is calculated based on the third signature value (σ 3 ) and the first identifier with a first hash function, e.g., c=H 1 (σ 3 The second hash is computed by hashing the first identifier, the first signature value, and the first signature with a second hash function, e.g., d=H 2 (id||σ 1 A second verification value is calculated based on the second signature value and the generator, e.g., σ 2 · P. Then, the first signature value is σ 1 +d (σ 3 + c z).

[0103] In some examples, the locking script of a first transaction may require that the unlocking script of a second transaction include multiple identity-based signatures, each generated by a different party based on a different identifier and user private key. This allows for multi-signature outputs, as discussed below in Section 6.4. More generally, the locking script of a first transaction may require that the unlocking script of a second transaction include multiple second signatures, each generated by a different party.

[0104] The second signature may be a signature of a signature scheme other than identity-based signatures. For example, the second signature may be a Schnorr signature or a Rabin signature. Those skilled in the art will be familiar with how to generate and verify Schnorr and Rabin signatures. Exemplary algorithms for such generation and verification are given below in Section 6.3. As another example, the second signature may be a quantum-resistant signature. Any suitable quantum-resistant signature may be used, including one of the examples given below in Section 6.3.1.

[0105] 6. Exemplary Implementations This section describes how Identity-Based Signatures (IBS) can be used on a blockchain, such as the Bitcoin blockchain, to achieve several features that are difficult to build without IBS, namely: Identity-Based Transactions: Eliminating the need for PKI in Bitcoin and enabling "Pay to Identity" transactions · Delegation of rights: Ability to delegate the right to unlock outputs even after they have been published Dynamic multisig: A multisig that allows new signers to be added after the script is created. A multisig is a locking script that can be unlocked by providing n signatures (which can be n out of m) that correspond to the public keys listed in the locking script.

[0106] The following protocol is based on the Galindo-Garcia Schnorr-like IBS because it can be verified in script, avoiding the use of bilinear maps. Moreover, this scheme can implicitly authenticate users using ECDSA private keys.

[0107] In some use cases, a trusted entity called a Private Key Generator (PKG) is required to create private keys for any user. This brings key escrow inherent to identity-based encryption. Key escrow is problematic when the main requirement of the application is to avoid PKI. It is possible to address this issue by splitting the key escrow entity into multiple entities and have threshold key creation. This technique remains secure if these entities do not collude. Alternatively, key generation can be done inside the HSM, making this entity autonomous and therefore immune to external influences.

[0108] To secure IBS without changing the Bitcoin protocol, embodiments utilize so-called "dummy signatures". This method can be generalized to allow any signature to be securely verified within a script, including Rabin signatures, Schnorr signatures, and quantum-resistant signatures, leading to quantum-resistant transactions.

[0109] IBS is a signature scheme consisting of four algorithms. Setup is a security parameter

[0110]

number

[0111] as input. It returns a master private key, msk, and a master public key, mpk. msk is a strong secret that key escrow can hold. mpk is a set of public parameters. KeyGen takes as input the mpk, msk, and an identity id. It generates the user private key usk id Returns Sign is a message that contains an identity id, a message m, a user private key usk, and id as input. It returns a signature σ on the message m. Verify takes in as inputs mpk, m, id, and σ. If the signature is valid (on m and by id), it returns 1. If the signature is not valid, it returns 0.

[0112] One scheme that can be used to instantiate IBS directly into Bitcoin script is described by Galindo et al. Most other IBS schemes in the literature also work, but do not achieve the same efficiency when implemented within scripts. This is due to the computation of a function called pairing that is absent from Galindo's scheme.

[0113] 6.1 Schnorr-like IBS scheme This section describes Galindo's scheme in the context of elliptic curves, where the scheme is explained using additional notation. -Setup

[0114]

number

[0115] :Security parameters

[0116]

number

[0117] as input and select a corresponding point generator P of group G and prime order p. Two different hash functions

[0118]

number

[0119] ,

[0120]

number

[0121] The hash functions are different to achieve unforgeable security in the random oracle model.

[0122]

number

[0123] Randomly select and calculate Z = z P. msk = z and mpk = (G, P, p, Z, H 1 ,H 2 ). Returns the master private key and master public key: (msk,mpk). -KeyGen(mpk,msk,id):Random

[0124]

number

[0125] Select R=r·p. Calculate y=r+z×H 1 Calculate (R||id) mod p. id Return (y,R). Note that R is not secret and is given inside any signature from this user. -Sign(id,m,usk id ,mpk): Random

[0126]

number

[0127] Choose A=a·P. Calculate b=a+y×H 2 Calculate (id||A||m). Return σ = (A,b,R). -Verify(mpk,m,id,σ):σ(σ 1 ,σ 2 ,σ 3 ) is analyzed as σ 2 P=σ 1 +d (σ3 +c·z), and d=H 2 (id||σ 1 ||m), and c=H 1 (σ 3 ||id). If this expression is true, return 1. Otherwise, return 0.

[0128] In identity-based schemes, the public parameters are usually generated randomly, while the user's private key is derived from the public key. In classical public key schemes, it is the other way around: the private key is first generated and then the public key is derived from it.

[0129] This scheme is computationally very efficient compared to other IBSs because there is no bilinear map to compute. It also allows signature verification to be done efficiently within the script.

[0130] This identity-based signature scheme is proven secure in the random oracle model (ROM) under the discrete logarithm problem (DLP).

[0131] One advantage of choosing this IBS is that it can be efficiently verified within the script compared to pairing-based IBS instantiations. Table 1 shows the cost of verifying the IBS with respect to script size.

[0132] [Table 1]

[0133] 6.2 Dummy Signatures In Bitcoin, digital signatures that are not verified by OP_CHECKSIG cannot directly provide the integrity of transaction data, especially the output. This is the case for the IBS described earlier. To remedy this issue, so-called dummy signatures are introduced to increase the security of IBS in Bitcoin transactions. This technique can be generalized to any other type of digital signatures and other blockchains, not only to Bitcoin.

[0134] 6.2.1 How to sign a script using IBS The opcode OP_CHECKSIG forces the script validation engine to see almost the entire transaction. It is the only opcode (and a few other related opcodes, including OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY) that fetches data from the consuming transaction. This ensures the integrity of the transaction data and therefore that the signature cannot be replayed in different transactions. For example, the pay to public key hash (P2PKH) locking script specifies that the next unlocking script must include a signature of the transaction. The opcode OP_CHECKSIG in P2PKH verifies the signature using a public key, which when hashed is a value specified in the locking script. Messages that are signed include (but are not limited to) the transaction version (for SIGHASH_ALL), the inputs, and outputs of the consuming transaction. This ensures that replay attacks are not possible since signatures cannot be reused in different consuming transactions. In a replay attack, for example, if two unlocking scripts are asked to be signed by the same user and one has already been unlocked, an attacker can take the Identity-Based Signature portion of the unlocking script from the first transaction and put it into the unlocking script for the second transaction. Because the IBS does not contain any fields of the transaction, the attacker can put anything he wants into this second transaction.

[0135] The challenge is to make IBS non-replayable. The method to compute the signature is explained in the following paragraphs and in Figures 4A and 4b. The same fields of the transaction used for the ECDSA signature verified by OP_CHECKSIG need to be immutable under IBS. This allows the signature to be tied to this specific transaction. Since OP_CHECKSIG takes the consuming transaction as input, it must be included in the script.

[0136] The signature to be verified by OP_CHECKSIG is a dummy signature. It is dummy because it provides integrity without authenticity for the transaction data. This technique uses a dummy signature (verified by OP_CHECKSIG) to ensure the integrity of the transaction data, and uses IBS to ensure the integrity and authenticity of the dummy signature. As a result, the transaction data has both authenticity and integrity.

[0137] The signatories will act as follows: 1. Generate a dummy signature: Create an ECDSA signature on the transaction with randomness and a private key equal to 1. 2. Sign a dummy signature using IBS 3. Include the IBS signature in the unlocking script (along with the Id, the mpk if not pre-determined, and a dummy signature)

[0138] That is, the signer Signs IBS (id,sign ECDSA (transaction,sk=1,k=1),usk id ,mpk).

[0139] The validation works as follows: 1. Verify the dummy signature using OP_CHECKSIG 2. Verify the IBS signature on the dummy signature

[0140] A locking script has the following format: DumSig Verification: OP_DUP OP_CHECKSIGVERIFY. This script verifies that DumSig is a transaction signature computed with a dummy signing key equal to 1, where P is a group generator that is independent of the identity of the transaction recipient. IBS Validation: <ida>OP_SWAP <mpk>[Verify]. This script verifies that the IBS is a valid IBS made with respect to the public parameters mpk by the identity IdA on the message DumSig.

[0141] The unlocking script has the following format: · <siga>: Valid IBS on DumSig by IdA · <dumsig>: A valid dummy signature on the transaction

[0142] In these examples, the dummy signatures are ECDSA signatures, which are fast to compute and anyone can compute them.

[0143] Note that the message signed by the IBS (the dummy signature) can be extended to include arbitrary data. This allows the user to sign parts of the unlocking script (except the IBS itself). This allows conditional payment on authenticated messages. This extension is used in the following general context:

[0144] 6.3 Generalizing dummy signatures The dummy signature technique described in the previous section can be applied to any type of signature that is verified in a script without OP_CHECKSIG. Let any signature scheme be denoted as Σ. For IBS, the method is to use a dummy signature in the message or part of the message to be signed by Σ. This is shown in Figures 5A and 5B.

[0145] 6.3.1 Quantum Secure Bitcoin In the unlikely event that the Discrete Logarithm Problem (DLP) becomes a simple problem, ECDSA will no longer be secure. This may happen when efficient quantum computers emerge. However, a variant of the dummy signature technique can be used to secure transactions with a different signature Σ that remains secure, e.g. a quantum-safe digital signature.

[0146] In ECDSA, there are two important elements sk and k. In a dummy signature, k and sk are set to 1. Verifying the signature implicitly verifies that sk=1. In the version presented above, the script does not verify that k=1. This is a problem if DLP is straightforward. In fact, in ECDSA, s=k -1 (H(m)+r d A ) and r is g k If k is not fixed and DLP is simple, then the Σ signature from transaction m′ can be reused to spend a new transaction m with a similar locking script. r is set to H(m')-H(m) k is computed from r using an efficient DLP algorithm (which exists here because DLP is assumed to be simple). DumSig is now calculated correctly using the k and r created ·Σ is copied from m''s consuming transaction and to m's consuming transaction.

[0147] This can be prevented using two different methods. Have node 104 calculate the dummy signature portion and extract the dummy signature Σ from the unlocking script. Verify in advance that the first part of the dummy signature r is computed correctly, e.g., r=x mod p, where x is the first coordinate of P.

[0148] By fixing k and sk, the dummy signature is nothing more than a double SHA256 hash, which can be verified in the script. The fact that SHA256 is unaffected by quantum algorithms means that this technique is quantum-safe if Σ is quantum-safe. Quantum-safe signatures are well known and any suitable scheme may be used. For example, L. Ducas, E. Klitz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler and D. Sthehle, "CRYSTALS-Dilithium: A Lattice-Based Digital", IACR Transactions on Cryptographic Hardware and Embedded Systems, 2017, T. Prest, P.-A. Fouque, J. Hoffstein, P. Kirchner, V. Lyubashevsky, T. Pornin, T. Ricosset, G. Seiler, W. Whyte and Z. Zhang, “Falcon: Fast-Fourier and J. Ding, M.-S. Chen, A. Petzoldt, D. Schmidt, B.-Y. Yang, M. Kannwischer and J. Patarin, "Rainbow, a New Multivariable Polynomial."

[0149] 6.3.2 Rabin Signatures This section describes Rabin signatures that can provide transaction data integrity using dummy signatures. The locking script size to verify a Rabin signature is very small, requiring only a few arithmetic operations (addition multiplication and hashing) for large numbers. The script size to verify a Rabin signature is approximately 5 bytes. Setup

[0150]

number

[0151] : 1. Hash Functions

[0152]

number

[0153] Select KeyGen(param): 1. Size

[0154]

number

[0155] Choose two random primes p and q of 2. Choose one random b ∈ [1; p q] 3. Print sk = (p, q) and pk = (p q, b) Sign(m,sk;r): 1. Choose a random padding U of size m (where m is a dummy signature) 2. Solve x(x+b)=H(mU) 3. If there is no solution, go to step 1 4. Output the signature σ = (U, x) Verify(m,σ,vk): 1. Calculate x(x+b) and H(mU) 2. If they are equal, output 1, otherwise output 0.

[0156] 6.3.3 Schnorr Signatures Another scheme that can be used with dummy signatures is Schonrr signatures. Schonrr signatures have many direct applications, such as group signatures, threshold signatures, blind signatures, and multi-signatures. They can also be aggregated and verified in batches with only one verifier. This last application (multi-signatures) is the motivation for modifying the Bitcoin protocol to allow Schnorr signature verification within scripts. The techniques described herein enable secure use and verification of Schnorr signatures without modifying the Bitcoin protocol. Setup

[0157]

number

[0158] : 1. Hash Functions

[0159]

number

[0160] Select KeyGen(param): 2.

[0161]

number

[0162] Randomly select and calculate Z=z P 3. Print sk=z and pk=z Sign(m,sk;r): 5. Random

[0163]

number

[0164] Select 6. Calculate R = r P, e = H(R||m), and s = r-ze. 7. Output the signature σ = (e,s) Verify(m,σ,vk): 3. Calculate r'=s·P+e·Z and e'=H(r'||m). 4. If e=e', output 1, otherwise output 0

[0165] The script size to verify a Schnorr signature is approximately 1.4MB (two fixed scalar multiplications and one point addition).

[0166] 6.4 Application The IBS private key or user private key is a signing key that embeds immutable information. This information is created to define an entity. However, it can be any string of bits. If the signature verification passes, the verifier is assured that the message really comes from the entity whose identity is represented by the bit string.

[0167] There are several ways to use IBS in Bitcoin, each leading to different applications. Two are described here. · In one case, a general-purpose system is set up where everyone shares the same master public key. This implies that there is only one master private key that can be held by one entity (leading to key escrow as discussed above). This environment eliminates the use of public key infrastructure, which is a large communication and computational burden. In the other case, an individual maintains their own IBS scheme. In this context, any user can use their own ECDSA signing key as the master private key and construct a master public key with the verification key. This leads to several uses, including CA delegation and dynamic multisig, two of which are described below.

[0168] 6.4.1 P2ID and P2IDH This section describes a transaction template that can be used to circumvent PKI using IBS. See Table 2 and Table 3, where the locking script is denoted as Pay-to-ID (P2ID). As with P2PKH, it is possible not to include the identity of the recipient of the transaction in the locking script. Instead, its hash may be included in the locking script, and the identity may be included in the unlocking script. This is referred to herein as pay to Identity Hash (P2IDH). This is shown in Table 4 and Table 5.

[0169] [Table 2]

[0170] [Table 3]

[0171] [Table 4]

[0172] [Table 5]

[0173] 6.4.2 Transfer of Rights Any entity can act as a PKG and delegate its signing rights to others. In this use case, key escrow is a feature. Even after the locking script is created and the transaction containing the locking script is published, a new private key can be generated and given to the delegate to unlock the output. The following section describes the case of delegation of revocation rights. More precisely, in this example, a valid certificate is represented by a UTXO on the blockchain. A certificate authority with its own signing key needs to handle many operations. In the context of a regular PKI, there are several entities with different roles in the certification protocol: registration authorities, certification authorities (CAs), revocation authorities (RAs). The successor of all these entities can be a root certificate authority that can hold multiple instances of the public key infrastructure. In the IBS technique described herein, the root CA can create user private keys for any entity whose identity reflects its role. Figure 6 shows an example of a revocation authority RA1 with delegated rights to revoke certificates. It works as follows. 1. A certificate authority CA creates a pair (mpk,msk) using its ECDSA signing key as msk (implying that Z in mpk is equal to the CA's ECDSA verification key). 2. The CA sends its master private key (msk) and identity (Id) RA1 Create a user private key usk for revocation authority RA1 using ="revocation authority for CA|RA1" 3. usk is then passed to RA1 4. When a transaction needs to be consumed to revoke a certificate, RA1 generates a signature (IBS+DumSig) on ​​the transaction and sends this signature and its identity, Id, to the unlocking script. RA1 Include 5. Id RA1 If the signature begins with "revocation authority for CA" and is valid, the transaction is valid and is accepted. The certificate is therefore revoked.

[0174] The information in the identity enables or disables different types of activities (here, spending transactions are only possible for entities responsible for revoking certificates). Moreover, the master public keys of these delegated entities contain the CA's verification key, which allows the subentity to be directly linked to the superior entity. Table 6 shows the locking script for transactions where certificate consumption can be delegated to a revocation authority. In this example, a special template is used for the identity to be recognized as a revocation authority. In practice, any format of identity will work as long as it is publicly known. To spend a UTXO, the unlocking script: 1. Sig as mpk Id and PK CA* To verify 2. The Id begins with "revocation authority for CA" 3. DumSig is a valid dummy signature for the transaction, as explained in Table 6 and Table 7. It should contain any (Sig, Id, DumSig) such that

[0175] [Table 6]

[0176] [Table 7]

[0177] 6.4.3 Dynamic Multisig The opcode OP_CHECKMULTISIG allows for the allocation of transaction outputs with n signatures of m of the PK owners specified in the locking script, but this opcode is not dynamic and the public keys (and therefore the private keys) must be generated at the time of creating the locking script.

[0178] A PKG that creates templates for the keys and identities for all users in a multisig group provides an efficient way to implement multisignatures, which leads to key escrow since multisigs can be used between entities of the same company or between subordinate entities, but that's not a problem.

[0179] In this document, IBS-based multisig is referred to as n-MultiSig for k conditions. A condition is a constraint on the identity information. As an example, this section describes the case of 1-multisig for two conditions. Condition 1: Part of nChain Condition 2: Be a researcher

[0180] To aid in condition validation, one can think of a template of the form "Country||Company||Position||LastName||FirstName", so the identity could be "France||nChain||Researcher||Germouty||Paul". Using this example template, it is possible to create a multisig for any researcher in nChain by having the identity have "nChain" and "Researcher" as the second and third fields. This is shown through transaction templates in Tables 8 and 9.

[0181] [Table 8]

[0182] [Table 9]

[0183] In a general context, we have n-Multisig for k conditions. This means that n signatures are required for k different conditions that are enforced using regular expressions in the script on the identities. Thus, a signature is accepted if and only if its number is n, and if the identity of each signature satisfies the k conditions. This is shown in the general template transaction in Table 10 and Table 11.

[0184] [Table 10]

[0185] [Table 11]

[0186] The size of the locking script grows linearly with the size of n, not k. In fact, there are n validations of the IBS to be performed. Since one set of opcodes is required for each signature, the size of the locking script grows linearly with the size of n. Conversely, the number of conditions to be verified has little effect on the size of the locking script. In both cases, string comparisons are performed, and the number of conditions only increases the number of equality checks up to the bit validation at this bit.

[0187] The number of possible signers is infinite if the size of the locking script is fixed. In the above example, the condition "researcher" in nChain can be true for as many identities as the PKG wants, since the PKG can create identities arbitrarily.

[0188] One could argue that an authority in a PKI environment could do the same thing by distributing the same public key to every single user in a multisig and allow them to sign directly with the public key. However, this has two main problems: 1) it is impossible to know which user signed, and 2) it is not flexible or extensible, whereas in the above example it is possible to create different conditions for a multisig, which could be everyone in nChain, or everyone in nChain in France, etc.

[0189] As mentioned before, the multisig scheme described herein is dynamic: any user can be added to the set of authorized signatures if the PKG generates and sends a valid user private key to the user. This can even be done after the creation of the locking script.

[0190] CA delegation can be seen as a special case of dynamic multisig. For the revocation example described above, it can be seen as a multisig with one condition. The condition is that the first part of the identity is "revocable for CA".

[0191] 6.5 Efficiency Comparison This section compares the Identity-Based Signatures used in Bitcoin with other IBS schemes. Efficiency is described in multiplicative notation and for clarity

[0192]

number

[0193] Ignore the multiplications and additions in

[0194] BBG IBS (D. Boneh, X. Boyen and E. Goh, "Hierarchical Identity Based Encryption with Constant Size Ciphertext", EUROCRYPT, Aahrus, 2005) is based on bilinear mappings and is secure in the standard model under the bilinear Diffie Hellman problem. It is an adaptation of Hierarchical Identity-based Encryption (HIBE) (ASCraig Gentry, "Hierarchical ID-based cryptography", ASIACRYPT, Queenstown, 2002) to IBS.

[0195] The three other schemes are secure under a more flexible model called the Random Oracle Model. This model is enabled by the core use of hash functions in these schemes. GS IBS is another adaptation of HIBE to IBS, based on one of the first HIBEs created. It is secure under Constructive Diffie Hellman (CDH). GG IBS (D. Galindo and FD Garcia, "A Schnorr-Like Lightweight Identity-Based Signature Scheme", Africacrypt, Gammarth, 2009) is the one used to instantiate IBS in Bitcoin as described herein. It does not use bilinear maps and is secure under the Discrete Logarithm Problem (DLP).

[0196] Table 14 compares ECDSA with dummy signature schemes. Due to the simplifications made in dummy signatures, the efficiency is quite different. Signing time is by construction very short. In addition, in P2PKH, the signer's public key needs to be included in the unlocking script, which is not necessary for dummy signatures, since it is always equal to the generator P and is therefore implicit.

[0197] [Table 12]

[0198] [Table 13]

[0199] In these tables, the following notation is used: ·

[0200]

number

[0201] ,

[0202]

number

[0203] denotes the two groups required to implement the bilinear map. ·

[0204]

number

[0205] is a group for nonlinear mapping-based scheme operations, which is a group such that DLP and CDH must be hard to have secure signatures. "exp." means exponentiation, "inv." means inverse operation, and "mult." means multiplication.

[0206] 7. Further Observations Other variations or uses of the disclosed techniques may be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the disclosure is limited only by the appended claims, and not by the described embodiments.

[0207] For example, some embodiments above have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one 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 may 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 may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

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

[0209] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not precluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, on those 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 store and / or disseminate those blocks 151 to other nodes.

[0210] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, publishing, disseminating and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0211] Some embodiments have been described with respect to blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and general embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to produce the next block 151. The chosen node is often called a validator. A blockchain node can lock its token for a certain amount of time to have a probability of becoming a validator. In general, the node that locks the largest stake for the longest time has the highest probability of becoming the next validator.

[0212] It will be appreciated that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided according to any one or more of the following statements:

[0213] Statement 1. A computer-implemented method for enabling a non-native blockchain signature to be verified within a script, the method being performed by a first party; obtaining a second blockchain transaction, the second blockchain transaction referencing the first blockchain transaction; generating a first signature based on at least the second blockchain transaction, wherein a first private key used to generate the first signature is set equal to 1; generating a second signature based on the first signature, where the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; including the first signature and the second signature in an unlocking script for verification when the unlocking script of the second blockchain transaction is executed together with the locking script of the first blockchain transaction; and causing a second blockchain transaction to be submitted to the blockchain network.

[0214] The first signature signs a first message, the first message being based on the second transaction. The second signature signs a second message, the second message comprising the first signature.

[0215] In other words, the first signature is a signature of a first signature scheme and the second signature is a signature of a second, different signature scheme. A native blockchain signature is a signature that, when verified by a blockchain scripting engine, forces the scripting engine to obtain fields of the first blockchain transaction (i.e., the spend transaction) during the verification process. Similarly, a native signature is a signature that can be verified within a script using dedicated functions / opcodes.

[0216] Statement 2. The method of statement 1, wherein the first signature is an ECDSA signature.

[0217] Statement 3. The method of statement 1 or statement 2, wherein the ephemeral key used to generate the first signature is set equal to 1.

[0218] Statement 4. The second signature, quantum resistant signature, Rabin signature, Schnorr signature Any of statements 1 to 3.

[0219] Statement 5. The method of any preceding statement, wherein the second signature is an identity-based signature.

[0220] Statement 6. The method of statement 5, wherein the first party has a first identifier, a second private key, and a second public key, the second private key is based on the first identifier, and the second signature is based on the first signature, the first identifier, and the second private key.

[0221] Statement 7. The method of statement 6, wherein the first identifier comprises at least a portion of one or more of a name, an address, a date of birth, an email address, a username, a passport number, a driver's license number, and a social security number.

[0222] Statement 8. The second public key has a set of parameters, the set of parameters including at least a prime number, an elliptic curve point generator of an order of the prime number, a first hash function, and a second hash function; and the second private key is calculating a first elliptic curve point based on a first random value and an elliptic curve point generator, the first elliptic curve point being a first value of a second private key; calculating a second value of the second private key based on a first hash generated by hashing the first elliptic curve point, the master private key, the first elliptic curve point, and the first identifier with a first hash function; The method of statement 5 or statement 6,

[0223] Statement 9. The method of statement 8, wherein the second private key is generated by a key generator having a master private key, the method comprising receiving the second private key from the key generator.

[0224] Statement 10. The second signature, calculating a first value of a second signature based on the second random value and the elliptic curve generator; calculating a second value of the second signature based on the second random value, the first value of the second private key, and a second hash generated by hashing the first identifier, the first value of the second signature, and the first signature; Setting the third value of the second signature as the first value of the second private key. The method of statement 8 or statement 9,

[0225] Statement 11. Any of statements 6 to 10, the method comprising including the first identifier in an unlocking script of the second blockchain transaction.

[0226] Statement 12. The method of any of statements 5-11, wherein the unlocking script of the second blockchain transaction comprises one or more additional identity-based signatures, each generated by a different party.

[0227] Statement 13. The method of any preceding statement, wherein the locking script of the first blockchain transaction represents a certificate and wherein issuing the second blockchain transaction represents a revocation of the certificate.

[0228] Statement 14. A computer-implemented method for verifying a non-native blockchain signature in a script, the method being performed by a second party; generating a first blockchain transaction comprising a locking script, the locking script comprising a first verification script and a second verification script, wherein when the locking script of the first blockchain transaction is executed together with the unlocking script of the second blockchain transaction, the first verification script is configured to verify a first signature based on a first public key corresponding to a first private key set equal to one, and the second verification script is configured to verify a second signature, wherein the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; causing a first blockchain transaction to be submitted to a blockchain network.

[0229] Statement 15. The method of statement 14, wherein the first verification script is configured to verify an ECDSA signature.

[0230] For example, the first verification script may comprise at least one of an OP_CHECKSIG opcode, an OP_CHECKSIGVERIFY opcode, an OP_CHECKMULTISIG opcode, and an OP_CHECKMULTISIGVERIFY opcode.

[0231] Statement 16. The method of statement 14 or statement 15, wherein the second verification script is configured to verify the identity-based signature.

[0232] Statement 17. The method of statement 16, wherein the first party has a first identifier, a second private key, and a second public key, the second private key being based on the first identifier, and the second signature verification script is configured to verify the second signature based on the first identifier, the second public key, and the first signature.

[0233] Statement 18. The second public key comprises a set of parameters, the set of parameters including at least a prime number, an elliptic curve point generator of an order of the prime number, a first hash function, a second hash function, and a public value corresponding to the master private key; the second signature comprises a first value, a second value, and a third value; and the second verification script comprises: calculating a first verification value based on a first hash generated by hashing the first value, the third value, and the first identifier with a first hash function, a second hash generated by hashing the first identifier, the first value, and the first signature with a second hash function, and a public value corresponding to the master private key; calculating a second verification value based on the second value and the elliptic curve generator; Verifying that the first verification value corresponds to the second verification value. 20. The method of claim 17, configured to verify the second signature by

[0234] Statement 19. The method of statement 17 or statement 18, wherein the locking script of the first blockchain transaction comprises the first identifier and the second verification script is configured to verify that the unlocking script of the first blockchain transaction comprises the first identifier.

[0235] Statement 20. Any of statements 16-19, wherein the locking script of the first blockchain transaction comprises a hash of the first identifier, and the second verification script is configured to verify that the unlocking script of the first blockchain transaction comprises the first identifier by hashing the first identifier and comparing the result to the hash of the first identifier.

[0236] Statement 21. The method of any of statements 16-19, wherein the locking script comprises multiple instances of the second validation script, and when executed, each instance of the second validation script is configured to validate a respective identity-based signature included in the unlocking script of the second blockchain transaction.

[0237] Statement 22. The method of any of statements 16-21, wherein the locking script is configured to verify that the unlocking script of the second blockchain transaction comprises an identifier, the identifier having one or more predetermined fields.

[0238] Statement 23. The method of statement 22, wherein the locking script does not require that a particular identifier be included in the unlocking script of the second blockchain transaction.

[0239] Statement 24. The second signature, quantum resistant signature, Rabin signature, Schnorr signature The method of statement 14 or statement 15 is one of the methods of statement 14 or statement 15.

[0240] Statement 25. A memory having one or more memory units; a processing device having one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any of statements 1 to 24.

[0241] Statement 26. A computer program embodied on a computer readable storage configured, when executed on one or more processors, to perform the method of any of statements 1 to 24.

[0242] According to another aspect disclosed herein, a method may be provided that comprises activity of a first party and a second party.

[0243] According to another aspect disclosed herein, a system may be provided that includes a first party and a second party computing device. [Explanation of symbols]

[0244] 101 Packet Switching Network 102 Computer terminals 103 users 104 Blockchain nodes 105 Client Applications 106 Blockchain Network 107 Side Channel 150 Blockchain 151 Blocks 152 Transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output 301 Key Generator< / dumsig> < / siga> < / mpk> < / ida>

Claims

1. 1. A computer-implemented method for enabling a non-native blockchain signature to be verified in a script, the method being performed by a first party, the method comprising: obtaining a second blockchain transaction, the second blockchain transaction referencing the first blockchain transaction; generating a first signature based on at least the second blockchain transaction, wherein a first private key used to generate the first signature is set equal to 1; generating a second signature based on the first signature, wherein the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; including the first signature and the second signature in an unlocking script for validation when the unlocking script of the second blockchain transaction is executed together with the locking script of the first blockchain transaction; causing the second blockchain transaction to be submitted to a blockchain network; A method comprising:

2. The method of claim 1 , wherein the first signature is an ECDSA signature.

3. 3. The method of claim 1, wherein an ephemeral key used to generate the first signature is set equal to one.

4. The second signature: quantum resistant signature, Rabin signature, Schnorr signature The method according to any one of claims 1 to 3, wherein the

5. The method of claim 1 , wherein the second signature is an identity-based signature.

6. 6. The method of claim 5, wherein the first party has a first identifier, a second private key, and a second public key, the second private key being based on the first identifier, and the second signature being based on the first signature, the first identifier, and the second private key.

7. The method of claim 6 , wherein the first identifier comprises at least a portion of one or more of the following: a name, an address, a date of birth, an email address, a username, a passport number, a driver's license number, and a social security number.

8. the second public key comprises a set of parameters, the set of parameters including at least a prime number, an elliptic curve point generator of an order of the prime number, a first hash function, and a second hash function; and the second private key comprises: calculating a first elliptic curve point based on a first random value and the elliptic curve point generator, the first elliptic curve point being a first value of the second private key; calculating a second value of the second private key based on a first hash generated by hashing the first elliptic curve point, a master private key, the first elliptic curve point, and the first identifier with the first hash function; 7. The method of claim 5 or 6, wherein the compound is produced by

9. 9. The method of claim 8, wherein the second private key is generated by a key generator that has the master private key, the method comprising receiving the second private key from the key generator.

10. The second signature: calculating a first value of the second signature based on a second random value and the elliptic curve generator; calculating a second value of the second signature based on the second random value, the first value of the second private key, and a second hash generated by hashing the first identifier, the first value of the second signature, and the first signature; setting a third value of the second signature as the first value of the second private key.

10. The method of claim 8 or 9, wherein the compound is produced by

11. 11. The method of claim 6, further comprising including the first identifier in the unlocking script of the second blockchain transaction.

12. 12. The method of claim 5, wherein the unlocking script of the second blockchain transaction comprises one or more additional identity-based signatures, each generated by a different party.

13. 13. The method of claim 1, wherein the locking script of the first blockchain transaction represents a certificate and issuing the second blockchain transaction represents a revocation of the certificate.

14. 1. A computer-implemented method for verifying a non-native blockchain signature in a script to generate a blockchain transaction, the method being performed by a second party; generating a first blockchain transaction comprising a locking script, the locking script comprising a first verification script and a second verification script, wherein when the locking script of the first blockchain transaction is executed together with an unlocking script of a second blockchain transaction, the first verification script is configured to verify a first signature based on a first public key corresponding to a first private key set equal to 1, and the second verification script is configured to verify a second signature, wherein the first signature is a native blockchain signature and the second signature is a non-native blockchain signature; causing the first blockchain transaction to be submitted to a blockchain network; A method comprising:

15. 15. The method of claim 14, wherein the first verification script is configured to verify an ECDSA signature.

16. 16. The method of claim 14 or 15, wherein the second verification script is configured to verify an identity-based signature.

17. 17. The method of claim 16, wherein a first party has a first identifier, a second private key, and a second public key, the second private key being based on the first identifier, and the second signature verification script is configured to verify the second signature based on the first identifier, the second public key, and the first signature.

18. the second public key comprises a set of parameters, the set of parameters including at least a prime number, an elliptic curve point generator of an order of the prime number, a first hash function, a second hash function, and a public value corresponding to a master private key; the second signature comprises a first value, a second value, and a third value; and the second verification script comprises: calculating a first verification value based on a first hash generated by hashing the first value, the third value, and the first identifier with the first hash function, a second hash generated by hashing the first identifier, the first value, and the first signature with the second hash function, and the public value corresponding to the master private key; calculating a second verification value based on the second value and the elliptic curve generator; Verifying that the first verification value corresponds to the second verification value.

20. The method of claim 17, configured to verify the second signature by:

19. 19. The method of claim 17 or 18, wherein the locking script of the first blockchain transaction comprises the first identifier, and the second verification script is configured to verify that the unlocking script of the first blockchain transaction comprises the first identifier.

20. 20. The method of any one of claims 16 to 19, wherein the locking script of the first blockchain transaction comprises a hash of the first identifier, and the second verification script is configured to verify that the unlocking script of the first blockchain transaction comprises the first identifier by hashing the first identifier and comparing the result to the hash of the first identifier.

21. 20. The method of claim 16, wherein the locking script comprises multiple instances of the second validation script, and when executed, each instance of the second validation script is configured to validate a respective identity-based signature included in the unlocking script of the second blockchain transaction.

22. 22. The method of any one of claims 16 to 21, wherein the locking script is configured to verify that the unlocking script of the second blockchain transaction comprises an identifier, the identifier having one or more predetermined fields.

23. 23. The method of claim 22, wherein the locking script does not require that a particular identifier be included in the unlocking script of the second blockchain transaction.

24. The second signature: quantum resistant signature, Rabin signature, Schnorr signature 16. The method according to claim 14 or 15, wherein the

25. a memory comprising one or more memory units; 25. A computing device comprising: a processing device having one or more processing units; and wherein the memory stores code arranged to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any one of claims 1 to 24.

26. A computer program embodied on a computer readable storage configured to, when executed on one or more processors, perform the method of any one of claims 1 to 24.

Images