Method related to blockchain network

Abstract

To provide a computer-implemented method and an electronic device for updating private key share distributions.SOLUTION: A method includes: providing an enclave public key to a hub, from an enclave associated with an execution environment at a node; establishing a channel with the hub by broadcasting, to a blockchain network, a funding transaction which encumbers a digital asset with first to third public keys. The encumbrance of the digital asset may be removed by both first signature generated from a first private key and second signature generated from a second private key, or a third signature valid for the third public key, the third public key being associated with a group; receiving a commitment transaction encrypted with the enclave public key; detecting a failure; and issuing a failsafe activation request to the group using data from the enclave.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates generally to distributed ledgers and more particularly to off-blockchain channels. The present invention is particularly, but not exclusively, related to providing a fail-safe mode upon failure of off-blockchain channels established between participants for the purpose of electronic communication and exchange. Such channels, and communications / transfers conducted over them, may be vulnerable to attacks or exploitation upon failure in the network. [Background technology]

[0002] The term "blockchain" is used herein to include all forms of electronic, computer-based, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although reference may be made herein to Bitcoin for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with various Bitcoin protocols, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system of blocks that consist of transactions and other information. In Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, so that together they create a permanent, immutable record of all transactions that have been written to the blockchain since inception. Transactions contain small programs called scripts that are embedded in the transaction's inputs and outputs, and the scripts specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Some network nodes, acting as miners, work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, in Bitcoin, a software client installed on the node performs this validation for transactions that reference unspent transaction outputs (UTXOs). Validation may be performed by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and the transaction can be written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the node that receives it, and if the transaction is valid, that node relays it to other nodes in the network; and ii) be added to a new block constructed by miners; and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered agreed upon once enough blocks have been added to the blockchain to make it effectively irreversible.

[0005] Scalability within blockchain protocols, including Bitcoin, has been a topic of much discussion within the cryptocurrency community. The question of how to enable scaling raises a variety of technical challenges. For example, because blockchain networks operate by a “gossip protocol” in which all state changes to the ledger are broadcast to all participants, and consensus on the state is agreed upon based on the gossip protocol, all nodes in the blockchain network must know about all transactions that occur globally. This global tracking of transactions may limit the volume or frequency of transactions in at least some blockchain networks. For example, as realized at the time of writing, Bitcoin is likely not able to directly replace existing high-volume electronic payment systems such as Visa®. In fact, it is expected that performing a Visa® transaction with Bitcoin would consume 400 terabytes of data per year. Many nodes in existing blockchain networks cannot handle this amount of bandwidth and storage.

[0006] To accommodate larger transaction volumes, off-chain (i.e., off-blockchain) known as “payment channels” have been proposed. For example, an off-chain payment channel called the “Lighting Network” is described in “The Bitcoin Lighting Network: Scalable Off-Chain Instant Payments” by Poon and Dryja (January 14, 2016). According to the Lighting Network, transactions of value occur off-blockchain. The Lighting Network describes a technique whereby commitment transactions previously exchanged off-chain can be broadcast to the blockchain if certain non-cooperative or adversarial actions occur after the payment channel is opened. The Lighting Network includes safeguards that remove the incentive for participants to broadcast stale commitment transactions that do not reflect the current state of the payment channel. For example, when a new commitment transaction is exchanged to update the state of a payment channel (e.g., to transfer value from one participant to another), a secret value associated with the previous commitment transaction is shared from one party to another. This value may be used in a breach remedy transaction (BRT). More specifically, if a participant node detects that another node is broadcasting an stale commitment transaction and attempting to commit the balance reflected in the stale commitment transaction to the blockchain, the participant node may rather use that value to claim all digital assets in the payment channel.Under this breach remedy scheme, the commitment transaction is locked so that the party who generated the signature for the commitment transaction (typically the party who broadcasts the commitment transaction to the blockchain network) is required to wait before the digital assets associated with the commitment transaction can be spent. For example, the party may be required to wait 1000 blocks after broadcasting the commitment transaction before their transaction attempting to spend the digital assets is added to the blockchain. This waiting period allows the other party to issue a breach remedy transaction if the commitment transaction does not reflect the current state of the payment channel. Summary of the Invention

[0007] Payment channels are typically configured such that participants in a payment channel can transfer value off-chain, but can forward such transfers to the blockchain network if they wish to leave the payment channel. This can occur, for example, if a hub, to which they have a payment channel, becomes unresponsive. However, if a large number of payment channels fail, the blockchain network may not have the capacity to process the large number of transactions that are suddenly requested to be written to the blockchain. For example, if a hub of a size comparable to the Visa® network fails, the blockchain network may not be able to effectively process all the transactions that are suddenly broadcast to the blockchain network. Thus, there are serious technical issues related to the network resilience and the ability to process transactions in the event of a network failure.

[0008] For example, if a node broadcasts a stale commitment transaction (i.e., a commitment transaction that does not reflect the current state of the payment channel) to the blockchain network during such a failure, the breaching rescue transaction may not be added to the blockchain network rapidly enough to prevent the stale commitment transaction from being targeted by the breaching rescue transaction due to the transaction bottleneck resulting from the failure, and thus the payment channel may be vulnerable to attacks during the widespread failure.

[0009] Thus, a need exists for improved security techniques for establishing links or channels between parties for electronic transactions.

[0010] According to the present invention there is therefore provided a method as defined in the accompanying claims. The present invention may also be referred to as a security method / system. The present invention may also be referred to as a cryptographic security method. The present invention may provide resilience in a blockchain network in the event of node failure. The present invention may prevent or at least reduce the possibility of exploitation in such situations.

[0011] As described in more detail below, techniques for setting up channels for off-chain transfers are described.

[0012] More specifically, a congress is used during channel setup. A congress is a group of nodes that any node in a blockchain network can join by submitting a sufficient stake (a “member deposit”) to a pool of digital assets associated with the congress (a “congress pool”). For example, a node can join a congress by transferring digital assets, such as digital currency (e.g., Bitcoin), tokens, or other stake or value, to an account associated with the congress. A congress may be secured, in part, through the distributed generation of private key shares. Each private key share may be used by its owner to generate partial signatures for transactions. A threshold signature scheme may be used to generate valid signatures for such transactions using at least a threshold number of partial signatures. Member deposits may be forfeited for malicious activity.

[0013] Advantageously, congress nodes may be configured to implement a fail-safe mode in which such nodes may close (payment) channels if the hub stops operating according to a predefined protocol. For example, if the hub becomes unresponsive, congress nodes may implement a fail-safe protocol to close payment channels in a manner that reduces the risk of the blockchain network becoming overwhelmed with transactions attempting to close the channels. For example, congress may perform batch closures in which multiple payment channels are closed in a single transaction. Additionally, congress may stagger the closures such that at least some channel closures are delayed.

[0014] Thus, according to the present invention, there may be provided a computer-implemented method, comprising: providing an enclave public key from an enclave associated with a trusted execution environment at the node to a hub; establishing a channel with the hub by broadcasting a funding transaction to the blockchain network that encumbrances the digital asset with a first public key, a second public key, and a third public key, where the encumbrance is lifted by: 1) both a first signature generated from a first private key corresponding to the first public key and a second signature generated from a second private key corresponding to the second public key; or 2) a third signature valid for a third public key, the third public key being associated with a group; receiving a commitment transaction at the enclave from the hub, the commitment transaction encrypted with the enclave public key; detecting a failure of the hub; and issuing a fail-safe activation request to the group using data from the enclave based on the commitment transaction.

[0015] A channel may be referred to as an “exchange channel,” a “communication channel,” or a “payment channel.” For ease of reference, the term “payment channel” may be used.

[0016] In some implementations, the failsafe activation request specifies a block number of a block recently added to a blockchain of the blockchain network, and the group is configured to ignore a failsafe activation request that is determined to be expired based on the block number specified in the failsafe activation request and based on the current block number of the block recently added to the blockchain.

[0017] In some implementations, the method further includes: determining that the failsafe mode is not running and that the failsafe activation request has expired; and issuing another failsafe activation request to the group, where the another failsafe activation request includes a new block number of the new most recent block that was added to the blockchain.

[0018] In some implementations, issuing the failsafe activation request includes automatically posting the failsafe activation request online in response to detecting a malfunction of the hub.

[0019] In some implementations, the failsafe activation request specifies a fee to be offered by the node that closes the channel.

[0020] In some implementations, the method includes exchanging value with other nodes via the sidechain after the group deploys the sidechain in response to the failsafe activation request.

[0021] In some implementations, the failsafe activation request is generated within the enclave and signed using an enclave private key that is related to the enclave public key.

[0022] In some implementations, the method further includes decrypting the commitment transaction, determining a balance associated with the channel, and determining a value associated with the breach remedy transaction, where the value is a prior secret value associated with the prior commitment transaction.

[0023] In some implementations, the method further includes broadcasting a sidechain transaction to deployed sidechain miners in response to the failsafe activation request, the sidechain transaction transferring value.

[0024] According to the present invention, a computer-implemented method may be provided, comprising: detecting one or more failsafe activation requests issued by one or more nodes participating in one or more channels with a hub, the channels allowing commitments for value transactions associated with the blockchain network to be exchanged outside of the blockchain network, the failsafe activation requests issued by a node that previously opened the channel by broadcasting a funding transaction that bounds digital assets with a public key associated with the group; verifying that the one or more failsafe activation requests satisfy a predetermined criterion; and generating, in cooperation with other nodes of the group, a valid signature for a transaction to close the one or more channels.

[0025] As mentioned above, a channel may be referred to as a payment channel, an exchange channel, or a communication channel. For ease of reference, the term "payment channel" will be used hereafter.

[0026] In some implementations, verifying that the failsafe activation requests satisfy a predetermined criteria includes verifying that the number of failsafe activation requests weighted by the balances of the individual nodes issuing such requests exceeds a threshold.

[0027] In some implementations, the failsafe activation requests specify a respective block number of a block that was recently added to the blockchain of the blockchain network at the time each failsafe activation request was generated, and the group is configured to ignore failsafe activation requests that are determined to be expired based on the block number specified in the failsafe activation request and based on the current block number of the block that was recently added to the blockchain.

