COMPUTER-IMPLEMENTED SYSTEMS AND METHODS FOR AUTHORISING BLOCKCHAIN TRANSACTIONS WITH LOW-ENTROPY PASSWORDS

Abstract

There may be provided a blockchain-implemented security method involving a requestor and a group of nodes, which includes generating a cryptographic key of the requestor based on a password chosen by the requestor and first quantities sent by the group of nodes (which are derived from private key shares of the group of nodes and a generator function of a digital signature scheme employing a bilinear mapping on an elliptic curve). A cryptographic signature for a requestor blockchain transaction can be generated where the signature corresponds to the requestor's cryptographic key. The signature can be based on the password and second quantities sent by the group of nodes (which are also derived from the group private key shares). The method can further include verifying the cryptographic signature of the blockchain transaction using the requestor's cryptographic key. Additionally or alternatively, the method can employ a consensus mechanism involving the group of nodes to allow the requestor to authorise a transaction with a password. The method can be logically partitioned into a sequence of phases, including an initialisation phase, a funding phase, and a payment authorization phase (which involves a pre-spending transaction and a spending transaction).

Claims

1. A blockchain-implemented security method for a threshold signature scheme involving a requestor that belongs to a group of nodes in a blockchain network, the method performed at the requestor comprising: generating a cryptographic public key of the requestor based on i) a password chosen by the requestor and ii) a plurality of first quantities received at the requestor, wherein the plurality of first quantities is sent to the requester by the group of nodes and is based on private key shares of the group of nodes and a generator function of a digital signature scheme employing a bilinear mapping on an elliptic curve; generating a cryptographic signature for a blockchain transaction of the requestor, the cryptographic signature corresponding to the cryptographic public key of the requestor based on the bilinear mapping on an elliptic curve of the digital signature scheme, wherein the cryptographic signature is based on i) the password chosen by the requestor and ii) a plurality of second quantities received at the requestor, wherein the plurality of second quantities is sent to the requester by the group of nodes and is based on the private key shares of the group of nodes; and verifying the cryptographic signature of the blockchain transaction using the cryptographic public key of the requestor.

2. The blockchain-implemented security method according to claim 1, further comprising: establishing the group of nodes operably coupled to one another via at least one communication network, wherein each node of the group transfers a digital asset to the group; and/or receiving a funding transaction from a requestor, wherein the funding transaction specifies one or more digital assets of the requestor where all or some of such digital assets may be transferred using a password chosen by the requestor; and/or receiving a spending transaction that transfers some portion of the one or more digital assets of the requestor as specified in the funding transaction, wherein the spending transaction includes the cryptographic signature corresponding to the cryptographic public key of the requestor; and/or verifying the cryptographic signature included in the spending transaction using the cryptographic public key of the requestor.

3. The blockchain-implemented security method according to claim 2, further comprising: receiving an initialisation transaction from the requestor, wherein the initialisation transaction indicates a desire to set the password associated with the requestor; and/or generating a first quantity in response to the initialisation transaction; and/or sending a first message to the requestor, wherein the first message includes the first quantity.

4. The blockchain-implemented security method according to claim 2, further comprising: receiving a pre-spending transaction from the requestor, wherein the pre-spending transaction transfers a transaction deposit and includes a hash of at least part of the spending transaction, wherein the hash of at least part of the spending transaction is based on a hash function of the digital signature scheme; and/or generating a second quantity in response to the pre-spending transaction; and/or sending a second message to the requestor, wherein the second message includes the second quantity.

5. The blockchain-implemented security method according to claim 1, further comprising: broadcasting a funding transaction from the requestor for communication to the group of nodes, wherein the funding transaction specifies one or more digital assets of the requestor where all or some of such digital assets may be transferred using a password chosen by the requestor; and/or broadcasting a spending transaction from the requestor for communication to the group of nodes, wherein the spending transaction transfers some portion of the one or more digital assets of the requestor as specified in the funding transaction, and wherein the spending transaction includes the cryptographic signature.

6. The blockchain-implemented security method according to claim 5, further comprising: broadcasting an initialisation transaction from the requestor for communication to the group of nodes, wherein the initialisation transaction indicates a desire to set the password associated with the requestor, wherein the plurality of first quantities are generated and sent by the group of nodes in response to the initialisation transaction; and/or generating the cryptographic public key based at least in part on the password chosen by the requestor and the plurality of first quantities sent by the group of nodes in response to the initialisation transaction.

7. The blockchain-implemented security method according to claim 5, further comprising: broadcasting a pre-spending transaction from the requestor for communication to the group of nodes, wherein the pre-spending transaction transfers a transaction deposit and includes a hash of at least part of the spending transaction, wherein the hash of at least part of the spending transaction is based on a hash function of the digital signature scheme, wherein the plurality of second quantities are generated and sent by the group of nodes in response to the pre-spending transaction.

8. The blockchain-implemented security method according to claim 5, further comprising: establishing the group of nodes operably coupled to one another via at least one communication network, wherein each node of the group transfers a digital asset to the group, and wherein each node of the group stores a corresponding private key share; broadcasting, by a requestor system, an initialisation transaction from the requestor for communication to the group, wherein the initialisation transaction indicates a desire to set a password associated with the requestor; generating, by the nodes of the group, a plurality of first quantities in response to the initialisation transaction, wherein the first quantity generated by a given node is based at least in part on a private key share of the node and a generator function of the digital signature scheme; sending, by the nodes of the group, respective first messages to the requestor, wherein the first messages include the plurality of first quantities; generating, by the requestor system, the cryptographic public key based on the password chosen by the requestor and the plurality of first quantities; broadcasting, by the requestor system, a funding transaction from the requestor for communication to the group, wherein the funding transaction specifies one or more digital assets of the requestor where all or some of such digital assets may be transferred using the password chosen by the requestor; broadcasting, by the requestor system, a pre-spending transaction from the requestor for communication to the group, wherein the pre-spending transaction transfers a transaction deposit and includes a hash of an unsigned spending transaction that transfers some portion of certain funds of the requestor using a hash function of the digital signature scheme; generating, by the nodes of the group, a plurality of second quantities in response to the pre-spending transaction, wherein the second quantity generated by a given node is based at least in part on the hash of the unsigned spending transaction as included in the pre-spending transaction and the private key share of the node; sending, by the nodes of the group, second messages to the requestor, wherein the second messages include the plurality of second quantities; generating, by the requestor system, the cryptographic signature based on the password chosen by the requestor and the plurality of second quantities; broadcasting, by the requestor system, a spending transaction from the requestor for communication to the group, wherein the spending transaction transfers some portion of the certain funds of the requestor, and wherein the spending transaction is based on the unsigned spending transaction and includes the cryptographic signature; and verifying, by at least the nodes of the group, the cryptographic signature of the spending transaction using the cryptographic public key of the requestor.

9. The blockchain-implemented security method according to claim 3, wherein: the initialisation transaction includes an initialisation fee that is paid by the requestor to the group; and/or the initialisation fee is paid to a public group address associated with the group; and/or the initialization fee is returned to the requestor in the event that at least one node of the group sends an inconsistent first quantity to the requestor; and/or inconsistency of the first quantity is determined using a verifiable secret sharing scheme.

10. The blockchain-implemented security method according to claim 4, wherein: the pre-spending transaction further defines a spending fee; and/or the transaction deposit is locked under a public group address associated with the group; and/or the group selectively transfers the transaction deposit less the spending fee back to the requestor in the event that the verifying is successful; and/or the group selectively confiscates the transaction deposit in the event that the verifying fails; and/or the transaction deposit is returned to the requestor in the event that at least one node of the group of nodes sends an inconsistent second quantity to the requestor; and/or inconsistency of the second quantity is determined using a verifiable secret sharing scheme; and/or the spending fee is paid to a public group address associated with the group; and/or the nodes of the group verify that the spending fee is sufficient, wherein sufficiency of the spending fee is based on computation resources required to process a third transaction and the spending transaction; and/or the nodes of the group selectively bypass further processing of the pre-spending transaction in the event of failed verification of sufficiency of the spending fee; and/or the group selectively distributes the spending fee to the group in the event of successful verification of the signature of the spending transaction.

11. The blockchain-implemented security method according to claim 2, wherein: the funding transaction specifies that the one or more digital assets of the requestor are locked by the cryptographic public key and thus can be spent by the cryptographic signature; and the verifying of the signature of the spending transaction is performed by the group and optionally by other nodes that do not belong to the group.

12. The blockchain-implemented security method according to claim 2, wherein: the funding transaction specifies that the one or more digital assets of the requestor are locked by a public key of the group and thus can be spent by a signature based on a threshold number of private key shares of the group; the verifying of the signature of the spending transaction is performed only by the group; and upon successful verification of the signature of the spending transaction, the group cooperates to generate a signature based on a threshold number of private key shares of the group and to construct a secondary spending transaction that includes such signature.