[0028] In some implementations, the method further includes deploying a temporary sidechain after verifying that the one or more failsafe activation requests meet a predetermined criteria and prior to collaboratively generating a valid signature. The temporary sidechain allows value to be further transferred. The transaction that closes the one or more channels may also be based on the value transferred on the sidechain.

[0029] In some implementations, the processor includes a trusted execution environment and the computer-executable instructions are executed within the trusted execution environment.

[0030] According to the present invention, there may be provided an electronic device including an interface device, a processor coupled to the interface device, and a memory coupled to the processor, the memory storing computer-executable instructions that, when executed, configure the processor to perform the methods described herein.

[0031] According to the present invention, a computer-readable storage medium may be provided that includes computer-executable instructions that, when executed, configure a processor to perform the methods described herein. [Brief description of the drawings]

[0032] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter, embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0033] [Figure 1] Figure 1 shows a block diagram of an example blockchain network.

[0034] [Diagram 2]FIG. 2 shows a block diagram of an exemplary electronic device that may function as a node in a blockchain network.

[0035] [Diagram 3] FIG. 3 is a flow chart of an exemplary method for issuing a failsafe activation request.

[0036] [Figure 4] FIG. 4 is a flow chart of an exemplary method for participating in a congress.

[0037] [Diagram 5] FIG. 5 is a flow chart of an exemplary method for confiscating digital assets.

[0038] [Figure 6] FIG. 6 is a flow chart of an exemplary method for reallocating key shares.

[0039] [Figure 7] FIG. 7 is a flow chart of an exemplary alternative method for reallocating key shares.

[0040] [Figure 8] FIG. 8 is a flow chart of an exemplary method for returning a deposit.

[0041] [Figure 9] FIG. 9 is a flowchart of an exemplary method for implementing a fail-safe mode with respect to a payment channel. [Figure 10] Figure 10 is a block diagram of a ghost chain. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] Blockchain Network Reference is first made to FIG. 1, which illustrates in block diagram form an exemplary blockchain network 100 associated with blockchain. The blockchain network may be a public blockchain network, which may be a peer-to-peer open membership network in which anyone may join without being invited or consenting from other members. Any distributed electronic device that runs an instance of the underlying blockchain protocol on which the blockchain network 100 operates may join the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.

[0043] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including 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.

[0044] The 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 communications adhere to a protocol associated with the blockchain network. For example, if the blockchain is the Bitcoin blockchain, the Bitcoin protocol may be used.

[0045] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is therefore a distributed ledger. Each node 102 may store a full or partial copy of the global ledger. In the case of a proof-of-work-secured blockchain, transactions by nodes 102 that affect the global ledger are verified by other nodes 102 to ensure that the validity of the global ledger is maintained. If the blockchain is a proof-of-work-based blockchain, blocks are also verified by inspecting the proof-of-work submitted with the block.

[0046] At least some of the nodes 102 act as miners 104 of the blockchain network 100. The blockchain network 100 of FIG. 1 may be a proof-of-work blockchain in which miners 104 perform costly computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, miners 104 find a nonce such that the block header hashes with SHA-256 to a number less than a value defined by the current difficulty. The hashing power required for the proof-of-work algorithm means that a transaction is considered effectively irreversible after a predefined 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 the other nodes 102. The other nodes 102 verify that the miner 104 has indeed solved the cryptographic problem and has therefore demonstrated sufficient proof-of-work before accepting that the block should be added to the blockchain. Blocks are added to the blockchain (i.e., the distributed global ledger) by consensus of nodes 102.

[0047] As an alternative to proof-of-work, the blockchain network 100 may instead be a proof-of-stake blockchain network. A proof-of-stake blockchain network provides an alternative mechanism for achieving consensus. In a proof-of-stake blockchain network, the blockchain is secured by proof-of-stake rather than proof-of-work. Under proof-of-stake, miners deposit a security deposit of digital assets, and their probability of being selected as a node to mine a block is proportional to the amount of digital assets provided as a security deposit. Proof-of-stake blockchain systems can be used to avoid the computational costs and energy required to mine on a proof-of-work blockchain. Additionally, a proof-of-stake blockchain may allow for more frequent and regular block creation than a proof-of-work blockchain.

[0048] Blocks created by miners 104 contain transactions that have been broadcast to the blockchain by nodes 102. For example, a block may contain a transaction from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, a block serves as a record of transactions from one address to another. Those who request that a transaction be included in a block prove that they are authorized to initiate a transfer (e.g., in the case of Bitcoin, to spend Bitcoin) by signing the request with a private key that corresponds to their public key. A transfer can be added to a block only if the request is validly signed.

[0049] In 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, as used herein, transferring digital assets to or from a public key (e.g., paying a public key) and transferring digital assets to or from an address associated with that public key refer to a common operation.

[0050] Some nodes 102 in a blockchain network may not act as miners, but instead participate as validating nodes. Validating transactions may include verifying signatures, checking references to valid UTXOs, etc.

[0051] The example of FIG. 1 includes five nodes 102, two of which participate as miners 104. In practice, the number of nodes 102 or miners 104 may vary. In many blockchain networks, the number of nodes 102 and miners 104 may be much greater than the number shown in FIG. 1.

[0052] As described below, various nodes 102 may cooperate to form groups referred to herein as a congress 110. In the illustrated example, three nodes 102 are shown participating in the congress 110. However, the number of members of an actual congress 110 may be significantly larger.

[0053] A congress 110 may be an open membership group that any node 102 may join by contributing sufficient stake to a pool associated with the congress 110. For example, a node may join a congress by transferring digital assets such as digital currency (e.g., Bitcoin), tokens, or other stake or value to an account (e.g., to a group public address or group public key) associated with the congress 110. A node 102 that joins a congress may be any node in a blockchain network, including both mining and non-mining nodes.

[0054] The congress 110 can be used to facilitate the setup of off-blockchain payment channels 120a, 120b between nodes. This off-blockchain payment channel may be referred to herein as an off-chain payment channel, an off-chain channel, or a payment channel. A payment channel allows the exchange of value off-blockchain. A payment channel allows the channel state of the payment channel (i.e., the balance of the individual nodes involved in the payment channel) to be committed to the blockchain at any time. That is, parties can transfer value in multiple off-blockchain transactions and update the blockchain to reflect the current channel state of the payment channel at any point in time.

[0055] In an embodiment, the first payment channel 120a is set up between two nodes, the first node 102a and the second node 102b, and the second payment channel 120b is set up between two nodes, the first node 102a and the third node 102c. However, in practice, payment channels may be set up between the nodes, or a different number of payment channels may be set up. The payment channels 120a, 120b may be set up in a hub-and-spoke (HAS) configuration, in which a central hub (e.g., the first node 102a in this example) establishes a payment channel with both the second node 102b and the third node. This HAS configuration allows any node connected to the hub to transfer value off-chain to any other node connected to the hub, or to receive value off-chain from any other node connected to the hub. For example, the second node 102b can transfer value off-chain to the third node 102c or receive value from the third node. The hub may be connected to a larger number of nodes than those shown in FIG. 1. Additionally, a hub or non-hub node associated with one payment channel may set up other payment channels with other hub or non-hub nodes.

[0056] During the setup of a payment channel, the nodes associated with the payment channel 120 (e.g., in the illustrated example, the first node 102a and the second node 102b for the first payment channel 120a, and the first node 102a and the third node 102c for the second payment channel 120b) each lock digital assets in a special way to fund the payment channel. After the setup is complete, these digital assets may be allocated using a commitment transaction and an exchange of “value” that effectively invalidates the previous commitment transaction. More specifically, a payment channel allows the nodes associated with the payment channel to exchange commitment transactions. A commitment transaction is a transaction exchanged by a node without (initial) broadcasting it to the blockchain network. The commitment transaction provides a ledger that determines the allocation of the digital assets associated with the payment channel. This allocation may be referred to as the channel state. A commitment transaction may be broadcast at any time by one node associated with the payment channel. Commitment transactions may operate as described in Poon and Dryja in “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, January 14, 2016 (hereinafter “the Lightning Network”). However, payment channels may be set up in different ways than described in the Lightning Network. More specifically, a group of nodes, referred to herein as a congress, may be involved in a setup protocol that allows the group of nodes to assist in the event of a payment channel failure. Such a failure may occur, for example, due to a hub failure. The protocol for setting up payment channels, including the congress and the fail-safe mode provided by the protocol to implement the fail-safe mode, are described in more detail below.

[0057] Electronic devices acting as nodes 2 is a block diagram illustrating components of an exemplary electronic device 200 that may function as a node 102 (FIG. 1) in a peer-to-peer blockchain network 100 (FIG. 1). The exemplary electronic device 200 may also be referred to as a processing device. The electronic device may take a variety of forms including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smart watch, or other types of forms.

[0058] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 may communicate with each other via a bus 240. The memory 220 stores computer software programs including machine-readable instructions and data for performing functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to perform a protocol associated with the blockchain network 100 (FIG. 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0059] The memory 220 may store the global ledger of the blockchain network 100 (FIG. 1) or a portion thereof, i.e., the memory 220 may store all blocks of the blockchain or a portion of the blocks, e.g., the most recent blocks, or a portion of the information in some blocks.

[0060] 2, the electronic device 200 may actually include multiple memory components. The memory components may be of various types including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Additionally, while the memory 220 is shown separate from the processor 210, the processor 210 may include internal memory.

[0061] As shown in FIG. 2, the processor 210 of some nodes 102 (e.g., nodes forming the Congress 110 and / or nodes participating in a payment channel providing a fail-safe mode as described herein) may include a secure domain such as a trusted execution environment (TEE) 250. The TEE 250 is an isolated execution environment that provides additional security for the electronic device 200, such as isolated execution, integrity of trusted applications, and confidentiality of assets. The TEE 250 provides an execution space that ensures that computer instructions and data loaded into the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 may be used to protect the integrity and confidentiality of critical resources such as keys. The TEE 250 is at least partially realized at the hardware level, so that the instructions and data executed within the TEE 250 are protected from access and manipulation from outsiders, such as the rest of the electronic device 200 and the owner of the electronic device. The data and computations within the TEE 250 are protected from those operating the node 102 including the TEE 250.