13. The blockchain-implemented security method according to claim 2, wherein: the plurality of first quantities are included in private messages sent from the nodes of the group to the requestor and/or are encrypted with a public key of the requestor; and/or the nodes of the group each have a trusted execution environment that stores a private key share of the node; and/or the trusted execution environment of the node generates the first quantity based at least in part on a private key share of the node and the generator function of the digital signature scheme; and/or the plurality of second quantities are included in private messages sent from the nodes of the group to the requestor and/or are encrypted with a public key of the requestor; and/or the trusted execution environment of the node generates the second quantity based at least in part on a hash of the unsigned spending transaction as included in a pre-spending transaction and a private key share of the node; and/or the private message sent from a node of the group to the requestor is associated with the public key of the trusted execution environment of the node and is signed with a corresponding private key of the trusted execution environment of the node; and/or one or more nodes mine the funding transaction and the spending transaction for storage in a proof-of-work blockchain.

14. A computer readable storage medium comprising computer-executable instructions that, when executed, configure a processor to perform any part of the method of claim 1.

15. An electronic device comprising: an interface device; a processor coupled to the interface device; and a memory coupled to the processor, the memory having stored thereon computer executable instructions that, when executed, configure the processor to perform any part of the method of claim 1.

Description

[0035] These and other aspects of the present invention will be apparent from and elucidated with reference to, the embodiment described herein. An embodiment of the present invention will now be described, by way of example only, and with reference to the accompany drawings, in which:

[0036] FIG. 1A illustrates a block diagram of an example blockchain network.

[0037] FIG. 1B illustrates an example of a blockchain transaction, specific to a Bitcoin blockchain environment.

[0038] FIG. 2 illustrates a block diagram of an example electronic device which may function as a node in a blockchain network.

[0039] FIG. 3 is a high-level flowchart of an example method that employs a consensus mechanism involving a congress to allow a user to authorise a transaction with a password in a secure way.

[0040] FIG. 4 is a flow chart illustrating exemplary details of the phase of FIG. 3 that establishes a congress.

[0041] FIGS. 5A-5D, collectively, is a flow chart illustrating exemplary details of the initialisation phase of FIG. 3.

[0042] FIG. 6 is a flow chart illustrating exemplary details of the funding phase of FIG. 3.

[0043] FIGS. 7A-7D, collectively, is a flow chart illustrating exemplary details of the payment authorisation phase of FIG. 3.

[0044] FIGS. 8A and 8B is a flowchart of another example method that employs a consensus mechanism involving a congress to allow a user to authorise a transaction with a password in a secure way.

[0045] BLOCKCHAIN NETWORK

[0046] Reference will first be made to FIG. 1A which illustrates, in block diagram form, an example blockchain network 100 associated with a blockchain. The blockchain network may be a public blockchain network, which is a peer-to-peer open membership network which may be joined by anyone, without invitation or without consent from other members. Distributed electronic devices running an instance of the blockchain protocol under which the blockchain network 100 operates may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be a Bitcoin protocol, for example.

[0047] The electronic devices that run the blockchain protocol and that form the nodes 102 of the blockchain network 100 may be of various types including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smart watches or other electronic devices.

[0048] Nodes 102 of the blockchain network 100 are coupled to one another using suitable communication technologies which may include wired and wireless communication technologies. Such communication adheres to the protocol associated with the blockchain. For example, where the blockchain is a bitcoin blockchain, the bitcoin protocol may be used.

[0049] Nodes 102 maintain a global ledger of all transactions on the blockchain. Thus, the global ledger is a distributed ledger. Each node 102 may store a complete copy or a partial copy of the global ledger. In the case of a blockchain secured by proof-of-work, transactions by a node 102 affecting the global ledger are verified by other nodes 102 so that the validity of the global ledger is maintained. When the blockchain is a proof-of-work based blockchain, blocks are also verified by checking the proof-of-work submitted with the block.

[0050] At least some of the nodes 102 operate as miners 104 of the blockchain network 100. The blockchain network 100 of FIG. 1A is a proof-of-work block chain in which miners 104 perform expensive computations in order to facilitate transactions on the blockchain. For example, the proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, the miners 104 find a nonce such that a block header hashes, with SHA-256, to a number that is less than a value defined by the current difficultly. The hashing power required for the proof-of-work algorithm means that a transaction is considered practically irreversible after a certain number of blocks have been mined on top of it. A miner 104 who solves the cryptographic problem creates a new block for the blockchain and broadcasts the new block to other nodes 102. The other nodes 102 verify that the miner 104 has, in fact, solved the cryptographic problem and has, therefore, demonstrated sufficient proof-of-work before accepting that the block should be added to the blockchain. The block is added to the blockchain (i.e., to the distributed global ledger) by consensus of the nodes 102.

[0051] The block created by the miner 104 includes transactions which had been broadcast to the block chain by nodes 102. For example, the block may include transactions from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, the block serves as a record of a transaction from one address to another. The party which requested that the transaction be included in the block proves that they are authorized to initiate the transfer (e.g., in the case of Bitcoin, to spend the Bitcoin) by signing the request using a private key corresponding to their public key. The transfer may only be added to the block if the request is validly signed.

[0052] In the case of Bitcoin, there is a one-to-one correspondence between public keys and addresses. That is, each public key is associated with a single address. Thus, any reference herein to transferring digital assets to or from a public key (e.g., paying into the public key) and transferring digital assets to or from the address associated with that public key refer to a common operation.

[0053] Some of the nodes 102 may participate as validating nodes, and may (or may not) operate as miners as well. Validation nodes perform validation of transactions, which can involve checking signature(s), confirming reference to valid UTXO, etc.

[0054] The example of FIG. 1A includes five nodes 102, three of which are participating as miners 104. In practice, the number of nodes 102 or miners 104 may be different. In many blockchain networks, the number of nodes 102 and miners 104 may be much greater than the number illustrated in FIG. 1A.

[0055] FIG. 1B illustrates an example of a transaction 150 as might be stored in the Bitcoin blockchain. Other variations with similar functionality are possible. The data elements or fields of a transaction might be as shown in FIG. 1B and might include additional fields beyond those described in this disclosure. As shown, there is a blockchain version field 152 that has a value to indicate a blockchain protocol version of the transaction 150. A #vin field 154 indicates how many transaction inputs (explained below) are present in the transaction 150. Other fields might be present and not illustrated, but for each transaction input (illustrated here as the example Vin[y] 160), there is a set of fields including a transaction ID (TxID) 161 of a previous transaction, an index 162 to one of the outputs of that previous transaction (the transaction that supplies the transaction output to match transaction input 160), where the TxID 161 and the index 162 together form a pointer 163 that references the output of the previous transaction. As used herein, the term “previous transaction” when used in context with respect to a current or present transaction refers to a specific prior transaction (or transactions) having a transaction output that is referred to (and “spent”) by the current or present transaction. In examples, the current or present transaction might be referred to as the “spending transaction”.

[0056] In some blockchain implementations, there is no centralised mechanism for assigning unique TxID values and instead, there is a decentralised mechanism for generating a unique TxID for a transaction, such as by generating a hash of the contents of the transaction itself. Since a valid transaction cannot have all of the exact same content as another valid transaction, each valid transaction will have a unique hash for its TxID (aside from the astronomically low probability of a hash collision). However implemented, it is assumed herein that each transaction has a unique transaction ID. Due to the nature of hashing, once a TxID is generated from a transaction's content, none of that content can be changed and have the TxID remain valid for that transaction.

[0057] As shown in FIG. 1B, the set of fields for the transaction input Vin[y] 160 also includes an Unlocking_Script_Length field 164 indicating a length of an unlocking script that follows, an Unlocking_Script field 165 containing an unlocking script (commonly referred to as “scriptSig” in the Bitcoin protocol) for the vin[y] 160 that “unlocks” a corresponding locking script of the transaction output pointed to by the pointer 163, and a sequence # field 166 that might be used to constrain the transaction 150.

[0058] Although FIG. 1B only explicitly shows one transaction input and one transaction output, more than one of each are possible. Following the transaction inputs, there is a #vout field 180 that indicates how many transaction outputs (also explained below) are present in the transaction 150. For each transaction output (illustrated here as the example Vout[x] 180), there is a set of fields including an output value field 181 that indicates the transaction value provided by this transaction output Vout[x] 180, a Locking_Script_Length field 182 indicating a length of a locking script that follows, and a Locking_Script field 183 containing a locking script (commonly referred to as “scriptPubKey” in the Bitcoin protocol) for this transaction output Vout[x] 180. As explained, the transaction value of this transaction output can be “spent” by anyone able to create a spending transaction that has a transaction input that has an unlocking script that a blockchain node will verify as TRUE when performing a verification using that unlocking script and that locking script. Other fields might follow the transaction output fields, such as a lock time field 190 that can constrain the transaction 150 to be not active prior to a specified future time or prior to a specified future block. Where each transaction input of a spending transaction points to a corresponding transaction output of a previous transaction output and the previous transaction output includes the transaction value, the transaction input need not contain a field indicating that transaction value.

[0059] As will be explained below, various nodes 102 may cooperate to form a group which will be referred to herein as a congress 110. In the example illustrated, three nodes 102 are shown as taking part in the congress 110. However, the actual number of congress 110 members may be much larger.

[0060] The congress 110 is an open-membership group which may be joined by any node 102 upon submission of sufficient stake to a pool associated with the congress 110. For example, a node may join a congress through transfer of a digital asset, such as digital currency (such as bitcoin), tokens or other stake or value, to an account associated with the congress 110. A node 102 joining a congress may be any node in the blockchain network including both mining and non-mining nodes. In at least some applications of a congress, a node acting as a congress member monitors the blockchain in the sense that they download (but not necessarily retain) the full blockchain. Techniques for establishing and maintaining the congress 110 are described in GB Patent Appl. No. 1705867.8 (Attorney Docket P510727/CEJ), filed on 11 Apr. 2017, and GB Patent Appl. No. GB1705869.4 (Attorney Docket P510728/CEJ), filed on 11 Apr. 2017.

[0061] The members of the congress may form an alternate chain network 120. The alternate chain network 120 creates and maintains a distributed ledger which will be referred to as an alternate chain. The alternate chain network 120 may be deployed to arbitrate an algorithmic-related dispute generated on the blockchain network 100. Such a dispute may exist where the reliability of processor-generated work product of one node has been challenged by another node. The alternate chain network 120 can also possibly be deployed for other purposes.

[0062] While the blockchain associated with the blockchain network 100 is a proof-of-work blockchain, the alternate chain is a proof-of-stake blockchain. The proof-of-stake based alternate chain network 120 provides an alternative mechanism for achieving consensus. In the proof-of-stake alternate chain, the blockchain is secured by proof-of-stake rather than proof-of-work. Under proof-of-stake, the miners 125 of the alternate chain deposit a security deposit of digital assets and, the probability of being selected as the node to mine a block is proportional to the quantum of the digital assets provided as deposit. Such a proof-of-stake blockchain systems can be used to avoid the computational expense and energy typically required to mine on a proof-of-work blockchain.

[0063] A plurality of nodes 102 function as miners 125 of the alternate chain network 120. At least some of the miners 125 of the alternate chain network 120 may not serve as miners 104 of the blockchain network 100. Since the alternate chain network 120 is a proof-of-stake blockchain network, the miners 125 deposit digital assets in order to be included as miners. More particularly, the miners 125 for the alternate chain form a bonded validator set in order to mine on the alternate chain network 120. These miners 125 can also be members of a congress 110 associated with the proof-of-work blockchain network 100. That is, nodes 102 which are part of both the proof-of-work blockchain network 100 and the alternate chain network 120 act as miners 125 for the alternate chain network 120 and as members of a congress 110 established on the proof-of-work blockchain network 100. These miners 125 join the congress 110 and take part in the congress 110 according to methods described below. Their deposit of digital assets into a congress pool is made in the proof-of-work blockchain. That is, the congress members deposit their “stake” on the proof-of-work blockchain network 100 to become congress members which allows them to act as miners 125 on the alternate chain by forming a bonded validator set.

[0064] In embodiments, the alternate chain of the alternate chain network 120 can be a proof-of-stake ghost chain, which is a temporary proof-of-stake blockchain. Unlike a traditional blockchain, the proof-of-stake ghost chain is configured to terminate once it has achieved its purpose. That is, the ghost chain is a single-purpose blockchain which ceases to exist once its purpose has been achieved. The proof-of-stake ghost chain includes a first block, which may be referred to as a genesis block, which is only created when the proof-of-stake ghost chain is deployed for its purpose. Details of a proof-of-stake ghost chain network are described in GB Patent Appl. No. GB1705869.4 (Attorney Docket P510728/CEJ), filed on 11 Apr. 2017.

[0065] Electronic Device Operating as a Node

[0066] FIG. 2 is a block diagram illustrating components of an example electronic device 200 which may serve as a node 102 (FIG. 1A) in the blockchain network 100 (FIG. 1A). The example electronic device 200 may also be referred to as a processing device. The electronic device may take various forms including, for example, a desktop computer, laptop computer, tablet computer, server, mobile device such a smartphone, wearable computer such as a smart watch, or a form of another type.

[0067] The electronic device 200 includes a processor 210, a memory 220 and a network interface device 230 for data communication over a network. These components may be coupled directly or indirectly to one another and may communicate with one another. For example, the processor 210, memory 220 and network interface device 230 may communicate with each other via a bus 240. The memory 220 stores a computer software program comprising machine-readable instructions and data for performing functions described herein. For example, the memory may include processor-executable instructions which, when executed by the processor 210, cause the electronic device to perform a method described herein. The processor-executable instructions may include instructions which, when executed by the processor 210, cause the electronic device to implement a protocol associated with the blockchain network 100 (FIG. 1A). For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0068] The memory 220 may store the global ledger of the blockchain network 100 (FIG. 1A) or a portion thereof. That is, the memory 220 may store all blocks of the blockchain or a portion of the blocks, such as the most recent blocks, or a portion of the information in some blocks. Further, when an alternate chain (e.g., ghost chain) is deployed, the memory 220 may store the alternate chain (e.g., ghost chain) or a portion thereof.

[0069] While the memory 220 is illustrated with a single block in FIG. 2, in practice the electronic device 200 may include multiple memory components. The memory components may be of various types including, for example, RAM, HDD, SSD, flash drives, etc. Different types of memory may be suited to different purposes. Further, while the memory 220 is illustrated separately from the processor 210, the processor 210 may include embedded memory.

[0070] As illustrated in FIG. 2, the processor 210 may include a secure area referred to as a Trusted Execution Environment (TEE) 250. The TEE 250 is an isolated execution environment which provides additional security to the electronic device 200 such as isolated execution, integrity of Trusted Applications and asset confidentiality. The TEE 250 is implemented, at least in part, at a hardware level so that instructions and data executed within the TEE 250 are protected against access and manipulation from the rest of the electronic device 200 and from external parties such as the owner of the electronic device. The data and computations within the TEE 250 are secured from the party operating the node 102 that includes the TEE 250. The TEE 250 can provide execution space and data storage which guarantees that the computer instructions and data loaded inside the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 can be implemented as a secure virtual machine that executes on the processor 210. In alternate embodiments, the TEE 250 can be implemented by a dedicated secure processor that is separate and distinct from the processor 210. The TEE 250 may be used to protect the integrity and confidentiality of important resources, such as keys. The TEE 250 can be implemented, at least in part, at a hardware level so that instructions and data executed within the TEE 250 are protected against access and manipulation from the rest of the electronic device 200 and from external parties such as the owner of the electronic device. The data and computations within the TEE 250 can be secured from the party operating the node 102 that includes the TEE 250.

[0071] The TEE 250 may operate to instantiate an enclave and then add pages of memory one at a time, while cumulatively hashing. A similar operation may also be performed on a remote machine (which may be a developer machine or another machine) so that the remote machine determines and stores the hash that is expected. The contents of an enclave can, therefore, be verified by any remote machine to ensure that the enclave is running an approved algorithm. This verification may be performed by comparing hashes. When an enclave is fully built, it is locked down. It is possible to run the code in the TEE 250 and to send secrets to the code, but the code cannot be changed. A final hash may be signed by an attestation key (which is internal to the TEE) and may be made available to a data owner to verify it before the data owner sends any secrets to the enclave.

[0072] The TEE 250 may be used to protect the confidentiality and integrity of a private key share associated with a congress public key used by the congress 110 (FIG. 1A). For example, the TEE 250 may be used for the generation and storage of private key shares. The TEE 250 is intended to ensure that no member is able to directly obtain the private key share held within the TEE 250 enclave, or information about other private key shares from inter-member communication or inter-enclave communication. The protocol is also robust against the compromise of a threshold of enclaves. Further, the TEE 250 may enable remote attestation which may be used by a node 102 (FIG. 1A) to prove to other nodes 102 that a TEE 250 is authentic and is running approved computer executable instructions for a protocol that is implemented by a congress 110. Remote attestation may be provided by the TEE 250 by running a particular piece of code and sending a hash of the code, internal to the enclave, signed by an internal attestation key for the enclave.

[0073] The TEE 250 may be used to attest to secure deletion of the private key share when a member of a congress 110 who has previously used the private key share on the electronic device 200 has chosen to leave the congress. The electronic device 200 may signal attestation of deletion to other congress members through a remote attestation protocol provided in the TEE 250. Attestation of deletion may be required before a member is permitted to withdraw their member deposit. That is, return of the deposit may be conditional on attestation to deletion of the private key share held within the member's enclave.

[0074] The TEE 250 may be equipped with a secure random number generator, which is internal to an enclave of the TEE, which can be used to generate private keys, random challenges, or other random data. The TEE 250 may also be configured to read data from external memory and may be configured to write data to the external memory. Such data may be encrypted with a secret key held only inside the enclave.

[0075] The TEE 250 may be implemented using various platforms such as Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). SGX, for example, supports remote attestation, which enables an enclave to acquire a signed statement from the processor that is executing a particular enclave with a given hash of member known as a quote. A third-party attestation service such as Intel Attestation Service (IAS) may certify that these signed statements originate from authentic TEEs conforming to the SGX specification.