[0062] The TEE 250 may operate to instantiate an enclave and add one page of memory at a time, hashing incrementally. Similar operations 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 expected hash. Thus, the contents of the enclave can 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 the enclave is fully constructed, it is locked down. It is possible to run code on the TEE 250 and send secrets to the code, but the code cannot be modified. The final hash may be signed by an authentication key, allowing the data owner to verify it before sending any secrets to the enclave.

[0063] The TEE 250 used by nodes acting as congress members may be used to protect the confidentiality and integrity of private key shares related to the congress public key used by the congress 110 (FIG. 1). 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 can directly obtain information about the private key shares or other private key shares held within the TEE 250 enclave from inter-member or inter-enclave communications. The congress protocol is also robust against compromise of the TEE threshold. Additionally, the TEE 250 allows for remote attestation that may be used by the node 102 (FIG. 1) to prove to other nodes 102 that the TEE 250 is authentic and is executing computer-executable instructions approved for the protocol implemented by the congress 110 or the payment channel. Remote attestation may be provided by the TEE 250 by executing a particular piece of code and sending a hash of the code, internal to the enclave, signed by the enclave's internal attestation key (which may be referred to herein as the enclave private key).

[0064] The TEE 250 provided in a node acting as a congress member may be used to attest that a member of the congress 110 that previously used a private key share on the electronic device 200 will ensure the deletion of the private key share if they choose to leave the congress. The electronic device 200 may provide attestation of the deletion to other congress members by a remote attestation protocol provided in the TEE 250. Attestation of deletion may be required before members are allowed to withdraw their member deposits, i.e., the return of the deposit may be conditioned on attestation of the deletion of the private key shares held in the member's enclave.

[0065] A TEE 250 provided in a node participating in a payment channel 120a, 120b (FIG. 1) with a hub may be used to allow the hub to verify (e.g., by remote attestation) that the node is running existing approved code. Additionally, the enclave in the TEE 250 stores an enclave private key that is associated with an enclave public key that may be provided to the hub. The hub may use the enclave public key to send encrypted messages to the enclave. These encrypted messages may include one or more commitment transactions, one or more values ​​that may be used in a breach remedy transaction (BRT), i.e., the values ​​effectively invalidate the stale channel state. The commitment transactions and values ​​may be decrypted by the enclave and provided to other components, systems, or subsystems of the node (such as the node's main processor). The TEE, or more specifically the enclave in the TEE 250, may also be used to generate fail-safe activation requests in the event that the payment channel hub becomes unresponsive. As described in more detail below, the failsafe activation request may be generated at least in part based on data stored in the enclave. For example, the failsafe activation request may be generated based on the latest channel state (reflecting the current balance of digital assets in the payment channel). The failsafe activation request may also include other information, such as the latest block added to the blockchain of the blockchain network, and a statement of the fee offered to the Congress in return for closing the channel. The failsafe activation request is signed by the enclave using the enclave private key so that it can be verified as provided by the enclave.

[0066] The TEE 250 may include a secure random number generator internal to the TEE's enclave that may be used to generate private keys, random challenges, or other random data. The TEE 250 may also be configured to read data from and write data to external memory. Such data may be encrypted with a secret key held only within the enclave.

[0067] The TEE250 can be implemented using a variety of platforms, such as the Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). For example, SGX supports remote attestation, which allows an enclave to obtain a signed statement from the processor running the particular enclave, along with a given hash of a member, known as a quote. A third-party attestation service, such as the Intel Attestation Service (IAS), can attest that these signed statements originate from a genuine CPU that complies with the SGX specification.

[0068] Nodes acting as congress members and nodes acting as non-hub participants in a payment channel may include a TEE, but at least some nodes acting as hubs may not have a TEE 250. In other words, nodes acting as payment channel hubs are not required to operate a TEE in order to participate in (and be protected by) fail-safe mode.

[0069] The electronic device 200 functions as a node 102 (FIG. 1) in the blockchain network 100 (FIG. 1). Some nodes may join or become part of a congress 110. A congress 110 is formed when a group of digital asset holders pool digital assets, such as digital currency, tokens, or other interests or values ​​supported by the blockchain network 100 (FIG. 1). The congress may implement a fail-safe mode, for example, related to a payment channel. For example, if a hub fails, the congress may trigger a fail-safe mode and facilitate orderly closure of the payment channel and / or facilitate another off-chain transfer of value (i.e., an off-mainchain transfer of value).

[0070] Some nodes can participate as non-hub participants in a payment channel. Such nodes can, for example, set up payment channels with hubs or with other non-hub participants. Techniques for setting up payment channels are described below, as are techniques for implementing fail-safe modes in case of hub or payment channel failure.

[0071] Other nodes may not participate as non-hub participants or act as congress members: such nodes may instead function as one or more miners, validators, hubs, or provide other functions related to the blockchain network.

[0072] Participating in payment channels and dealing with channel malfunctions 3, a method 300 for participating in a payment channel and responding to channel failure is shown. Method 300 may be performed by a node 102 of a blockchain network. Such a node 102 may include computer-executable instructions stored in memory 220 (FIG. 2) that implement the method 300. Such instructions, when executed by a processor 210 (FIG. 2), cause the node 102 (such as an electronic device 200 of the type described with reference to FIG. 2) to perform the method 300.

[0073] In operation 302, the enclave associated with the node executing method 300, and more specifically the TEE 250 (FIG. 2) in the node executing the method 102, provides an enclave public key to a hub to be included in the payment channel. The enclave public key is a public encryption key associated with an enclave private key that is securely stored in the enclave. The enclave public key allows the hub to communicate directly with the enclave; that is, the hub uses the enclave public key to encrypt communications to the enclave.

[0074] The enclave public key may be provided to the hub directly by the node performing the method, or may be provided to the hub by including the enclave public key as metadata in a funding transaction, referenced below in connection with operation 304. Thus, although operations 302 and 304 are illustrated using separate blocks in the flowchart of Figure 3, operation 302 may be performed as part of operation 304 of method 300 of Figure 3.

[0075] In operation 304, the node executing method 300 establishes (i.e., sets up) a payment channel with the hub. More specifically, the payment channel may be set up by broadcasting a funding transaction to the blockchain network that restricts the digital asset with a first public key, a second public key, and a third public key, such that the restriction on the digital asset may be removed by: 1) both a first signature generated from a first private key corresponding to the first public key and a second signature generated from a second private key corresponding to the second public key; or 2) the third signature alone that is valid against the third public key. The third public key is a public key associated with a group, such as the congress 110 (FIG. 1). For example, the third public key may be a group public key (which may be referred to as a congress public key). The first public key is associated with the node executing method 300, and the second public key is associated with another node, such as the hub, that is a participant in the payment channel to be set up.

[0076] Thus, funding transactions are configured such that the two parties to a payment channel can mutually remove the restriction on the digital asset associated with the funding transaction, or the Congress acting alone can remove the restriction. That is, funding transactions are configured such that the restriction can be removed in one of two ways. If the parties to a payment channel are willing to cooperate, the restriction can be removed if they both use their respective private keys (i.e., the private keys associated with the first public key and the second public key) to generate a signature on a transaction that consumes the restricted digital asset. Under this scenario, those valid signatures together remove the restriction. The second way in which the restriction can be removed is by multiple members of a Congress cooperating to generate valid signatures on behalf of the Congress according to a threshold signature scheme. Threshold signature schemes are described in more detail in the detailed discussion of Congress. In general, threshold signature schemes require the cooperation of a number of Congress member nodes that control at least a threshold number of key shares. Because Congress is protected by the escrow of stakes, Congress member nodes risk confiscation of their stakes if they act contrary to the Congress protocol. For example, if a Congress member contributed a partial signature to a transaction that effectively steals the digital assets associated with the funding transaction in operation 304, the Congress member would risk having their deposit revoked by an honest Congress member who controls at least a threshold number of key shares.

[0077] As discussed above in the description of operation 302, the funding transaction broadcast in operation 304 of method 300 may include a public key associated with the TEE of the node performing the method as metadata of the funding transaction. For example, an enclave public key may be specified as metadata in the funding transaction.

[0078] After setting up the payment channel, the node executing method 300 is connected to the hub by the payment channel, which forms one spoke of the hub-and-spoke payment network, and may exchange value with other nodes connected to the hub by other "spokes" and, if necessary, with the hub itself. For example, the node can now transfer value off-chain with other non-hub nodes by forwarding (in operation 306) the token with the hub. More specifically, value may be transferred by exchange with the hub of the commitment transaction and one or more "values" that invalidate the previous commitment transaction. The commitment transaction may be received at the enclave of the node executing method 300 in encrypted form. For example, the received commitment transaction may be encrypted with the enclave public key, so that the commitment transaction remains secure within the enclave. The enclave can therefore see all commitment transactions sent by the hub and is therefore always aware of the latest channel state. The enclave can decrypt the commitment transaction, verify the balance associated with the channel, and verify the value associated with the breach remedy transaction. This value is the previous secret value associated with a previous commitment transaction, and the value can be used in a breach remedy transaction if a counterparty (such as a hub) violates the protocol by attempting to broadcast an outdated commitment transaction to the blockchain network.

[0079] Commitment transactions can generally be exchanged in the manner described in the lighting network. Commitment transactions can be exchanged with a value that effectively invalidates the previous channel state, i.e., the value effectively renders older commitment transactions unusable. Any attempt by a dishonest participant to broadcast an old (i.e., non-current) commitment transaction proves unwise, because the value that invalidates the previous channel state can be used by honest participants to penalize the dishonest participant (e.g., by claiming all funds in the channel).

[0080] If the payment channel continues to function as intended, the payment channel can be closed at any time by mutual agreement of the parties to the payment channel. Recall that the funding transaction used to fund the payment channel was constructed such that both parties to the payment channel (e.g., the nodes and the hub performing method 300) can remove restrictions on the digital assets by cooperating in a 2-of-2 multi-signature protocol. Thus, these nodes can cooperate to generate respective signatures for a transaction that would close the payment channel and redistribute the digital assets previously restricted by the funding transaction. That is, these nodes can easily reallocate funds in a manner that takes into account the current state of the payment channel without necessarily having to rely on a commitment transaction. However, if a counterparty becomes uncooperative and refuses to sign such a transaction, a commitment transaction may be required.