[0076] The electronic device 200 acts as a node 102 of the blockchain network 100 (FIG. 1A) and may join and otherwise take part in a congress 110 (FIG. 1A). A congress 110 is formed when a group of digital asset bearers pool digital assets, such as digital currency, tokens or other stake or value supported by the blockchain network 100 (FIG. 1A), and that pool of digital assets is locked under a single public key (the congress public key) such that shares in the corresponding private key are held by congress members (preferably inside TEEs of the congress members) in proportion to the quantity of assets contributed to the pool. The electronic device 200 can also act as a node 102 of the alternate chain network 120 (FIG. 1A).

[0077] Congresses

[0078] The congress 110 may be a permissioned group or non-permissioned group. That is, the congress 110 may be joined by any node in the blockchain network 100 (FIG. 1A) (i.e., by any node that monitors and stores at least a portion of the information in the blockchain). To join the congress 110, a node 102 transfers one or more digital assets to a digital asset pool associated with the congress 110 (i.e., to a public group address associated with one or more digital assets which are, in turn, associated with other members of the congress). This digital asset pool may be referred to as a congress pool. For example, a node 102 may join a congress 110 by transferring (i.e., depositing) such digital assets to an address associated with the congress pool (i.e., to a “congress address” which may also be referred to as a public group address). The digital assets are placed under the control of a group threshold signature with a single public key, referred to as a congress public key. Congress members hold distributively-generated private key shares. The number of shares held by a particular congress member may be in proportion to the amount deposited in the pool by that particular congress member.

[0079] The digital assets that are controlled by the congress 110, which include any digital assets transferred to the congress address, can be placed under the control of a threshold signature scheme. Under the threshold signature scheme, a group of members whose total private key share holdings exceed a threshold are needed to produce a valid signature which allows the digital assets to be transferred away from control of the congress 110. That is, at least a threshold number of private key shares must be used to generate a valid signature for any outgoing transfer of digital assets controlled by the congress 110.

[0080] The congress public key or CPK encumbers the digital assets deposited in the congress pool by the members of the congress 110 in return for private key shares, and any digital assets deposited to the address associated with the congress pool (i.e., placed under full, partial or conditional control of the congress) by members or non-members of the congress 110 which have been deposited for reasons other than obtaining private key shares. Non-members or members may deposit digital assets to the address associated with the congress for various reasons.

[0081] Since the same congress public key may encumber both member deposits (i.e., digital assets provided by congress members in return for private key shares) and digital assets provided by members or non-members for other purposes, at least some deposits to the congress public key may be specially flagged to indicate the type of deposit. For example, a transaction that transfers a digital asset to the congress public key may include a flag, identifier or other attribute which indicates the nature of the deposit being made. By way of example, a transaction that transfers the digital asset to congress public key that is not made for the purpose of joining a congress or boosting a stake in congress membership may include a special identifier to indicate that the deposit is being made for another purpose. Such identifiers may be used by nodes 102 associated with the congress 110 when managing private key generation. More particularly, nodes 102 which deposit digital assets for the purpose of joining the group are allocated private key shares for the congress 110 (as a result of making the deposit of digital assets) while other nodes 102 which deposited digital assets for other purposes (e.g., to transfer to a sidechain) may not hold congress private key shares for the congress (i.e., corresponding to the congress public key).