[0081] As mentioned above, a payment channel may fail in certain circumstances, which may be detected in operation 308. For example, a hub may fail, and such a failure may be detected by a node in operation 308. A hub failure may be detected, for example, if the hub fails to provide an expected commitment transaction to an enclave in response to a request to update a channel.

[0082] In response to detecting the hub failure, the node may issue a failsafe activation request to the group (i.e., the group or congress associated with the third public key) in operation 310. The failsafe activation request may be issued to the group by automatically sending the failsafe activation request online in response to detecting the hub failure. For example, the failsafe activation request may be submitted to a web server that serves as a central repository for failsafe activation requests and that is configured to be monitored by member nodes of the group. The failsafe activation request may be generated within the enclave and signed using an enclave private key associated with the enclave public key. The failsafe activation request is issued to the group using data from the enclave. For example, the data used to generate the failsafe activation request may be based on the commitment transaction received during operation 306. For example, the failsafe activation request may include a signed statement of the current state. The current state of a payment channel is the balance of the payment channel, and the status, state or balance determines the allocation of digital assets when recent commitment transactions associated with the payment channel are taken into account.

[0083] The failsafe activation request may also include other information. For example, the failsafe activation request may specify a fee provided by the node to close the payment channel. The failsafe activation request may also include freshness data, such as a timestamp. The timestamp or other freshness data may specify the date and / or time when the failsafe activation request was generated or issued by the TEE. Alternatively, the timestamp may specify the block number of the most recent block added to the blockchain of the blockchain network. A group of nodes processing the failsafe activation request may be configured to ignore a failsafe activation request that is determined to be expired based on the timestamp. For example, if the timestamp is expressed as the most recent block number, the group may ignore a failsafe activation request that is determined to be expired based on the block number specified in the failsafe activation request and based on the current block number of the most recent block added to the blockchain. That is, the group may evaluate the freshness of the failsafe activation request based on the number of blocks that have elapsed since the failsafe activation request was issued.

[0084] A node executing method 300 may be configured to reissue (in operation 314) the failsafe activation request if it has expired (as determined by the node in operation 312), if failsafe mode is not being implemented, and if the payment channel has not been tentatively restored. That is, if the group is not implementing failsafe mode and the payment channel remains inoperable, the expired failsafe activation request may be reissued in operation 314. More specifically, another failsafe activation request may be issued to the group, the another failsafe activation request including new freshness information, such as a block number, for the newest block added to the blockchain.

[0085] After the failsafe mode is activated by Congress (in response to observing sufficient failsafe activation requests, as described in more detail below), Congress can close the payment channel. For example, Congress nodes can cooperate to generate a signature for a transaction affecting a digital asset that is restricted in operation 304. The signature is valid against the third public key described above in the description of operation 304. That is, the signature is valid against the group / congress public key that restricted the digital asset. Because the payment channel was configured to allow Congress to assume control over the assets included in the funding transaction, Congress can facilitate closing the transaction if the payment channel fails.

[0086] In at least some examples, a temporary sidechain may be deployed in response to a failsafe activation request (and more specifically, in response to a sufficient number of failsafe activation requests to trigger a failsafe mode) before the channel is closed by broadcasting a closure transaction to the blockchain network. The temporary sidechain may be referred to as a ghost chain and is described in more detail below. The temporary sidechain may be used by a node in operation 316 of method 300 to exchange (e.g., transfer or receive) value with other nodes via the sidechain. For example, a node may transfer value to other nodes by broadcasting a sidechain transaction to miners of the sidechain that was deployed in response to the failsafe activation request. The sidechain transaction transfers value to or from other nodes. That is, the sidechain transaction effectively updates the balance of a digital asset associated with the node. The sidechain may be used to transfer or receive value via other "spokes" (i.e., other payment channels) for other nodes that previously established payment channels with the failed hub. Thus, the sidechain allows nodes previously connected to the hub to continue transacting with each other while they wait for their channels to be closed. No further requests to close channels may be required after failsafe has been activated; all channels that have issued a failsafe activation request will be closed when the sidechain is terminated.

[0087] When a sidechain is deployed, nodes may later issue a request to the Congress to assume the state of the payment channel relative to the main blockchain (which may also be referred to as the mainchain). The Congress nodes can then cooperate to generate valid signatures to close transactions that account for any sidechain transactions that affect balances. Thus, if a payment channel fails (e.g., due to a hub failure), a group of nodes that are members of the Congress can cooperate to facilitate the closure of the payment channel. Congresses and their various functions are described in more detail below.

[0088] Congress and Threshold Signatures A congress 110 may be a group of permissioned or unauthorized nodes 102 operating in a blockchain network. That is, a congress 110 may be joined by a node 102 (FIG. 1) in the blockchain network 100 (FIG. 1) (e.g., any node that monitors and stores at least a portion of the information in the blockchain). To join a 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 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 be referred to as a public group address). The digital assets are subject to a group threshold signature by a single public key, referred to as the congress public key. Congress members hold private key shares generated through distribution (i.e., private key shares generated by various nodes holding such private key shares). The number of shares held may be proportional to the amount deposited in the pool.

[0089] Digital assets managed by the Congress 110, including any digital assets transferred to a Congress address (i.e., to a Congress public key, which is a public key associated with the Congress), are subject to a threshold signature scheme. Under the threshold signature scheme, a group of members whose total private key shares exceed a threshold are required to generate a valid signature that allows a digital asset to be transferred away from the 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 a digital asset managed by the Congress 110.

[0090] The Congress Public Key restricts digital assets deposited in the Congress Pool by members of the Congress 110 in exchange for private key shares, and any digital assets deposited at addresses associated with the Congress Pool by members and non-members of the Congress 110 that are deposited for reasons other than obtaining private key shares (i.e., restricted by the Congress Public Key). Non-members or members may restrict digital assets with the Congress Public Key for a variety of reasons. For example, as described above with reference to FIG. 3, a funding transaction for a payment channel may restrict digital assets with the Congress Public Key. Restricting such digital assets (i.e., digital assets used to open a payment channel) with the Congress Public Key allows Congress to implement a fail-safe mode if the payment channel fails (e.g., if the hub associated with the payment channel becomes unresponsive).

[0091] Since the same Congress Public Key may restrict both member deposits (i.e., digital assets provided by Congress members in return for a private key) and digital assets provided by members or non-members for other purposes, at least some deposits to the Congress Public Key may be signaled with a special flag to indicate the type of deposit. For example, a transaction transferring digital assets to a Congress Address may include a flag, identifier, or other attribute indicating the nature of the deposit made. For example, a transaction moving digital assets to a Congress Address that is not intended to join a Congress or increase a stake in Congress membership may include a special identifier indicating that the deposit is being made for another purpose. Such an identifier may be used by nodes 102 associated with a Congress 110 when managing private key share generation (described in more detail below). More specifically, a node 102 that escrows / restricts digital assets for purposes of joining a group will be allocated a private key share with respect to the Congress 110 (as a result of making the escrow of the digital assets), while other nodes 102 that restrict digital assets for other purposes (e.g., to open a payment channel) may not possess a Congress private key (i.e., one that corresponds to the Congress public key) with respect to the Congress.

[0092] The Congress 110 can act as a self-governing group where cooperative behavior is enforced by the threat of confiscating all or part of a member's deposit. Uncooperative or malicious members can have such digital assets confiscated by the participation of a majority of honest members in the cooperative protocol. Furthermore, if Congress members wish to leave the Congress 110, they can withdraw their member deposits (i.e., request that the Congress 110 transfer the member's deposits back to the member's personal address). However, withdrawal of funds can only be performed if a number of private key shares exceeding the threshold required to generate a valid digital signature are used by the TEEs associated with the group's members (i.e., the Congress) to generate a partial signature to authorize the withdrawal.

[0093] The threshold signature scheme implemented by the Congress 110 can be of various types. A threshold signature scheme allows for the distribution of signing authority among n parties, as long as at least a threshold number of private key shares contribute to generating a valid signature. Any subset smaller than the threshold cannot generate a valid signature or generate any useful information about the signature. More specifically, each party controls a share of a private signing key, and a threshold number of key shares must be used to generate a valid signature of the combined partial signatures. Any subset of key shares below the threshold cannot generate a valid signature of the combined partial signatures.

[0094] The threshold signature scheme may be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. For example, the 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 the digital signature scheme, an elliptic curve cryptography based algorithm, in which t+1 key shares from n key share holder parties are required to reconstruct a private key. This scheme can be used to construct valid signatures without the need to reconstruct the private key and without any party having to reveal their key shares to anyone else.

[0095] The maximum number of adversaries allowed by this technique is t, since t+1 key shares are sufficient to reconstruct the secret. In Ibrahim et al.'s model, an adversary is an entity that bribes a party that holds a secret share and gains access to that secret share. Adversaries can be of different types. For example, a Byzantine problem adversary is one who pretends to participate in the protocol while actually sending false information. The ECDSA scheme proposed by Ibrahim is robust against malicious adversaries up to t<=n / 4. This robustness can be increased to t<=n / 3, but at the cost of more complexity.

[0096] Ibrahim et al.'s ECDSA scheme is robust to stopping halting adversaries with t<=n / 3, which can either prevent corrupted parties from participating in the protocol or stop them from participating midway.

[0097] The ECDSA scheme includes various mechanisms that can be used by the nodes 102 to identify malicious or non-cooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomial required for Shamir's secret sharing (SSS). SSS is a form of secret sharing in which the secret is split into multiple parts and provided to each participant in their own unique part. These parts can be used to reconstruct the secret. VSS can be used by the nodes 102 to identify malicious nodes 102 or members when conflicting shares are provided to various nodes 102 or when shares are sent secretly to different nodes than the blind shares that are broadcast to all nodes. The conflicting shares can be identified by any of the nodes 102. The secret shares can be made verifiable by including auxiliary information that allows the nodes 102 to verify their shares as consistent.