[0082] The congress 110 may act as a self-governing group in which cooperative behaviour is enforced through the threat of confiscation of all or part of the member deposit. Non-cooperative or malicious members may have such digital assets confiscated by participation in a cooperative protocol by a number of honest members. Further, when a congress member wishes to leave the congress 110, they may withdraw their member deposit (i.e., request that the congress 110 transfer the member deposit back to that member's personal address). However, withdrawal of funds is only performed if a number of private key shares exceeding a threshold required to generate a valid digital signature are used by members of the group (i.e., the congress) to approve the withdrawal.

[0083] The threshold signature scheme implemented by the congress 110 may be of various types. For example, the threshold signature scheme can allow for sharing of signing power between n parties as long as at least a threshold number of private key shares have contributed towards generating a valid signature. Any subset smaller than the threshold cannot generate a valid signature. The threshold signature scheme may be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. For example, an ECDSA scheme may be of the type proposed by Ibrahim et al. in “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”, 2003 EIII 46th Midwest Symposium on Circuits and Systems, 1:276-280 (2003). This threshold signature scheme is an extension of a digital signature scheme which is an elliptic curve cryptography based algorithm in which t+1 key shares from a party of n key share holders are required to reconstruct a private key. The scheme may be used to construct a valid signature without having to reconstruct a private key and without any party having to reveal their key share to another party. Note that other suitable signature schemes scan be implemented by the congress 110.

[0084] Example Method that Employs Consensus Mechanism Involving a Congress to Allow A User to Authorise a Transaction with a Password

[0085] Referring now to FIGS. 3-8B, methods are illustrated that employ a consensus mechanism involving a congress to allow a user (referred to as a “requestor” herein) to authorise one or more transactions with a user-chosen password. As shown in FIG. 3, the consensus mechanism can be logically partitioned into a sequence of phases, including a phase 301 that establishes the congress, an initialisation phase 303 (which involves an initialisation transaction), a funding phase 305 (which involves a funding transaction), and a payment authorization phase 307 (which involves a pre-spending transaction and a spending transaction). The password is never exposed directly in any phase of the method. The entropy of the password is not required to be high (and thus can be low), which can improve the memorability of the password as the amount of information of the password is proportional to the entropy of the password. The payment authorization phase 307 can possibly be repeated multiple times in order for the requestor to transfer the funds specified in the funding transaction using the password. Furthermore, once the congress is established in phase 301, the operations of the initialisation phase 303, the funding phase 305, and the payment authorization phase 307 can be replicated for multiple users in order to allow multiple individual users to authorise one or more transactions with a user-chosen password.

[0086] In embodiments, the consensus mechanism utilizes a digital signature scheme that employs a bilinear map on an elliptic curve. Such a bilinear map is a form of pairing-based cryptography that uses a pairing between elements of two cryptographic groups to a third group with a mapping e. Consider two finite cyclic groups (G.sub.1=P,⋅), (G.sub.2,⋅) of the same prime order q such that the discrete logarithm problem is hard in both groups. A mapping e: G.sub.1×G.sub.1.fwdarw.G.sub.2 is called a bilinear map if and only if the following three conditions are satisfied: [0087] 1. Bilinearity: ∀P,Q∈G.sub.1, ∀a, b∈Z.sub.q*, e(aP,bQ)=e(P,Q).sup.ab. [0088] 2. Nondegeneracy: G.sub.1=P=>e(P,P)=G.sub.2. [0089] 3. The mapping e is computable in polynomial time.

[0090] A deterministic signature scheme using a bilinear map on an elliptic curve was disclosed in D. Boned, B. Lynn, H. Sachem. “Short Signatures from the Weil Pairing,” International Conference on the Theory and Application of Cryptology and Information Security, ASIACRYPT 2001, pp 514-532. In this scheme, security is proven under the random oracle model assuming suitably chosen G.sub.1,G.sub.2. More specifically, let the signer's secret key be x∈.sub.R Z.sub.q* and the corresponding public key y=g.sup.x is an element in G.sub.1=g. Let H:{0,1}*.fwdarw.G.sub.1 be a hash function. The steps for signing and verifying a message m are as follows: [0091] Sign(m): the signature σ on message m is H(m).sup.x (in G.sub.1). [0092] Verify(σ, m): accept if and only if e(g,σ)=e(y, H(m)).

[0093] The signature scheme of bone, Lynn and Sachem was generalised to a t-out-of-n threshold signature scheme in A. Boldyreva, “Efficient Threshold Signature, Multisignature and Blind Signature Schemes Based on the Gap-Diffie-Hellman-Group Signature Scheme,” PKC 2003, LNCS 2139, pp. 31-46, Springer-Verlag, 2003. In this case, any t signers in the group of n can sign a message m. Let the i.sup.th signer's secret key be x.sub.i ∈.sub.R Z.sub.q* and the corresponding public key y.sub.i=g.sup.x.sup.i is an element in G.sub.1=g. Here, the master secret x=Σ.sub.i x.sub.i L.sub.i, where the L.sub.i's are the Lagrange coefficients, which depend on which t values of i that are available. The master public key is y=g.sup.x, and the individual public keys y.sub.i=g.sup.x.sup.i. The steps for signing and verifying a message m are as follows: [0094] Sign(m): each of the t signers creates a share of the signature: σ.sub.i=H(m).sup.x.sup.i. Note that validity of each σ.sub.i can be checked by ensuring that e(g,σ.sub.i)=e(y.sub.i, H(m)). The signature a can be determined as σ=Π.sub.iσ.sub.i.sup.L.sup.i for t values of i. [0095] Verify(m,σ): accept it and only if e(g,σ)=e(y,H(m)).

[0096] The digital signature scheme used by embodiments of the consensus mechanism of FIGS. 3-8 expand upon the a t-out-of-n threshold signature scheme of Boldyreva by incorporating a user-chosen password into the digital signature scheme as is described below in detail. The phase 301 that establishes the congress includes operations 401-405 of FIG. 4. The initialisation phase 303 includes operations 501-537 of FIGS. 5A-5D. The funding phase 305 includes operations 601-605 of FIG. 6. The payment authorization phase 307 includes operations 701-751 of FIGS. 7A-7D for one embodiment of the present disclosure or possibly the operations 737′ to 751′ of FIG. 8 for another embodiment of the present disclosure.

[0097] Note that the operations performed on behalf of the requestor (or “Alice” in this example) are shown on the left side of FIGS. 3-8, while the operations performed by or on behalf the nodes 102 that are members of the congress are shown on the right side of FIGS. 3-8. The operations performed on behalf of the requestor (or parts thereof) can involve a digital wallet. Such digital wallet can be a hardware wallet, which typically uses a smartcard or USB device for certain functions (such as key generation, key storage, and transaction signing). Alternately, the digital wallet can be a hot wallet, which uses systems that are online and connected in some way to the Internet.

[0098] FIG. 4 illustrates details of the phase 301 that establishes the congress 110.

[0099] At operation 401, the nodes 102 that will participate as members of the congress are identified, thus establishing the congress 110. Techniques for establishing and maintaining the congress 110 are described in GB Patent Appl. No. 1705867.8 (Attorney Docket P510727/CEJ), filed on 11 Apr. 2017, and GB Patent Appl. No. GB1705869.4 (Attorney Docket P510728/CEJ), filed on 11 Apr. 2017.

[0100] At operation 403, the congress 110 determines parameters for the digital signature scheme that employ bilinear mappings on an elliptic curve (e.g., first group G1, second group G2, mapping function e, and hash function H).

[0101] At operation 405, the members of the congress 110 use a distributed protocol whereby the TEE for each member i of the congress determines and holds its private key share x.sub.i in the congress private key x. In this embodiment, x∈.sub.R Z.sub.q* according to the bilinearity condition of the bilinear mapping of the digital signature scheme. The distributed protocol also determines the congress public key (CPK) that corresponds to the congress private key x.

[0102] FIGS. 5A-5D illustrates details of the initialisation phase 303.

[0103] At operation 501, the requestor (Alice) generates an initialisation transaction T.sub.I. It is assumed that the requestor (Alice) has an account with a public key Pk. The initialisation transaction T.sub.I indicates or signals to the congress 110 a desire to set a password that is associated with the requestor (Alice). The initialisation transaction T.sub.I specifies an initialisation fee F.sub.I that is transferred from the requestor's account with a public key Pk and paid to CPK. In embodiments, the initialisation transaction T.sub.I can specify that the initialisation fee F.sub.I is locked by the congress public key CPK, and may therefore be spent by a transaction signed with a signature based on the corresponding congress private key x. Note that the initialisation fee F.sub.I will be transferred to congress 110 in return for processing the initialisation transaction T.sub.I and thus participating in the initialisation phase 303.

[0104] In embodiments, the initialisation transaction T.sub.I can include one or more transaction inputs that specify UTXO of the requestor's account and an associated unlocking script (e.g., scriptSig) that unlocks the UTXO as well as a transaction output that specifies a value equal to the initialisation fee F.sub.I with an associated locking script (e.g., scriptPubKey) that locks the initialisation fee F.sub.I with the congress public key CPK, and may therefore be spent by a spending transaction having a transaction input with an unlocking script (e.g., scriptSig) that provides the congress public key CPK and a signature based on the corresponding congress private key x. The initialisation transaction T.sub.I can possibly include another transaction output for change returned to the requestor's account, which represents the difference between the UTXO of the transaction input(s) and the initialisation fee F.sub.I less any implied transaction fee.

[0105] At operation 503, the requestor (Alice) broadcasts the initialisation transaction T.sub.I to the blockchain network 100 thereby communicating the initialisation transaction T.sub.I to the members of the congress 110. The operations of the requestor (Alice) then proceeds to operation 517.

[0106] At operation 505, nodes of the blockchain network 110 (which includes the members of the congress 110 and possibly other non-member nodes) validate the initialisation transaction T.sub.I, and a mining node of the blockchain network 100 (which need not be a member of the congress 110) can mine the validated initialisation transaction T.sub.I for storage in the blockchain of the blockchain network 100, which confirms the transfer of the initialisation fee F.sub.i to the CPK of the congress 110. Note that the initialisation transaction T.sub.I can be required to satisfy the requisite conditions of all mined transactions (for example, one such condition is that the initialisation transaction T.sub.I offers a sufficient transaction fee to miners).

[0107] At operation 507, each member i of the congress 110 receives and processes the initialisation transaction T.sub.I.

[0108] At operation 509, the TEE for each member i of the congress 110 determines the generator function g for the first group G1 by hashing the public key Pk belonging to the requestor (Alice) using the hash function H. In embodiments, the generator function g can be unique for the requestor (Alice) with overwhelming probability.

[0109] At operation 511, the TEE for each member i of the congress 110 uses the generator function g as determined in 509 to generate a quantity g.sup.xi based on its private key share x.sub.i. In embodiments, the quantity g.sup.xi can be obtained via a repeated application of the group G1 where the operation depends on the group—additive or multiplicative—and will correspond to a sum or exponentiation. In embodiments, the quantity g.sup.xi can be obtained from repeated application of the group G.sub.1 g:=H(Pk) with the repeated application of the group shown simply as exponentiation.

[0110] At operation 513, the TEE of each member i of the congress 110 generates a private message M(g.sup.xi) to the requestor (Alice). The private message M(g.sup.xi) includes the quantity g.sup.xi which can be encrypted with the public key Pk belonging to the requestor (Alice). In embodiments, the private message M(g.sup.xi) can be associated with the public key associated with the TEE of the member i and can be signed with the corresponding private key of the TEE of the member i. Note that the private messages M(g.sup.xi) can include certain blinded quantities that do not reveal the private key shares x.sub.i of the congress to the requestor (Alice), but allow the requestor (Alice) to verify the consistency of the quantities which can be based on the techniques described in Ibrahim et al., “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”, 2003 EIII 46th Midwest Symposium on Circuits and Systems, 1:276-280 (2003).

[0111] At operation 515, each member i of the congress 110 sends the private message M(g.sup.xi) to the requestor (Alice) and the operations of the members of the congress 110 proceed to 531.

[0112] At operation 517, the requestor (Alice) receives and processes the private messages M(g.sup.xi) sent by the members of the congress 110 to the requestor (Alice). The authenticity of each private message M(g.sup.xi) can be checked by verifying the signature of the private message M(g.sup.xi) using the corresponding public key associated with the TEE of the member i.

[0113] At operation 519, the requestor (Alice) determines whether the quantities g.sup.xi are consistent. The consistency check of 323 can be carried out using any one of a number of well-known verifiable secret sharing schemes. See https://en.wikipedia.org/wiki/Verifiable_secret_sharing. The consistency check of 323 can also be carried out using a public verifiable secret sharing scheme as described in Stadler, M., “Publicly verifiable secret sharing,” In International Conference on the Theory and Applications of Cryptographic Techniques, May 1996, pp. 190-199. These schemes can be used to (i) identify inconsistent shares (ii) check whether a quantity or share ‘secretly sent’ to a party differs from the blinded quantity or share which is broadcast, which can be based on the techniques described in Ibrahim et al. In order to carry out the consistency check, the quantities g.sup.xi can be decrypted using the private key belonging to the requestor (Alice) and corresponding to the public key Pk.

[0114] At operation 521, the requestor (Alice) generates a transaction T.sub.c1 reporting results of the consistency determination of 323 and broadcasts the transaction T.sub.c1 to the blockchain network 100 thereby communicating the transaction T.sub.c1 to the members of the congress 110. In embodiment(s), the results of the transaction T.sub.c1 can include a reference to any node that provided an inconsistent quantity g.sup.xi (such as the public key for the TEE of that node), or a null reference if all of the quantities g′ are consistent.

[0115] At operation 523, the requestor (Alice) evaluates the transaction T.sub.c1 to check whether it indicates that the quantities g′ are consistent. If so, the operations of the requestor (Alice) continue to 525 to 529; otherwise the operations of the requestor (Alice) can return to 501 to generate and broadcast another initialisation transaction T.sub.I.

[0116] At operation 525, the requestor (Alice) chooses or otherwise inputs a password Pw.

[0117] At operation 527, the requestor (Alice) determines the generator function g for the first group G1 by hashing the public key Pk using the hash function H.

[0118] At operation 529, the requestor (Alice) uses the generator function g to construct a public key y based on the password Pw and the quantities g.sup.xi and the operations of the requestor (Alice) in the initialisation phase ends. In embodiments, the public key y can be constructed as:

y=.sub.g.sup.PwΠ.sub.i(g.sup.x.sup.i).sup.L.sup.i=g.sup.Pw+x,  (1) [0119] where L.sub.i are the appropriate Lagrange coefficients.

[0120] Note that, despite Pw being low-entropy, public key y is unique with overwhelming probability since Pk is and hence g will be as well.

[0121] At operation 531, the members of the congress 110 receive and process the transaction T.sub.c1.

[0122] At operation 533, each member i of the congress 110 evaluates the transaction T.sub.c1 to check whether it indicates that the quantities g′ are consistent. If so, the operations continue to 535; otherwise the operations continue to 537.

[0123] At operation 535, the congress 110 can take steps to distribute the initialisation fee F.sub.I to the members of the congress 110 and the operations of the members of the congress 110 in the initialisation phase ends.

[0124] At operation 537, the congress 110 can take steps to return the initialisation fee F.sub.I to the requestor (Alice) (as the requestor is not at fault in this phase) and confiscate the security deposit for any malicious member node of the congress 110 that provided an inconsistent quantity g.sup.xi (as reported by the results of the transaction T.sub.c1). In embodiments, the congress members can employ the proof-of-stake alternate chain (e.g., ghost chain) to confiscate the security deposit for any malicious member node of the congress 110. The confiscated security deposit can possibly be transferred to the other members of the congress 110 or burned by transferring the confiscated security deposit to an unspendable address. After 527, the operations of the members of the congress 110 in the initialisation phase can end.

[0125] FIG. 6 illustrates details of the funding phase 305.

[0126] At operation 601, the requestor (Alice) generates a funding transaction T.sub.F, which specifies funds f of the requestor (Alice) where some or all of the funds f may be transferred using the password Pw. The funding transaction T.sub.F also specifies i) a transaction deposit fraction where the transaction deposit amount D.sub.T*f will need to be provided with any attempt to transfer some or all of the funds f using a password, ii) the generator function g, and iii) the public key y that locks the funds f.