[0098] The transmission of erroneous shares (i.e., shares that are different from the broadcasted blind shares) to individual nodes can be identified by the intended recipient nodes of the shares. The identification of erroneous shares sent in secret to nodes can be made publicly verifiable using techniques of Publicly Verifiable Secret Sharing (PVSS). Such techniques can avoid possible delays in identifying fraudulent senders that could occur if PVSS is not used and the recipient of the erroneous share is offline or disconnected from a significant portion of the network when the erroneous share is sent.

[0099] Inappropriate behavior, such as providing incorrect shares to different nodes, may be addressed by the Congress 110 to discourage malicious behavior. For example, if a node 102 (FIG. 1) is identified by other nodes 102 as malicious, a number of nodes 102 (i.e., nodes associated with Congress members) exceeding a threshold (e.g., t+1) may cooperate to penalize the malicious party. For example, the nodes 102 may take action regarding digital assets (e.g., digital currency, tokens, or other stake or value) deposited with the Congress by the malicious party. For example, the Congress may burn the digital currency, tokens, stake, or value by moving it to an unspendable address, or the Congress may confiscate such digital assets by reaching consensus on a decision not to allow return to the malicious party. Additionally, nodes 102 that are not misbehaving nodes can also stop the misbehaving node by cooperating to exclude the misbehaving node (e.g., by effectively invalidating the key shares; e.g., by excluding the node from participating in the congress protocol, or by re-sharing the private key and not allocating shares to the misbehaving node).

[0100] The ECDSA technique described above can be strengthened by the use of TEEs. For example, the threshold ECDSA signature technique based on Ibrahim et al. assumes a strong form of adversary, referred to here as a Byzantine adversary. This kind of adversary can behave tyrannically, for example by refusing to participate in the signing process or dropping out midway, but also by pretending to participate honestly and sending false information. However, additional security can be provided by using a TEE and generating the data used for signing within an enclave in the TEE where the secret private key shares are stored, since the likelihood of a large number of enclaves being compromised is extremely low. If each TEE is assigned only one key share, for example, the number of TEEs that can be compromised can be reasonably expected not to approach the threshold of robustness against a Byzantine adversary, assuming n is sufficiently large. This allows the protocol to be secure if it is resistant to a small number of malicious adversaries relative to the total number of key shares.

[0101] For example, if all nodes in a congress have a TEE, obtaining secrets stored in the enclaves can be achieved only with physical access to the nodes, and only with great effort and expense, unless the manufacturer of the TEE is compromised. Such a manufacturer-level compromise is expected to be manageable. For example, if the manufacturer falsely claims that many public keys correspond to true TEEs, they could gain direct access to the private key shares and potentially launch an attack. However, such an attack would require a sufficient number of key shares to allow the manufacturer to generate valid signatures without assistance from other nodes. This would mean accumulating a large proportion of the total stake, which can be expected to be prohibitively expensive. Moreover, carrying out an attack would necessarily compromise a significant proportion of the value of the large stake.

[0102] When a TEE is used, it is useful to consider the robustness of the protocol against a “corrupted node”. A corrupted node is one in which the hardware external to the TEE has been corrupted, but the integrity of the TEE has not been corrupted. A corrupted node may have control over what information the enclave receives and what information it does not receive. In particular, a corrupted node may suspend, i.e., refrain from participating in the protocol. If the information provided to the protocol is required to be signed by a private key kept secret in the enclave (the corresponding public key is authenticated during the authentication process), the private key is as trustworthy as the enclave itself. Thus, a corrupted node would not be able to feed arbitrary (authenticated) information to the protocol, but would only be able to disrupt it by attempting to suspend or trick the enclave into behaving improperly, e.g. by providing stale information. As a result, for a corrupted node, a successful attack requires the collection of a sufficient number of partial signatures to generate a complete signature. With respect to TEEs, Ibrahim et al.'s protocol is robust to 2t compromised nodes. For n-2t>=2t+1, any eligible subset of key shares of size 2t+1<=(n+1) / 2 is sufficient for signatures to be generated. Thus, when a TEE is used, the threshold of the threshold signature scheme can be set to be 50% or more of the number of key shares to generate valid signatures in the presence of compromised nodes.

[0103] Other threshold signature schemes may be used. For example, the threshold signature scheme may be an ECDSA threshold scheme of the type proposed in Goldfeder et al., “Securing Bitcoin Wallets Via a New DSA / ECDSA threshold signature scheme”, (2015). This protocol allows t+1 parties to generate valid signatures. As a result, the number of key shares that an adversary must control to generate a valid signature is equal to the number of key shares that an adversary must possess to reconstruct the private key. This technique can provide an efficient scheme when unanimity is required to generate a valid signature. In the most general case, this scheme imposes space requirements that grow exponentially with the number of congress members, because for any threshold, the entire protocol must be repeated for any possible subset of t+1 players out of n. Thus, for large values ​​of both n and t, a large number of key shares must be stored. To alleviate such storage requirements, standard Bitcoin multisignatures can be combined with threshold signatures. In particular, digital assets can be locked using multi-signatures, such that each private key is divided into multiple shares. This technique would make large congresses more efficient in terms of space requirements. Scaling properties could also be improved by iteratively constructing schemes for large numbers of participants, from smaller party sizes, at multiple levels. For example, threshold signature schemes could be combined with techniques from Cohen et al.,Efficient Multiparty Protocols via Log-Depth Threshold Formulae(2013),Advances in Cryptology - CRYPTO 2013 pp 185-202.

[0104] Other threshold schemes may be used, including non-ECDSA signature schemes. For example, a threshold scheme based on the Schnorr scheme may be used by the nodes 102 to implement the congress 110.

[0105] A node 102 in a blockchain network 100 (FIG. 1) may implement a congress protocol based on a selected threshold signature scheme. Such a node 102 may include computer-executable instructions stored in memory 220 (FIG. 2) that implement the congress protocol. Such instructions, when executed by a processor 210 (FIG. 2), cause a node 102 (such as an electronic device 200 of the type described with reference to FIG. 2) to perform one or more methods of the congress protocol. Such methods may include any one or combination of methods 400, 500, 600, 700, 800, 900 of FIGS. 4-9. Thus, the congress protocol may include one or more of methods 400, 500, 600, 700, 800, 900 of FIGS. 4-9. The methods may be performed by a node cooperating with other nodes in association with other congress members.

[0106] Joining the Congress Reference is now made to Figure 4, which illustrates a method 400 for joining a congress. This method can be performed to join an existing congress, i.e., method 400 may be used to join a congress that was previously started.

[0107] The method 400 of FIG. 4 includes, in operation 402, obtaining a congress public key. The congress public key may be obtained from an existing member of the congress or from a third party, including, for example, a third party system operating outside the blockchain network 100 (FIG. 1). For example, the congress public key may be obtained from a public web server accessible via the public internet. As a further example, the congress public key may be tracked on the blockchain; for example, based on metadata included in at least some transactions that transfer digital assets to the congress public key.

[0108] A node 102 executing the method 400 pays the congress public key in operation 404 by broadcasting a digital asset transaction from a private account associated with the node 102 to a congress address (i.e., an address associated with the congress public key). More specifically, the node 102 broadcasts a transaction to transfer one or more digital assets to a public group address associated with the congress public key. The public group address is the address of a congress pool. The congress pool contains other digital assets associated with other members of the congress. Thus, the transaction in operation 404 is transferred to the congress pool, which contains digital assets from other members, once it has been added to a block by the miner 104 (FIG. 1) and the block has been confirmed. The public group address can receive both transfers from those who wish to participate in the congress and those who do not wish to participate in the congress. Those who do not wish to participate in the Congress may transfer digital assets to the Congress Pool, where such digital assets may be managed in whole, in part, or conditionally using the threshold signature scheme used by the Congress. For example, as described above with reference to Figure 3, the Congress public key may restrict the digital assets associated with funding transactions that open payment channels.

[0109] The transaction in operation 404 may include a flag, identifier, or other attribute that indicates that the person transferring the digital asset wishes to participate in the congress and that a deposit is being made for such purposes.

[0110] After depositing digital assets in the congress pool, the node 102 executing the method 400 receives a private key share in operation 406. The node 102 then regenerates the private key share in operation 408 by executing a single instance of the protocol. The generation of the private key share may be performed within the TEE of the node 102.

[0111] In operation 408, node 102 generates private key shares to be used in a threshold signature scheme in which at least a threshold number of private key shares must be used to generate a valid signature for a transaction on behalf of the Congress. The holders of other private key shares are other members of the Congress and are participating in the Congress in an authorized or unauthorized manner by transferring their digital assets to the public group address.

[0112] In operation 407, to regenerate the private key shares, the existing congress members may cooperate to update the key shares. For example, the node 102 may generate a random polynomial f 0 n+1 Then, the node 102 can generate point f 0 n+1 (n+1) and set this as their private key share. The nodes 102 can then compute this polynomial (i)f 0 n+1The points in (i) can be distributed to each of the existing congress members (i=1,...,n). Then, each existing congress member (i=1,...,n) adds the received value to its existing private key share to obtain a new private key share. Node 102 now has an equal private key share to all other members, and the corresponding public key remains unchanged. As mentioned above, the threshold signature scheme may be of various types, including threshold schemes based on the Elliptic Curve Digital Signature Algorithm or the Schnorr scheme.

[0113] The private key shares may be generated within the TEE 250 (FIG. 2) and securely stored at the node 102. For example, the private key shares may be stored in the TEE 250.

[0114] After private key shares are generated by each node, funds under the control of the previous Congress Public Key (e.g., funds transferred to the public group address associated with the original Congress Public Key) may be transferred (through the cooperation of a sufficient number of group nodes to generate valid signatures under the threshold signature scheme) to a new Congress Public Key associated with the new private key share. However, in other embodiments, nodes may participate in a congress in a manner that does not require a new Congress Public Key to be defined. Instead, the same Congress Public Key may be used, and the TEE associated with the congress nodes may be used to cooperate to allow nodes participating in the congress to generate private key shares corresponding to the existing Congress Public Key.