[0127] In this embodiment, the funds f are locked (encumbered) by the public key y and may therefore be spent by one or more signed transactions (each of which is referred to the signed spending transaction, T.sub.S) that contain, as meta data, a spending signature σ.sub.s which is generated from the password Pw and the quantities σ.sub.s,i sent from a threshold number of congress members in 735.

[0128] In this embodiment, nodes of the to the blockchain network 100 (which can include members of the congress 110 and nodes that are not members of the congress 110) can operate to verify the spending signature σ.sub.s with the public key y (see operation 743 below) as part of validating the signed spending transaction T.sub.S, which in effect releases the lock (encumbrance) involving the public key y on the funds f of the funding transaction T.sub.F.

[0129] In embodiments, the funding transaction T.sub.F can include one or more transaction inputs that specify UTXO of the requestor's account and an associated unlocking script (e.g., scriptSig) that unlocks the UTXO as well as a transaction output that specifies a value equal to the funds f with an associated locking script (e.g., scriptPubKey) that locks the funds f with the public key y, and may therefore be spent by a spending transaction having a transaction input with an unlocking script (e.g., scriptSig) that provides the public key y and the spending signature σ.sub.s derived from the password Pw and the congress private key x. The funding transaction T.sub.F can also possibly include other transaction outputs (unspendable) that specify the transaction deposit fraction D.sub.T and the generator function g. The funding transaction T.sub.F can also possibly include another transaction output for change returned to the requestor's account, which represents the difference between the UTXO of the transaction input(s) and the the funds f less any implied transaction fee.

[0130] At operation 603, the requestor (Alice) broadcasts the funding transaction T.sub.F to the blockchain network 100.

[0131] At operation 605, nodes of the blockchain network 100 (which includes members of the congress 110 and possibly other non-member nodes) validate the funding transaction T.sub.F, and a mining node of the blockchain network 100 (which need not be a member of the congress 110) can mine the validated funding transaction T.sub.F for storage in the blockchain of the blockchain network 100. Note that the funding transaction T.sub.F can be required to satisfy the requisite conditions of all mined transactions (for example, one such condition is that the funding transaction T.sub.F offers a sufficient transaction fee to miners).

[0132] FIGS. 7A-7D illustrate details of the payment authorization phase 307.

[0133] At operation 701, the requestor (Alice) generates an unsigned spending transaction T.sub.S, which refers to the funds f locked by the funding transaction T.sub.F. The unsigned spending transaction T.sub.S (when signed and broadcasted in 739 and 741 below) will transfer to a recipient some portion of the funds f.

[0134] In embodiments, the unsigned spending transaction T.sub.S can include a transaction input that refers to the funds flocked by the funding transaction T.sub.F of the requestor as well as a first transaction output that specifies a value equal to some portion of the funds f with an associated locking script (e.g., scriptPubKey) that locks this value based on the public key of the recipient, and may therefore be spent by a spending transaction having a transaction input with an unlocking script (e.g., scriptSig) that provides the recipient's public key and a signature based on the private key of the recipient.

[0135] At operation 703, the requestor (Alice) generates a pre-spending transaction T.sub.PS that transfers the transaction deposit amount D.sub.T*f locking it under the congress public key CPK. The pre-spending transaction T.sub.PS also includes a spending fee F.sub.s, the hash of the corresponding unsigned spending transaction T.sub.S (i.e., H(T.sub.S)) and a public key Pk′. The spending fee F.sub.s is a fee that the requestor (Alice) is willing to provide to the congress 110 for processing the pre-spending transaction T.sub.PS and the spending transaction T.sub.S. The public key Pk′ is an address of an account where the requestor wishes to move funds. This address may or may not be the same as the public key Pk used to transfer the deposit.

[0136] In embodiments, the pre-spending transaction T.sub.PS can include one or more transaction inputs that refer to UTXO of the requestor's account and an associated unlocking script (e.g., scriptSig) that unlocks the UTXO as well as a transaction output that specifies a value equal to the amount (D.sub.T*f) with an associated locking script (e.g., scriptPubKey) that locks the amount (D.sub.T*j) with the congress public key CPK, and may therefore be spent by a spending transaction having a transaction input with an unlocking script (e.g., scriptSig) that provides the congress public key CPK and a signature which is generated using the congress private key x. The pre-spending transaction T.sub.PS can possibly include other transaction outputs (unspendable) that specify the spending fee F.sub.s, the hash of the corresponding unsigned spending transaction T.sub.S (i.e., H(T.sub.S)) and the public key Pk′. The pre-spending transaction T.sub.PS can possibly include another transaction output for change returned to the requestor's account, which represents the difference between the UTXO of the transaction input(s) and the amount (D.sub.T*f) less any implied transaction fee.

[0137] At operation 705, the requestor (Alice) broadcasts the pre-spending transaction T.sub.PS to the blockchain network 100 thereby communicating the pre-spending transaction T.sub.PS to the members of the congress 110, and the operations of the requestor (Alice) proceeds to 723.

[0138] At operation 707, nodes of the blockchain network 100 (which includes members of the congress 110 and possibly other non-member nodes) validate the pre-spending transaction T.sub.PS, and a mining node (which need not be a member of the congress 110) can mine the validated pre-spending transaction T.sub.PS for storage in the blockchain of the blockchain network 100, which confirms the transfer of the transaction deposit amount D.sub.T*f Note that the pre-spending transaction T.sub.PS can be required to satisfy the requisite conditions of all mined transactions (for example, one such condition is that the pre-spending transaction T.sub.PS offers a sufficient transaction fee to miners).

[0139] At operation 709, the members of the congress 110 receive and process the pre-spending transaction T.sub.PS to determine if the spending fee F.sub.s specified by the pre-spending transaction T.sub.PS is sufficient. The sufficiency of the spending fee F.sub.s can depend on the amount of computational work that is required to process the pre-spending transaction T.sub.PS (which includes the operations 709 to 749 as described below).

[0140] At operation 711, the members of the congress 110 evaluate the determination of sufficiency of the spending fee F.sub.s. If the spending fee F.sub.s is determined to be insufficient, the operations continue to 713; otherwise (for the case where the spending fee F.sub.s is determined to be sufficient) the operations continue to 715-719.

[0141] In embodiments, the determination of sufficiency of the spending fee F.sub.s in 709 can involve a special unit of work that reflects the computational work of the operations carried out by the members of the congress, which is similar to “gas” in the Ethereum blockchain network. Each particular computational operation carried out by the members of congress 110 in processing the pre-spending transaction T.sub.PS is assigned a specific amount of this special unit in accordance with the computational resources required to execute that particular computation operation. The specific amounts of this special unit for all of the computational operation carried out by the members of congress 110 in processing the pre-spending transaction T.sub.PS are totaled together and multiplied by a price per special unit to determine a requisite threshold for the spending fee F.sub.s. If the spending fee F.sub.s exceeds this threshold, the spending fee F.sub.s is deemed sufficient in 711. If the spending fee F.sub.s does not exceed this threshold, the spending fee F.sub.s is deemed insufficient in 711.

[0142] At operation 713, the congress 110 can take steps to bypass the further processing for the pre-spending transaction T.sub.PS (operations 715-719 and operations 729-733) as well as follow-on operations for the spending transaction T.sub.S (operations 741-749)

[0143] At operation 715, the TEE for each member i of the congress 110 uses its private key share xi and the hash of the unsigned spending transaction T.sub.S (denoted H(T.sub.S)) as included in the pre-spending transaction T.sub.PS to generate a corresponding quantity σ.sub.s,i. In embodiment(s), the quantity σ.sub.s,i can be generated as σ.sub.s,i=H(T.sub.s).sup.x.sup.i. Note that other members of the congress 110 do not know the spending transaction T.sub.S at this stage.