[0115] After the private key share is generated in operation 408, it may be used in operation 410 of method 400. The private key share may be used to cooperatively generate a valid signature for a transaction from a public group address that may be broadcast by the members. That is, the private key share may be used in a threshold signature scheme to contribute to the signature generation. Under a threshold signature scheme, a threshold number of private key shares of the congress are required to be used by each member to generate a valid signature that allows a digital asset to be transferred away from the congress. The node 102 executing method 500 may retrieve the private key share from storage and use the private key share to contribute to the signature generation. If a sufficient number of other congress members also use their private keys to contribute to the signature generation, a signature may be generated and a valid outgoing transaction may be broadcast. An outgoing transaction is completed when a miner 104 (FIG. 1) in the blockchain network 100 adds the transaction to a mined block that is added to the blockchain by consensus of nodes 102 in the blockchain network 100 and the block is confirmed. At this point, the digital assets represented in the transaction may no longer be bound by the Congress public key. That is, such digital assets may no longer be bound by the Congress public key.

[0116] The use of the private key shares in operation 408 may be performed within the TEE of node 102. The TEE protects the private key shares, such that other parts of the system or the member itself cannot access any data stored in the enclave, such as the private key shares. Additionally, the TEE protects the private key in that a member cannot retain a copy of the private key if they wish to return their deposit, since, assuming the integrity of the TEE is maintained, the deletion of the private key must be proven before the member's deposit can be returned. Additionally, using a TEE when the Congress acts as a bonded validator set for a proof-of-stake sidechain can also ensure that partial signatures are provided (by the TEE to the node) if and only if consensus is reached regarding the sidechain on which the transaction should actually be signed.

[0117] The transaction in operation 410 can transfer the digital assets back to the person who originally deposited those digital assets in the Congress Pool. That is, the transfer can return the digital assets to the depositor. The transfer can also move the digital assets elsewhere. For example, the digital assets may be transferred to a third party or to an unusable address. In some cases, one or more digital assets that were restricted by the Congress public key in a funding transaction to open a payment channel can be redistributed by the transaction with Congress approval.

[0118] Confiscation of Digital Assets Referring now to Figure 5, an exemplary method 500 for confiscating digital assets is shown. Method 500 of Figure 5 may be performed by a node 102 that has previously participated in a congress, which may be the same node that performs method 400 of Figure 4. Method 500 may be performed after operation 408 of method 400 of Figure 4, such that the node 102 performing method 500 already has access to the private key shares when method 500 of Figure 5 is performed.

[0119] In operation 502, the node 102 detects malicious activity by a malicious party. The malicious party is another member of the congress. Malicious activity is detected when the node 102 determines that a member of the congress is violating a predefined protocol or criteria. For example, if a node that is a member of the congress reports bad information (i.e., false information, contradictory information, unacceptable information) to other members of the congress, the member may be considered a malicious member. As a further example, if a node that is a member of the congress proposes a transaction that dishonestly and fraudulently transfers a digital asset restricted by a congress public key (such as a digital asset restricted by a congress public key in a funding transaction to open a payment channel) to another location, the other honest nodes may act to penalize the member deposit of the dishonest node.

[0120] In operation 503, in response to detecting malicious activity, node 102, in cooperation with other nodes of the congress, can suspend the member who is the malicious party, i.e., the congress can exclude the malicious party from further participation in the congress.

[0121] To ensure that all nodes 102 operate according to a predefined protocol or standard, member deposits to the Congress Pool may be subject to confiscation. Confiscation means permanently preventing the return of a member deposit that is deemed confiscated. Digital assets forming a member deposit that are not returned due to malicious activity may remain in the Congress Pool but not be returned, and may be transferred to another unusable address immediately or in the future, or may be confiscated, the nature of the confiscation depending on whether the Congress acts as an endorsement validator configured for the sidechain. For example, in operation 504, in response to detecting malicious activity by a malicious actor, the node 102 executing method 500 may provide a partial signature in a confiscation transaction using a private key share. That is, the node cooperates with other nodes in the Congress to confiscate at least a portion of the digital assets previously transferred by the malicious actor to the public group address (i.e., to the Congress Pool). That is, in response to a group member noticing a violation of a given protocol or standard, the private key shares are utilized to contribute to the approval of a transaction involving one or more digital assets associated with that group member and held in the Congress Pool.

[0122] Because the threshold signature scheme is used with the Congress public key, an individual node acting alone cannot transfer other Congress members' digital asset deposits from the Congress pool to another location (e.g., to an unusable address). Rather, digital assets can be confiscated by transfer only if a threshold number of private key shares are used by each respective member to generate a valid signature to transfer the digital assets to another address, or if a group of members with at least the threshold number of private key shares reach a consensus to suspend the member (in operation 503), which causes any withdrawal requests from the suspended member to be automatically ignored. When digital assets are confiscated by transfer, other addresses to which the digital assets may be transferred may be associated with unusable addresses. For example, the other addresses may be addresses for which no private key exists, such that no one can access the digital assets associated with the public key of that address. When digital assets are moved to an unusable address, they may be considered burned because they can no longer be used by any member of the Congress, or indeed by any node in the blockchain network 100.

[0123] Thus, in operation 504, a node can confiscate digital assets by using its private key shares in cooperation with other members of the congress to generate valid signatures for transactions to the unusable addresses.

[0124] Furthermore, in some implementations, the Congress can act as a set of endorsers, ensuring a proof-of-stake sidechain (including ghost chains, described in more detail below), which can be used as a broadcast channel. For example, a consensus can be reached by the Congress members in the sidechain that a member acted maliciously. This consensus can correspond to the confirmation of a sidechain transaction that contains incriminating evidence of the malicious activity. If consensus is reached, any request to withdraw a member deposit made by a malicious member is denied, and the deposit is considered confiscated. All or part of the confiscated digital assets can be burned at some future point in time. That is, at a later point in time, a threshold number of members (not including the malicious member) can cooperate to approve the transfer of the confiscated digital assets to an unusable address. Rather, some or all of the digital assets can be sent as a reward to the node that provided evidence of the member's misconduct.

[0125] Because the Congress is an open group that may be joined by any node 102 in the blockchain network 100 by depositing digital assets, group membership may change periodically. When such changes occur, the allocation of private key shares may be updated.

[0126] Updating private key share allocation with new public addresses 6, an example method 600 for updating private key share allocations is shown. Method 600 may be performed by a node 102 of a blockchain network 100 in coordination with other nodes of the blockchain network.

[0127] In operation 602 of method 600, node 102 detects a redistribution request, which is a request that requires a redistribution of key shares to fulfill the request. For example, node 102 may detect that a prospective new member has transferred digital assets to a public group address or that an existing member has requested a withdrawal of a member deposit.

[0128] Digital assets may be transferred to the public group address (i.e., the congress pool) by nodes requesting to participate in the congress or to increase their involvement in the congress, and by other nodes that are not requesting to participate in the congress but are transferring digital assets to the congress for another purpose (e.g., transferring the digital assets to a sidechain, as described below). In operation 602, node 102 may use one or more attributes included in at least some transactions of digital assets to the public group address to identify congress members (i.e., those transferring digital assets to the congress public key in order to participate in the congress but not for other purposes). For example, a particular transaction may be flagged as a special transaction utilizing an attribute in the transaction. Such an attribute (or the presence or absence of an attribute) may indicate the purpose for which the transfer is made. For example, a flag may be included in the transaction if the transfer does not request participation in the congress.

[0129] In response to detecting the request in operation 602, the implementation of which requires a redistribution of key shares in operation 604, new private key shares being generated by node 102 in a manner similar to the way the private key shares were generated in operation 408 of method 400 of FIG. 4. Other member nodes of the congress also generate their own private key shares. These private key shares may be used with the threshold signature scheme of the new congress public key. Members leaving the congress at this point do not generate new private key shares during operation 604, and since they are not assigned private key shares for use with the new congress public key, they are ineligible to participate in the congress and are no longer considered congress members.

[0130] Further, in response to detecting a redistribution request (which is a request the fulfillment of which requires a redistribution of key shares), in operation 606, node 102, in cooperation with other congress members, moves all digital assets in the public group address to a new public address associated with the new public key (which then becomes the new congress public key).

[0131] Thus, according to method 600 of Figure 6, when the allocation of deposits changes or when a request is received from a member to withdraw a deposit, the private key shares can be regenerated and all digital assets under the control of the Congress can be transferred to the new public key. The frequency with which the membership of the Congress can be updated is limited by the block time of the blockchain network 100. Many applications will only require rebalancing (or asset reallocation) to occur infrequently (i.e., infrequently compared to the frequency with which blocks are mined in a proof-of-work mechanism).

[0132] Renewing Private Key Share Reallocation While Preserving Existing Public Group Addresses 7, another exemplary method 700 for updating private key share distributions is shown. Method 700 may be performed by node 102 of blockchain network 100 in cooperation with other nodes of blockchain network 100.

[0133] In method 700 of FIG. 7, the Congress public key does not change whenever the distribution of member deposits changes. When a request to allocate new key shares is detected (operation 702, which may occur due to the deposit of digital assets to a public group address), node 102 collaborates with other members of the Congress to issue new private key shares for the same public key to the new members of the group (in operation 704). The number of collaborating nodes is at least the threshold number required to generate a digital signature under the threshold signature scheme. In operation 704, additional key shares may be assigned while other key shares remain the same. This may require a change in the threshold (of the threshold signature scheme), but in practice the change may be small. Alternatively, in operation 804, additional key shares may be assigned while other key shares are renewed. Such an update is required to be accomplished by proof against deletion of any key shares of the previous generation. In this case, new shares may be assigned while maintaining the same threshold (in the case of SSS, this involves a share in a new polynomial for the increased degree).

[0134] In operation 702, node 102 may identify congress members (i.e., those who transferred digital assets to the congress public key in order to participate in a congress and not for other purposes) using one or more attributes included in at least some of the digital asset transactions to the public group address. For example, a particular transaction may be flagged as a special transaction using an attribute in the transaction. Such an attribute (or its presence or absence) may indicate the purpose for which the transfer is made. For example, a flag may be included in a transaction if the transfer is not requesting participation in a congress.