[0144] At operation 717, the TEE of each member i of the congress 110 generates a private message M(σ.sub.s,i) to the requestor (Alice). The private message M(σ.sub.s,i) includes the quantity σ.sub.s,i generated in 363 which can be encrypted with the public key Pk of the requestor (Alice). In embodiments, the private message M(σ.sub.s,i) can be associated with the public key of the TEE of the member i and can be signed with the corresponding private key of the TEE of the member i. Note that the private messages M(σ.sub.s,i) can include certain blinded quantities that do not reveal the private key shares x.sub.i of the congress to the requestor (Alice), but allow the requestor (Alice) to verify the consistency of the quantities σ.sub.s,i, which can be based on the techniques described in Ibrahim et al., “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”, 2003 EIII 46th Midwest Symposium on Circuits and Systems, 1:276-280 (2003).

[0145] At operation 719, each member i of the congress 110 sends the private message M(σ.sub.s,i) to the requestor (Alice), and the operations proceed to 729.

[0146] At operation 721, the requestor (Alice) receives and processes the private messages M(σ.sub.s,i) sent by the members of the congress 110 to the requestor (Alice). The authenticity of each private message M(σ.sub.s,i) can be checked by verifying the signature of the private message M(σ.sub.s,i) using the corresponding public key associated with the TEE of the member i.

[0147] At operation 723, the requestor (Alice) determines whether the quantities σ.sub.s,i included in the received private messages M(σ.sub.s,i) are consistent. The consistency check of 723 can be carried out using any one of the verifiable secret sharing schemes described above for 519. In order to carry out the consistency check, the quantities σ.sub.s,i can be decrypted using the private key belonging to the requestor (Alice) and corresponding to the public key Pk.

[0148] At operation 725, the requestor (Alice) generates a transaction T.sub.c2 reporting results of the consistency determination of 723 and broadcasts the transaction T.sub.c2 to the blockchain network 100 thereby communicating the transaction T.sub.c2 to the members of the congress 110. In embodiment(s), the results of the transaction T.sub.c2 can include a reference to any node that provided an inconsistent quantity σ.sub.s,i (such as the public key for the TEE of that node), or a null reference if all of the received quantities σ.sub.s,i are consistent.

[0149] At operation 727, the requestor (Alice) evaluates the transaction T.sub.c2 to check whether it indicates that the quantities σ.sub.s,i are consistent. If so, the operations of the requestor (Alice) continue to 735-739; otherwise the operations of the requestor (Alice) can return to 701 to generate another unsigned spending transaction T.sub.S and follow-on processing.

[0150] At operation 729, the members of the congress 110 receive and process the transaction T.sub.c2 to check whether it indicates that the received quantities σ.sub.s,i are consistent.

[0151] At operation 731, each member i of the congress 110 determines whether the processing of 729 indicates that the received quantities σ.sub.s,i are consistent. If so, the operations continue to 741; otherwise the operations continue to 733.

[0152] At operation 733, the congress 110 can take steps to transfer the transaction deposit amount D.sub.T*f specified by the pre-spending transaction T.sub.SP and locked under the congress public key CPK to the public key Pk′ specified by the requestor (as the requestor is not at fault in this phase) and confiscate the security deposit for any malicious member node of the congress 110 that provided an inconsistent quantity σ.sub.s,i (as reported by the results of the transaction T.sub.c2) and then bypass follow-on operations for the spending transaction T.sub.S. In embodiments, the congress members can employ the proof-of-stake alternate chain (e.g., ghost chain) to confiscate the security deposit for any malicious member node of the congress 110. The confiscated security deposit can possibly be transferred to the other members of the congress 110 or burned by transferring the confiscated security deposit to an unspendable address. After 733, the operations of the members of the congress 110 in the payment authorization phase can end.

[0153] At operation 735, the requestor (Alice) uses the hash of the unsigned spending transaction T.sub.S (i.e., H(T.sub.S)), the password and the quantities σ.sub.s,i received from a threshold number of Congress members to generate a signing signature σ.sub.s The threshold number of Congress members can be determined in the initialisation phase when the private key shares xi are distributed to the congress members. In embodiment(s), the signing signature σ.sub.s can be generated as σ.sub.s=H(T.sub.S).sup.PwΠ.sub.iσ.sub.s,i.sup.L.sup.i=H(T.sub.S).sup.Pw+x.

[0154] At operation 737, the requestor (Alice) includes the signature σ.sub.s generated in 735 as the signature for the spending transaction T.sub.S (which was initially generated in 701). In one example, the signature σ.sub.s can be included as part of the unlocking script (e.g., scriptSig) of the transaction input of the spending transaction T.sub.S where the transaction input refers to the funds f locked by the public key y.

[0155] At operation 739, the requestor (Alice) broadcasts the spending transaction T.sub.S (now signed with the signing signature σ.sub.s) to the blockchain network 100.

[0156] At operation 741, nodes of the blockchain network (which includes members of the congress 110 and possibly other non-member nodes) validate the spending transaction T.sub.S, which includes operations that verify the signature σ.sub.s of the spending transaction T.sub.S against the public key y of the corresponding funding transaction T.sub.F. Such verification can use the mapping function e of the digital signature scheme and the generator function g specified in funding transaction T.sub.F. For example, such verification can accept the signature σ.sub.s of the spending transaction T.sub.S if and only if e(g,σ.sub.s)=e(y, H(T.sub.S)). In embodiments, the operations that verify the signature σ.sub.s of the spending transaction T.sub.S against the public key y can be specified by the unlocking script (e.g., scriptSig) of the transaction input of the spending transaction T.sub.S (where the transaction input refers to the funds f locked by the funding transaction T.sub.F of the requestor) as well as the locking script (e.g., scriptPubKey) of corresponding transaction output of the referenced funding transaction T.sub.F of the requestor (which locks the funds f using the public key y).

[0157] At operation 743, the nodes of the blockchain network (which include members of the congress 110 and possibly other non-member nodes) evaluate the validation of the funding transaction T.sub.F performed in 741. If the validation of the funding transaction T.sub.F was successful (and thus the signature σ.sub.s of the spending transaction T.sub.S has been successfully verified against the public key y of the corresponding funding transaction T.sub.F), the operations continue to 745 and 747. Otherwise (for the case where the validation of the funding transaction T.sub.F failed, possibly because the verification of signature σ.sub.s of the spending transaction T.sub.S against the public key y of the corresponding funding transaction T.sub.F failed), the operations continue to 749.

[0158] At operation 745, a mining node (which need not be a member of the congress 110) can mine the spending transaction T.sub.S for storage in the blockchain of the blockchain network 100, which confirms the transfer of the portion of funds f to the recipient of the spending transaction T.sub.S.

[0159] At operation 747, the members of the congress 110 can take steps to transfer the amount (D.sub.T*f−F.sub.s) as referred to in the pre-spending transaction T.sub.S p and locked by the congress public key CPK to the public key Pk′ and transfer the spending fee F.sub.s to the members of the congress 110. This can involve the congress 110 generating a transaction with a first transaction input that refers to the transaction output of the pre-spending transaction T.sub.S p locked under the congress public key CPK with an unlocking script (e.g., scriptSig) that includes a congress-generated signature which releases the lock under the congress public key CPK and a first transaction output that transfers the amount (D.sub.T*f−F.sub.s) to the public key Pk′. The transaction can also include a second transaction input that refers to the transaction output of the pre-spending transaction T.sub.S p locked under the congress public key CPK with an unlocking script (e.g., scriptSig) that includes the congress-generated signature which releases the lock under the congress public key CPK and a second transaction output that transfers F.sub.s to the CPK of the congress 110. The nodes of the blockchain network (which include members of the congress 110 and possibly non-member nodes) can validate this transaction, and a mining node (which need not be a member of the congress 110) can mine the validated transaction for storage in the blockchain of the blockchain network 100.

[0160] At operation 749, the spending transaction T.sub.S is deemed invalid, and the congress 110 can take steps to confiscate the transaction deposit amount D.sub.T*f referred to in the pre-spending transaction T.sub.S p and locked by the congress public key CPK and distribute the transaction deposit amount D.sub.T*f to the members of the congress 110. This can involve transactions that transfers shares in the transaction deposit amount D.sub.T*f to the members of the congress 110 where each transaction includes a transaction input that refers to the pre-spending transaction T.sub.S p whose output transfers the transaction deposit amount D.sub.T*f to the CPK of the congress 110. The transaction input also includes an unlocking script (e.g., scriptSig) that includes a congress-generated signature derived from the congress private key x (which utilises their private key shares x.sub.i). This unlocking script releases the lock on the transaction deposit amount D.sub.T*f locked under the CPK in the previous transaction. The nodes of the blockchain network (which can include the members of the Congress and non-member nodes) can validate these transactions, and one or more mining nodes (which need not be a member of the Congress) can mine the validated transactions for storage in the blockchain of the blockchain network 100.