[0135] When members leave a congress using method 700, they can reliably delete their private key shares. To ensure that the private key shares of the old members are not available, members of the congress may be required to use a node 102 with a special TEE. A TEE is an architecture implemented at the hardware level that ensures that instructions and data executed within it are protected against access and manipulation from the rest of the system. A TEE may use a hardware mechanism that responds to remote attestation challenges that can be used to verify the integrity of the system to external parties such as other nodes of the congress.

[0136] Each member node may use an authenticated TEE configured to generate one or more random secret values ​​that remain inaccessible to the host system without compromising hardware at the integrated circuit level. The secret value thus generated is used in the distributed generation of private key shares (e.g., operation 410 of method 400 of FIG. 4). This secret value may also be used to establish a shared public key during the setup phase of the congress. Because the computations associated with the setup protocol are performed within the TEE enclave, no member or former member can derive information about its own or the other's private key shares from member-to-member communications or in any other manner. The enclave within the TEE allows a remote attestation protocol to be performed that may be used to prove to other nodes that the TEE enclave is authentic and is executing authorized computer-readable instructions.

[0137] Computations related to group changes are performed within the TEE enclave, e.g., the generation of new secure random secrets that can be used in computing new polynomials for SSS purposes is performed in the TEE enclave.

[0138] The TEE enclave also aims to ensure that previous secrets and previous key shares that are no longer in use are deleted before the member deposit can be returned. More specifically, in order to return the member deposit, an attestation protocol may require the TEE enclave to publicly attest the deletion of the key shares. Each node 102 may interpret such attestation as confirmation that the necessary deletion occurred at the other nodes due to the remote attestation protocol. Thus, the method 800 may include verifying that private key shares previously held in the TEE of the member that has left the congress have been deleted from the nodes associated with that member. This verification may be performed by authenticating the deletion of the private key shares. Thus, a remote attestation protocol may be used to obtain authentication for the deletion of private key shares previously held in the TEE of the member that has left the congress.

[0139] Method 600 of Figure 6 and method 700 of Figure 7 each provide various advantages. For example, method 600 of Figure 6 does not rely on secure deletion, nor does it need to rely on trusted hardware. However, method 600 of Figure 6 can benefit from such hardware because, in some circumstances, such hardware can make malicious pooling of key shares less likely to occur.

[0140] Method 700 of Figure 7 avoids the need to relock digital assets under a new congress public key each time membership changes. Furthermore, in some circumstances, method 700 may update membership sooner than method 600 of Figure 6 because, under method 700 of Figure 7, digital assets are not transferred to a new public key, so no transaction needs to be added to the blockchain to move all digital assets to a new public key. That is, because the public key does not change, membership can be updated using method 700 of Figure 7 without having to wait for several blocks to be generated to confirm the transfer of the digital assets to the new public key.

[0141] Withdrawal from the Congress As previously mentioned, group members may from time to time request to leave a congress, and when group members leave a congress, the digital assets they deposited in the congress pool may be returned to them. Referring now to Figure 8, an exemplary method 800 for returning a deposit is shown in flow chart form. The method may be performed by a node 102 in cooperation with other nodes 102 of the congress.

[0142] In operation 802 of method 800, node 102 receives a withdrawal request from a requester who is a congress member. A withdrawal request may also be referred to as an unsubscription request. A withdrawal request is a request to withdraw a digital asset that was previously deposited by the requester and is currently managed by the congress. This request may be broadcast by the requester to all congress members.

[0143] In response to receiving the request, node 102 evaluates the request against determined criteria in operation 804. Such criteria may be predefined criteria. If the Congress operates according to a Congress protocol in which the Congress public key is not changed every time group membership changes, node 102 may verify that the private key share has been deleted by the requester in operation 804. Such verification may be obtained utilizing a remote attestation protocol associated with the TEE.

[0144] If the Congress protocol is such that the Congress Public Key is changed when membership changes, node 102 may not acknowledge the deletion of the private key share since the private key share is no longer valid. Instead, a new Congress Public Key may be used, and other digital assets under Congress control may be transferred to the new Congress Public Key.

[0145] In operation 804, the evaluation may take into account whether a ghost chain is currently deployed. If the ghost chain is deployed, the withdrawal request may not be satisfied until the ghost chain terminates operation. That is, congress members mining on the ghost chain are prevented from withdrawing their “stake” of digital assets at least until the ghost chain terminates.

[0146] If the nodes 102 approve the withdrawal request based on the evaluation, in operation 806, the nodes facilitate the withdrawal of the digital assets. That is, the nodes 102 use their private key shares to cooperatively generate a digital signature and use the digital signature to transfer to the requester the digital assets previously deposited by the requester. For example, the digital assets may be returned to an address from which they were previously received. Operation 806 is performed according to a threshold signature scheme, so that the withdrawal is accomplished only if at least a threshold number of congress members approve the withdrawal. Operation 806 is performed after a period of inactivity for a member wishing to leave. This waiting period prevents members from engaging in erroneous behavior when a protocol for the return of their member deposits is being performed.

[0147] The Congress Protocol can be used for many different purposes. It provides a secure mechanism to perform a variety of functions, can function without loss of trust, and can control ownership of digital assets.

[0148] The Congress Protocol may, for example, be used to implement a Ghost Chain, in which case it may be referred to as the Ghost Chain Protocol.

[0149] Congress as a hub fail-safe 9, an exemplary method 900 for implementing a fail-safe mode is illustrated in flow chart form. Method 900 may be performed by a node 102 that is a member of a congress 110 in cooperation with other nodes 102 that are members of the congress 110. That is, method 900 may be performed by a node 102 that has already joined a congress by depositing a member deposit into the congress pool, as described above. Thus, a node 102 performing method 900 will have obtained private key shares, as described above, prior to performing method 900 of FIG. 9.

[0150] In operation 902, node 102 detects one or more failsafe activation requests issued by one or more nodes participating in a payment channel with the hub. The payment channel allows commitments for exchanges of value associated with the blockchain network to be exchanged outside of the blockchain network. For example, as described above, value can be exchanged using commitment transactions, and value (for potential breach remedy transactions) can be committed to the blockchain at any time.

[0151] A failsafe activation request is a request issued by a node that previously opened a payment channel by broadcasting a funding transaction as described above in connection with FIG. 3, and particularly operation 304 of the method of FIG. 3. The funding transaction restricts the digital asset with a congress public key (i.e., with a public key associated with a group of nodes that form a congress). More specifically, as described above in connection with FIG. 3, each funding transaction restricts the digital asset with three separate public keys, such that the restriction can be removed by both nodes associated with the payment channel operating together, or by the congress acting alone.

[0152] The failsafe activation request may be of the type described in connection with operation 310 of method 300 of Figure 3. As mentioned in the description of Figure 3, the failsafe activation request may be submitted to a web server that acts as a central repository for failsafe activation requests. Thus, a node performing method 900 of Figure 9 may monitor the web server for failsafe activation requests.

[0153] Each failsafe activation request is generated within the enclave at the request of a node connected to the failing hub and is signed using an enclave private key related to the enclave public key. The failsafe activation request may specify the state of the payment channel. The state of the payment channel is the balance of the payment channel, and the state or balance determines the allocation of the digital assets when the latest state of the payment channel (as reflected by the latest commitment transaction) is taken into account. The failsafe activation request may also include other information. For example, the failsafe activation request may specify the fee offered by the node to close the payment channel. The failsafe activation request may also include freshness data, such as a timestamp. The timestamp or other freshness data may specify the date and / or time when the failsafe activation request was generated or issued. Alternatively, the timestamp may specify the block number of a recent block added to the blockchain of the blockchain network.

[0154] In operation 904, the nodes executing the method 900 evaluate the failsafe activation requests. For example, the nodes may evaluate the freshness of each failsafe activation request. The nodes in the congress can be configured to ignore failsafe activation requests that are expired (i.e., are not considered current enough), and each failsafe activation request may include freshness information, such as a timestamp, that allows the node to determine whether the individual failsafe activation request is expired. For example, the freshness information may be the most recent block number observed by the node that submitted the failsafe activation request, and the group can ignore failsafe activation requests that are determined to be expired based on the block number specified in the failsafe activation request and based on the current block number of the most recent block added to the blockchain. That is, each failsafe activation request may specify a respective block number of the most recent block added to the blockchain of the blockchain network when the failsafe activation request is generated, and the group (i.e., the congress nodes) is configured to ignore failsafe activation requests that are determined to be expired based on the block number specified in the failsafe activation request and based on the current block number of the most recent block added to the blockchain. A node executing method 900 may thus have access to the freshness of a failsafe activation request based on the number of blocks that have elapsed since the failsafe activation request was issued. This number may be compared to a predefined threshold or other criteria to determine whether a given failsafe activation request has expired. For example, the criteria may be that the failsafe activation request was issued a small number of blocks ago compared to a "waiting period" during which the TEE does not process in the payment channel after the failsafe activation request was issued.

[0155] Each failsafe activation request can be mapped by the node executing the method to a particular payment channel, and more specifically to a funding transaction used to open the payment channel. The node can identify the funding transaction associated with a given failsafe activation request because the funding transaction contains the enclave public key that corresponds to the enclave private key used to sign the failsafe activation request.

[0156] In operation 904, the node performing method 900 may determine that the failsafe activation request satisfies predetermined criteria and, accordingly, implement the failsafe mode in operation 906.

[0157] The predetermined criteria may require that a sufficient number of failsafe activation requests (i.e., a sufficient number of failsafe activation requests that have not expired) be received. The sufficiency of the failsafe activation requests may be determined with reference to a threshold. For example, the predetermined criteria may require that a sufficient number of failsafe activation requests (weighted by the balances of the individual nodes issuing such requests) exceed a predetermined threshold.

[0158] In operation 906, the node executing method 900 cooperates with other nodes in the Congress to implement the failsafe mode. In doing so, the node cooperates with other nodes in the Congress to close the payment channel associated with the failsafe activation request. To close the payment channel, a main chain transaction is prepared and proposed, and partial signatures are added to the proposed transaction by enough nodes in the Congress to generate valid signatures on behalf of the Congress. The transaction is broadcast to the blockchain network. This transaction redistributes the digital assets that were previously bound by the Congress public key in the funding transaction that opened the payment channel. More specifically, the digital assets are redistributed based on the state of the payment channel as indicated in the associated failsafe activation request.