[0161] In an alternate embodiment, the funding transaction T.sub.F can specify that the funds f are locked by the congress public key CPK (instead of the public key y as described above) and can therefore be unlocked by a threshold of congress members who collaborate to sign a transaction using the congress private key x (by utilising their private key shares x.sub.i). In this case, the signed spending transaction T.sub.S includes the public key y and the members of congress 110 operate to verify the signing signature σ.sub.s of the signed spending transaction T.sub.S using public key y. Thus, in this embodiment, only congress members need to verify the signature σ.sub.s of the signed spending transaction T.sub.S against the public key y (see 743′ to 751′). If a threshold number of members of the congress 110 successfully verify the signing signature σ.sub.s of the signed spending transaction T.sub.S using the public key y, the members of congress collaborate to construct and sign a secondary spending transaction using the congress private key x (by utilising their private key shares x.sub.i). The secondary spending transaction can be replicated from the spending transaction T.sub.S but has an unlocking script (e.g., scriptSig) for the transaction input that refers to the funds f locked by the funding transaction T.sub.F of the requestor where such unlocking script includes a congress-generated signature derived from the congress private key x. This unlocking script releases the lock on the funds f locked under the CPK in the funding transaction T.sub.F. Also note that in this embodiment, the transaction deposit amount D.sub.T*f transferred by the pre-spending transaction T.sub.PS is locked under the CPK of the congress 110. In this embodiment, the operations of the spending phase can be modified as shown in FIGS. 8A and 8B.

[0162] At operation 735′, the requestor (Alice) generates the signing signature σ.sub.s using the password P.sub.w and the quantities σ.sub.s,i received from a threshold number of Congress members. The threshold number of Congress members can be determined in the initialisation phase when the private key shares x.sub.i are distributed to the congress members. In embodiment(s), the signing signature σ.sub.s can be generated as σ.sub.s=H(T.sub.s).sup.PwΠ.sub.i σ.sub.s,i.sup.L.sup.i=H(T.sub.s).sup.Pw+x.

[0163] At operation 737′, the requestor (Alice) includes the signature σ.sub.s as part of the spending transaction T.sub.S (which was initially generated in 701).

[0164] At operation 739′, the requestor (Alice) broadcasts the spending transaction T.sub.S (which includes the signing signature σ.sub.s) to the blockchain network 100, thereby communicating the spending transaction T.sub.S to the members of the congress 110.

[0165] At operation 741′, the members of the congress 110 process the spending transaction T.sub.S to verify the signing signature σ.sub.s of the spending transaction T.sub.S using the public key y included in the spending transaction T.sub.S. Such verification can use the generator function g included in the funding transaction T.sub.F and the mapping function e of the digital signature scheme. For example, such verification can accept the signing signature σ.sub.s of the spending transaction T.sub.S if and only if e(g,σ)=e(y,H(T.sub.S)).

[0166] At operation 743′, the members of the congress 110 alone evaluate the verification of the signing signature σ.sub.s of the spending transaction T.sub.S using the public key y performed in 741′. If the verification of signature σ.sub.s of the spending transaction T.sub.S fails, the operations continue to 745′. Otherwise (for the case where the verification of the signing signature σ.sub.s of the spending transaction T.sub.S is successful), the operations continue to 747′ to 755′.

[0167] At operation 745′, the spending transaction T.sub.S is deemed invalid, and the congress 110 can take steps to confiscate the transaction deposit amount D.sub.T*f specified by the pre-spending transaction T.sub.S p and locked under the congress public key CPK and distribute the transaction deposit amount D.sub.T*f to the members of the congress 110. This can involve transactions that transfer shares in the transaction deposit amount D.sub.T*f to the members of the congress 110 where each transaction includes a transaction input that refers to the transaction output of the pre-spending transaction T.sub.S p locked under the congress public key CPK. The transaction input also includes an unlocking script (e.g., scriptSig) that includes a congress-generated signature derived from the congress private key x (which utilises their private key shares x.sub.i). This unlocking script releases the lock on the transaction deposit amount D.sub.T*f locked under the congress public key CPK in the pre-spending transaction T.sub.S p. The nodes of the blockchain network (which can include the members of the Congress and non-member nodes) can validate these transactions, and one or more mining nodes (which need not be a member of the Congress) can mine the validated transactions for storage in the blockchain of the blockchain network 100.

[0168] At operation 747′, a mining node (which need not be a member of the congress 110) can mine the spending transaction T.sub.S for storage in the blockchain of the blockchain network 100.

[0169] At operation 749′, members of congress 110 (and no other non-member nodes) collaborate to generate a signature for the spending transaction T.sub.S using the congress private key x (which utilises their private key shares x.sub.i).

[0170] At operation 751′, members of the congress 110 (and no other non-member nodes) construct a secondary spending transaction by replicating the spending transaction T.sub.S. The congress-generated signature of 749′ is included in the secondary spending transaction to release the lock on the funds funder the CPK as specified in the funding transaction T.sub.F.

[0171] At operation 753′, nodes of the blockchain network (which includes members of the congress 110 and possibly non-member nodes) validate the secondary spending transaction, and a mining node (which need not be a member of the congress 110) can mine the validated secondary spending transaction for storage in the blockchain of the blockchain network 100.

[0172] At operation 755′, members of the congress 110 can take steps to transfer the amount (D.sub.T*f−F.sub.s) specified by the pre-spending transaction T.sub.S p and locked under the congress public key CPK to the public key Pk′ and transfer the spending fee F.sub.s to the members of the congress 110. This can involve the congress 110 generating a transaction with a first transaction input that refers to the transaction output of the pre-spending transaction T.sub.S p locked under the congress public key CPK with an unlocking script (e.g., scriptSig) that includes the congress-generated signature of 749′ (which releases the lock under the CPK) and a first transaction output that transfers the amount (D.sub.T*f−F.sub.s) to the public key Pk′. The transaction can also include a second transaction input that refers to the transaction output of the pre-spending transaction T.sub.S p locked under the congress public key CPK with an unlocking script (e.g., scriptSig) that includes the congress-generated signature of 749′ (which releases the lock under the CPK) and a second transaction output that transfers F.sub.s to the CPK of the congress 110. The nodes of the blockchain network (which include members of the congress 110 and possibly non-member nodes) can validate this transaction, and a mining node (which need not be a member of the congress 110) can mine the validated transaction for storage in the blockchain of the blockchain network 100.

[0173] Note that nodes of the blockchain network 100 that are not members of the congress 110 do not participate in verifying the spending signature σ.sub.s of the spending transaction T.sub.S using the public key y in 741′ and 743′. This is different from operations 741 and 743 of the embodiment of FIGS. 7A-7D where members of the congress 110 as well as non-members nodes can participate in validating the spending transaction T.sub.S.

[0174] Note that the embodiment of FIGS. 7A-7D can be efficient for large congresses, since it does not require the congress 110 generate a signature for the spending transaction T.sub.S using the congress private key x (which utilises their private key shares x.sub.i) and validate this signature against CPK of the corresponding funding transaction T.sub.F. However, the embodiment of FIGS. 8A-8B has the advantage that it could be implemented by a ‘second layer’ protocol. For example, it could be implemented on the Bitcoin blockchain network without the need to modify Bitcoin consensus rules.

[0175] The security of the improved digital signature scheme described herein is a function of the length of the password Pw and D.sub.T. In the initialisation phase, choosing g:=H(Pk), where Pk in the public key of the account from which the fee F.sub.I is transferred, means that g will be unique to the requestor, since (we assume) only the requestor has the private key corresponding to Pk, which is necessary to authorise the transfer of the fee F.sub.I.

[0176] Consider the following attack: An adversary would like to spend some funds f, without knowledge of the corresponding password Pw. The adversary would broadcast a pre-spending transaction T.sub.ps, which transfers the required deposit D.sub.T*f to the congress public key CPK and specifies a public key Pk for which they hold the private key. The pre-spending transaction T.sub.ps also specifies H(T.sub.s), where T.sub.s spends the funds to themselves. The adversary will receive σ.sub.i=H(T.sub.s).sup.x.sup.i from the congress. However, since the adversary does not know the password Pw, it must construct a through repeated guessing of Pw. Each time the guess of Pw fails, the adversary loses D.sub.T*f. Let us say that D.sub.T=1/25, if the password Pw consists of a two-digit numeric ‘PIN’, then 50 trials, on average, are required to guess correctly, which requires the spending of 2f (twice the funds in the account). The attack is therefore not viable from an economic point of view.

[0177] In other embodiments, the requestor may specify other options for transferring the digital assets locked by the funding transaction, such as by the ‘regular method’ of signing with a private key s held by the requestor. In this case, the requestor may prefer to transact using the regular method, since it would be cheaper than using a password (because it would not require any fee to be paid to the congress). In this scenario, the transaction processing for the pre-spending transaction and spending transaction based upon the requestor chosen password might only be used if the requestor loses the private key s.

[0178] In yet other embodiments, one or more transactions as described herein can be mined for storage on the blockchain irrespective of whether or not verification of the respective signatures of the transactions is successful.

[0179] While the examples described above have referred to certain proof-of-work blockchain networks (such as the Bitcoin blockchain network), the methods described herein may also be used with other types of proof-of-work blockchain networks and possibly other proof-of-stake blockchain networks.

[0180] The methods described above have been generally described as being performed at a node, but features of the method rely on cooperation with other nodes and could be performed elsewhere.

[0181] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.