[0159] A transaction that closes a payment channel may close multiple payment channels associated with multiple failsafe activation requests. That is, a congress node may perform a batch closure of multiple payment channels in one transaction. Such a batch closure reduces the burden on the main blockchain network (i.e., the main chain). A congress node may implement other load balancing measures for the blockchain network, including, for example, staggered closure transactions. For example, a congress node may wait until broadcasting at least some transactions that close payment channels to ensure that the load does not increase beyond a level that could cause disruptions to the main blockchain network.

[0160] To close a payment channel, the congress nodes cooperatively generate a valid signature for a transaction that closes the payment channel. To facilitate this signing process, a temporary side chain may be deployed by the congress nodes. This temporary side chain may be called a ghost chain. In addition to facilitating the signing of the closing transaction, the ghost chain may also allow another exchange of value between nodes that were previously party to the payment channel connected to the failed hub. That is, a temporary side chain, called a ghost chain, may be deployed before the congress nodes cooperatively generate a valid signature for the transaction that closes the payment channel. The temporary side chain may allow further transfer of value between nodes connected to the hub. Thus, when the payment channel is finally closed, the transaction that closes the payment channel is based on the initial balance in the payment channel as described in the failsafe activation request and the value transferred on the side chain.

[0161] Next, an exemplary ghost chain is described.

[0162] Ghost Chain Referring now to FIG. 10, there is shown a blockchain 1002 and a ghost chain 1004. The blockchain 1002 is a block-based distributed proof-of-work ledger. The ghost chain 1004 is a block-based distributed proof-of-stake distributed ledger that can be used to facilitate closing a payment channel in the event that a hub associated with the payment channel fails.

[0163] A ghost chain is a proof-of-stake blockchain where miners of the ghost chain are members of the congress, i.e., congress members are allowed to mine on the ghost chain. Their member deposits in the proof-of-work blockchain network act as their stake that allows them to mine on the ghost chain, and the probability of any member being selected to mine is proportional to the relative amount of their deposits.

[0164] The ghost chain 1004 is deployed in operation 906 of method 900 of FIG. 9; i.e., when the failsafe mode is implemented. The ghost chain may be instantiated with a genesis block, which is the final block (also referred to as a terminal block) from a previous instantiation of the ghost chain. This block may contain information regarding the genesis payment. The genesis payment is a transfer of digital assets that has not yet occurred based on a previous deployment of the ghost chain.

[0165] A number of blocks are added to the ghost chain by miners in order to generate a valid signature for the transaction, the effect of which is to close the payment channel or to further transfer value between nodes associated with the faulty payment channel (e.g., these nodes may be connected to the failed hub via "spokes"). More specifically, nodes append partial signatures to the proposed transaction using their private key shares until a valid signature is generated according to the threshold signature scheme.

[0166] To close a payment channel, a transaction (which may be referred to as a closure transaction) is constructed and signed (described in more detail below). This transaction will have the effect of distributing funds on the main blockchain 1002 based on the state of the payment channel (and in at least some cases based on any further transactions of value that occur on the ghost chain). The transaction also distributes funds to reward miners on the ghost chain and to make the genesis payment.

[0167] After all payment channels are closed, the ghost chain 1004 terminates. Because the ghost chain 1004 terminates, unlike a typical blockchain, it has a termination block. The termination block can be prepared to include a record of the genesis payment that will be made in the next iteration of the ghost chain. The genesis payment provides an incentive to participants. More specifically, nodes that participated in the payment channel closure but did not receive a transfer of digital assets in return for their participation during that iteration of the ghost chain (e.g., because the closure transaction was prepared prior to their participation) can be referenced in a terminal block, which will result in them receiving digital assets in the next iteration of the ghost chain.

[0168] Although the above examples refer to operation codes available in Bitcoin, the methods described herein may also be used with other types of blockchain networks.

[0169] Although the methods described above have generally been described as being performed at a node, features of the methods rely on coordination with other nodes and may be performed elsewhere.

[0170] It should be noted that the above-described embodiments are illustrative rather than limiting of the invention, and that those skilled in the art may design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the scope of the claims. Words such as "comprises" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "comprises or consists of" and "comprising" means "comprises or consists of". A single reference to an element does not exclude the reference to a plurality 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 items are recited in mutually different dependent claims does not indicate that a combination of these items cannot be used to advantage.

[0171] (Appendix 1) providing an enclave public key from an enclave associated with a trusted execution environment at the node to the hub; establishing a channel with the hub by broadcasting to a blockchain network a funding transaction restricting a digital asset with a first public key, a second public key, and a third public key, the restriction on the digital asset being capable of being lifted by: 1) both a first signature generated from a first private key corresponding to the first public key and a second signature generated from a second private key corresponding to the second public key; or 2) a third signature valid against the third public key, the third public key being associated with a group; receiving a commitment transaction at the enclave from the hub, the commitment transaction being encrypted with the enclave public key; detecting a malfunction of the hub; and issuing a fail-safe activation request to the group using data from the enclave, the data being based on the commitment transaction; The method according to claim 1, (Appendix 2) 2. The method of claim 1, wherein the failsafe activation request specifies a block number of a recent block added to a blockchain of the blockchain network, and the group is configured to ignore failsafe activation requests that are determined to be expired based on the block number specified in the failsafe activation request and based on a current block number of the recent block added to the blockchain. (Appendix 3) determining that a failsafe mode is not being executed and that the failsafe activation request has expired; and issuing another failsafe activation request to the group, the another failsafe activation request including a new block number of a new recent block added to the blockchain; 3. The method of claim 2, comprising: (Appendix 4) 4. The method of claim 1, wherein the step of issuing the failsafe activation request includes a step of automatically sending the failsafe activation request online in response to detecting a malfunction of the hub. (Appendix 5) 5. The method of any one of claims 1-4, wherein the failsafe activation request specifies a fee offered by the node to close the channel. (Appendix 6) 6. The method of any one of claims 1-5, further comprising exchanging value with other nodes via the sidechain after the group deploys the sidechain in response to the failsafe activation request. (Appendix 7) 7. The method of any one of claims 1-6, wherein the failsafe activation request is generated within the enclave and signed using an enclave private key that is related to the enclave public key. (Appendix 8) 8. The method of any one of claims 1-7, further comprising the steps of decrypting the commitment transaction, determining a balance associated with the channel, and determining a value associated with the breach remedy transaction, the value being a previous secret value associated with a previous commitment transaction. (Appendix 9) 9. The method of any one of claims 1-8, further comprising the step of broadcasting a sidechain transaction to deployed sidechain miners in response to the failsafe activation request, the sidechain transaction transferring value. (Appendix 10) detecting one or more failsafe activation requests issued by one or more nodes participating in one or more channels with a hub, the channels allowing commitments for transactions of value associated with a blockchain network to be exchanged outside of the blockchain network, the failsafe activation requests being issued by nodes that previously opened the channel by broadcasting a funding transaction that bounds digital assets with a public key associated with the group; verifying that the one or more fail-safe activation requests meet predetermined criteria; and generating, in cooperation with other nodes in the group, a valid signature for a transaction that closes the one or more channels; The method according to claim 1, (Appendix 11) 11. The method of claim 10, wherein verifying that the failsafe activation requests satisfy a predetermined criteria includes verifying that a number of failsafe activation requests weighted by the balances of the individual nodes issuing the requests exceeds a threshold. (Appendix 12) 12. The method of claim 10 or 11, wherein the failsafe activation requests specify a respective block number of a recent block added to the blockchain of the blockchain network at the time each failsafe activation request is generated, and the group is configured to ignore failsafe activation requests that are determined to be expired based on the block number specified in the failsafe activation request and based on a current block number of the recent block added to the blockchain. (Appendix 13) 13. The method of claim 10, 11 or 12, further comprising: after verifying that the one or more failsafe activation requests meet predetermined criteria and before collaboratively generating the valid signatures, deploying a temporary sidechain that allows value to be further transferred, wherein the transaction closing one or more channels is also based on the value transferred on the sidechain. (Appendix 14) A computer-readable storage medium having computer-executable instructions that, when executed, configure a processor to perform the method of any one of claims 1-13. (Appendix 15) Interface devices; a processor coupled to the interface device; a memory coupled to the processor, the memory storing computer executable instructions that, when executed, configure the processor to perform a method according to any one of claims 1-13; An electronic device having: (Appendix 16) 16. The electronic device of claim 15, wherein the processor includes a trusted execution environment, and the computer-executable instructions are executed in the trusted execution environment.

Claims

1. 1. A computer-implemented method executed by a processing resource for updating private key share distributions, comprising: Detecting a redistribution request; identifying a congress member using one or more attributes included in at least a portion of a transaction to a public group address associated with the congress; in response to detecting a reallocation of the requests, generating new private key shares and transferring all digital assets associated with the public group address to a new public address associated with a new public key; The method includes:

2. 2. The method of claim 1, wherein the processing resource is a node associated with a blockchain network.

3. The method of claim 2 , wherein the nodes are associated with a congress.

4. 2. The method of claim 1, wherein the reallocation request includes detecting that a prospective new member has transferred a digital asset to the public group address.

5. 2. The method of claim 1, wherein the reallocation request includes determining that a member of a group associated with the public group address has requested a withdrawal of a member deposit.

6. 5. The method of claim 4, wherein a prospective new member transfers digital assets by a node requesting to join an associated congress.

7. 2. The method of claim 1, wherein a congress member is identified utilizing the presence of an absence of an attribute indicative of a forwarding purpose.

8. 8. The method of claim 7, wherein a flag is included in a transaction if a forwarder does not request to participate in the conference.

9. 2. The method of claim 1, wherein the generation of the private key share is performed in a trusted execution environment.

10. A computer readable storage medium comprising computer executable instructions which, when executed, configure a processor to perform the method of any one of claims 1-9.

11. interface devices; a processor coupled to the interface device; a memory coupled to said processor storing computer executable instructions that, when executed, configure said processor to perform the method of any one of claims 1-9; An electronic device having:

12. 12. The electronic device of claim 11, wherein the processor includes a trusted execution environment, and the computer-executable instructions are executed in the trusted execution environment.

Images