Secure reuse of private keys for dynamic node groups

Abstract

A computer-implemented method may be provided. The computer-implemented method comprises: i) broadcasting, by a node in a blockchain network, a transaction to transfer one or more digital assets to a public group address associated with a conference public key, the public group associated with one or more other digital assets associated with other members of the conference; ii) generating a private key share to be used in a threshold signature scheme in which at least a threshold of the private key share must be used to generate a valid signature by means of a combination of partial signatures representative of the conference, and wherein the private key share has to be used in the threshold signature scheme. Other holders of the private key share join other members of the conference by transferring respective digital assets to the public group address; and iii) cooperatively generating a valid signature for a transaction from the public group address using the private key share.

Description

[0001] This application is a divisional application of the patent application with Chinese Application No. 201880024757.0 (PCT International Application No. PCT / IB2018 / 052470), filing date of April 9, 2018, and title of "Secure Reuse of Private Keys for Dynamic Node Groups". Technical Field

[0002] The present invention generally relates to distributed ledgers, and more particularly, to methods and systems for providing decentralized control of digital assets associated with a digital ledger. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. They include blockchain and transaction chain technologies, permissioned ledgers and permissionless ledgers, shared ledgers and their variants. It should be noted that the present invention is not limited to use with a particular blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0004] A blockchain is a consensus-based electronic ledger that is implemented as a computer-based decentralized, distributed system consisting of blocks, which in turn consist of transactions and other information. Each transaction can be a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, such that the blocks become linked together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the output of the transaction can be accessed. These scripts can be written using a stack-based scripting language.

[0005] In order to write a transaction to the blockchain, it must be "validated". Certain network nodes work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, the software client installed on a node performs this validation work for transactions that reference unspent transaction outputs (UTXOs). Validation can be performed by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, and if certain other conditions are met, the transaction is valid and can be written to the blockchain. Thus, in order to write a transaction to the blockchain, the transaction must i) be verified by the node receiving the transaction - if the transaction is verified, the node relays it to other nodes in the network; ii) be added to a new block; iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0006] It would be highly advantageous if blockchain could be used for automated tasks and processes. Such a solution would be able to leverage the benefits of blockchain (e.g., permanence of events, tamper-proof records, distributed processing, etc.) while being more versatile in its applications.

[0007] As blockchain technology is extended to provide new features, it is important to maintain the security of the blockchain and the digital assets represented therein. Relying on an extended feature set of the blockchain may be vulnerable to attacks by malicious parties. Accordingly, it is useful to provide methods and apparatus that provide additional security for the blockchain or new features of the blockchain, or that control ownership of digital assets to maintain the integrity of the blockchain.

[0008] Furthermore, as new improvements or modifications to the blockchain are developed, it is helpful to obtain techniques for controlling the transfer of digital assets from one blockchain to another while maintaining the integrity of both blockchains. Accordingly, it is desirable to provide improved methods and apparatus that improve blockchain technology in one or more aspects of these scenarios. SUMMARY OF THE INVENTION

[0009] Accordingly, in accordance with the present invention, there are provided certain methods.

[0010] As described in more detail below, a congress may be formed on a blockchain network. The congress may be an open membership group, and any node in the blockchain network may join the open membership group when sufficient stake is submitted to a pool associated with the congress. For example, a node may join the congress by transferring a digital asset such as a digital currency or other stake or value to a resource (e.g., an account) associated with the congress. The congress may be partially protected by the distributed generation of private key shares. Each private key share may be used by its holder to generate a partial signature of a transaction. A threshold signature scheme may be used to generate a valid signature for such a transaction by using a threshold of at least partial signatures. Member deposits may be forfeited for malicious behavior.

[0011] Advantageously, by using the distributed generation of key shares and other security features, the key shares can be protected against malicious activities by group members or non-group members. This security, combined with the use of a threshold signature scheme, can allow for the formation of autonomous decentralized groups, and such groups can be used for any of a variety of purposes, including, for example, providing two-way anchoring. More specifically, the threshold signature scheme can allow the group to control digital assets obstructed by a public key associated with the group.

[0012] Accordingly, a computer-implemented method can be provided according to the present invention. The computer-implemented method can include: i) broadcasting, by a node in a blockchain network, a transaction for transferring one or more digital assets to a public group address associated with a conference public key, the public group address being associated with one or more other digital assets of other members associated with the conference; ii) generating private key shares to be used in a threshold signature scheme, wherein at least a threshold of the private key shares must be used to generate a valid signature by a combination of partial signatures representing the conference, and wherein other holders of the private key shares are other members of the conference who joined the conference by transferring their respective digital assets to the public group address; iii) cooperatively generating a valid signature for the transaction from the public group address using the private key shares; iv) detecting a request for allocating new key shares; and v) cooperating with other members of the conference to issue private key shares of the same public key for new members of the group.

[0013] In some embodiments, the threshold signature scheme is an elliptic curve digital signature algorithm.

[0014] In some embodiments, the computer-implemented method can further include: i) detecting malicious activities of a malicious party, wherein the malicious party is one of the other members of the conference; and ii) confiscating at least a portion of the digital assets previously transferred by the malicious party to the public group address. In some embodiments, the confiscation can include transferring to an unspendable address, and in some embodiments, can include cooperating with other members of the conference to use the private key shares to generate a valid signature for a transaction to the unspendable address.

[0015] In some embodiments, the computer-implemented method can further include: i) detecting a reallocation request; ii) cooperating with other conference members to transfer all digital assets in the public group address to a new public address associated with a new public key; and iii) generating new private key shares.

[0016] In some embodiments, the computer-implemented method can further include confirming that private key shares previously held by a member who has left the conference have been deleted from the node associated with the member. In some embodiments, the node associated with the member who has left the conference includes a trusted execution environment that provides proof of the deletion of the private key shares previously held by the member. In some embodiments, the trusted execution environment of each member can be configured to periodically prove all transactions they have partially signed and / or they may need to broadcast such proof before their deposits are requested to be returned.

[0017] In some embodiments, the conference public key blocks digital assets received from group members and non-group members, and detecting a request for distributing a new key share includes identifying conference members using attributes included in at least a portion of a transaction of the digital assets to the public group address.

[0018] In some embodiments, the private key share is generated and used on a trusted execution environment within the node.

[0019] In some embodiments, the computer-implemented method may further include: i) receiving, from a requester who is a conference member, a request to withdraw digital assets previously deposited by the requester and currently controlled by the conference; ii) evaluating the request against determined criteria; and iii) using the private key share to cooperatively generate a digital signature and using the digital signature to transfer the digital assets previously deposited by the requester back to the requester.

[0020] According to the present invention, a computer-implemented method can be provided. The computer-implemented method is for confiscating digital assets. The method is implemented by processing resources. The method includes: i) detecting malicious activities of a malicious party, where the malicious party is one of the other members of the conference; and ii) confiscating at least a portion of the digital assets previously transferred by the malicious party to a public group address.

[0021] In some embodiments, confiscating at least a portion of the digital assets includes: transferring to an unspendable address.

[0022] In some embodiments, transferring to the unspendable address includes: cooperating with other members of the conference to use the private key share to generate a valid signature for a transaction to the unspendable address.

[0023] In some embodiments, malicious activities are detected when it is determined that a node associated with the malicious party violates a predetermined protocol or criterion.

[0024] In some embodiments, malicious activities are detected at a node that reports error information to other members of the conference.

[0025] In some embodiments, confiscating a portion of the digital assets includes transferring to an unspendable address.

[0026] In some embodiments, the confiscation includes: cooperating with other members of the conference to use the private key share to generate a valid signature for a transaction to a spendable address.

[0027] In some embodiments, verifiable secret sharing is used for malicious behavior.

[0028] In some embodiments, malicious behavior is detected by determining that a node provides inconsistent key shares.

[0029] In some embodiments, the method further comprises: i) detecting a reallocation request; ii) cooperating with other meeting members to transfer all digital assets in the public group address to a new public address associated with a new public key; and iii) generating a new private key share.

[0030] According to the present invention, an electronic device can be provided. The electronic device includes: an interface device; a processor coupled to the interface device; and a memory coupled to the processor. Computer-executable instructions are stored on the memory, and when executed, the computer-executable instructions configure the processor to perform the methods described herein.

[0031] According to the present invention, a computer-readable storage medium can be provided. The computer-readable storage medium includes computer-executable instructions, and when executed, the computer-executable instructions configure the processor to perform the methods described herein.

[0032] According to the present invention, a computer-implemented method can be provided, comprising: in a node in a blockchain network, the node broadcasts a transaction for transferring one or more tokens to a public group address associated with a meeting public key, the public group address being associated with one or more other tokens of other members associated with the meeting; generating, using a secure area of the processor of the node, a private key share to be used in a threshold signature scheme, in which at least a threshold of the private key shares must be used to generate a valid signature by a combination of partial signatures representing the meeting, and wherein the other holders of the private key share are the other members of the meeting who joined the meeting by transferring their respective tokens to the public group address; and using the private key share of the secure area to cooperatively generate a valid signature for the transaction from the public group address.

[0033] In some embodiments, the secure area can be a trusted execution environment.

[0034] In some embodiments, the secure area may store a BGLS private key (which may be a private key associated with an aggregate signature scheme, such as the Boneh, Gentry, Lynn, and Shacham "BGLS" scheme (Aggregate and Verifiably Encrypted Signatures from Bilinear Maps. International Conference on the Theory and Applications of Cryptographic Techniques, EUROCRYPT 2003: Advances in Cryptology - pp 416 - 432)). The method may further include generating the BGLS private key of the secure area. The registration transaction includes information corresponding to the latest block on the blockchain associated with the blockchain network, information corresponding to the latest block on another blockchain suitable as a broadcast channel for communication among conference members, and a hash of the initial content of the memory within the secure area that is signed using the proof key of the secure area and bound to the public key associated with the BGLS private key. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Referring to the embodiments described herein, these and other aspects of the invention will become apparent and be elucidated. The embodiments of the invention are described below only by way of example and with reference to the drawings, in which:

[0036] Figure 1 A block diagram showing an exemplary blockchain network is presented.

[0037] Figure 2 A block diagram showing an exemplary electronic device that may act as a node in a blockchain network is presented.

[0038] Figure 3 A flowchart of an exemplary method for initiating a conference is shown.

[0039] Figure 4 A flowchart of an exemplary method for joining a conference is shown.

[0040] Figure 5 A flowchart of an exemplary method for seizing digital assets is shown.

[0041] Figure 6 A flowchart of an exemplary method for re - distributing key shares is shown.

[0042] Figure 7 A flowchart of another exemplary method for re - distributing key shares is shown.

[0043] Figure 8 A flowchart of an exemplary method for returning a deposit is shown.

[0044] Figure 9 is a block diagram of the first and second blockchain networks.

[0045] Figure 10 is a flowchart of an exemplary method for providing two-way anchoring. DETAILED DESCRIPTION

[0046] Blockchain network

[0047] First, refer to Figure 1 . Figure 1 An exemplary blockchain network 100 associated with a blockchain is shown in block diagram form. The blockchain network can be a public blockchain network, which is a peer-to-peer open membership network where anyone can join without an invitation or the consent of other members. Distributed electronic devices running an instance of the blockchain protocol (under which the blockchain network 100 operates) can participate in the blockchain network 100. Such distributed electronic devices can be referred to as nodes 102.

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

[0049] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies, which can include wired and wireless communication technologies. Such communication follows the protocol associated with the blockchain.

[0050] The nodes 102 maintain a global ledger of all transactions on the blockchain. Thus, the global ledger is a distributed ledger. Each node 102 can store a complete copy or a partial copy of the global ledger. For example, a block can include 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, the block serves as a record of the transaction from one address to another. The party requesting that the transaction be included in the block proves that they are authorized to initiate the transfer by signing the request using the private key corresponding to their public key. If the request is effectively signed, only the transfer is added to the block.

[0051] There can be a one-to-one correspondence between the public key and the address. That is, each public key is associated with a single address. Thus, any reference herein to transferring a digital asset to or from a public key (e.g., paying into a public key) and transferring a digital asset to or from the address associated with the public key refers to the same operation.

[0052] Some nodes 102 participate as verification nodes. Transaction verification may involve checking the signature(s), confirming references to valid UTXOs, etc.

[0053] Figure 1 An example includes five nodes 102, three of which are mining nodes 104. In practice, the number of nodes 102 or mining nodes 104 can vary. In many blockchain networks, the number of nodes 102 and mining nodes 104 can be much larger than Figure 1 the number shown.

[0054] As described below, various nodes 102 can cooperate to form a group that will be referred to herein as session 110. In the example shown, three nodes 102 are shown as participants in session 110. However, the actual number of session 110 members can be much larger.

[0055] Session 110 is an open membership group that can be joined by any node 102 when sufficient stake is submitted to a pool associated with session 110. For example, a node can join the session by transferring digital assets (such as digital currency, tokens, or other stakes or values) to an account associated with session 110. A node 102 joining the session can be any node in the blockchain network, including mining nodes and non-mining nodes. In at least some applications of the session (such as when the session performs two-way anchoring as described below), the nodes acting as session members monitor the blockchain in the sense that they download (but do not necessarily retain) the complete blockchain.

[0056] In various known systems involving groups formed by nodes of a blockchain network, group membership is fixed. In contrast, nodes can join and leave session 110. Conveniently, by allowing such flexible group membership, session 110 can reduce overhead compared to systems such as SecureCoin by avoiding the need to repeatedly form node groups from scratch.

[0057] The techniques for joining, leaving, and participating in session 110 are discussed in more detail below.

[0058] An electronic device operating as a node

[0059] Figure 2 is a block diagram showing the components of an exemplary electronic device 200 that can act as a node 102 in a peer-to-peer blockchain network 100 ( Figure 1 ). Figure 1)。The exemplary electronic device 200 may also be referred to as a processing device. The electronic device may take various forms, such as including a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smartwatch, or other types of forms.

[0060] 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, which include machine-readable instructions and data for performing the 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 the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to implement a protocol associated with the blockchain network 100( Figure 1 )).

[0061] The memory 220 may store the global ledger of the blockchain network 100( Figure 1 ) or a part thereof. That is, the memory 220 may store all the blocks of the blockchain or a part of the blocks, such as the latest block, or some of the information in some blocks.

[0062] Although the memory 220 is shown as a single box in Figure 2 , in fact, the electronic device 200 may include multiple memory components. The memory components may be of various types, such as including RAM, HDD, SSD, flash drives, etc. Different types of memory may be suitable for different purposes. In addition, although the memory 220 is shown separately from the processor 210, the processor 210 may also include embedded memory.

[0063] As Figure 2As shown, the processor 210 may include a secure area 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 asset confidentiality. The TEE 250 provides an execution space that ensures that the computer instructions and data loaded within the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 can be used to protect the integrity and confidentiality of important resources (such as keys). The TEE 250 is at least partially implemented at the hardware level, such that the instructions and data executed within the TEE 250 are protected from access and manipulation from the rest of the electronic device 200 and external parties such as the owner of the electronic device. The data and computations within the TEE 250 are protected from the party operating node 102 that includes the TEE 250.

[0064] The TEE 250 can operate to instantiate an enclave and then add pages of memory one at a time while cumulatively hashing. Similar operations can also be performed on a remote machine (which can 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 runs an approved algorithm. Verification can be performed by comparing the hashes. Once the enclave is fully built, it is locked. Code can be run in the TEE 250 and secrets can be sent to the code, but the code cannot be changed. The final hash can be signed with a proof key and made available to the data owner to verify it before the data owner sends any secrets to the enclave.

[0065] The TEE 250 can be used to protect the confidentiality and integrity of the private key share associated with the conference public key used by the conference 110( Figure 1 )). For example, the TEE 250 can be used for the generation and storage of private key shares. The purpose of the TEE 250 is to ensure that no member can directly obtain the private key share maintained within the TEE 250 enclave or obtain information about other private key shares through member - to - member communication or cross - enclave communication. The protocol is also robust against enclave threshold compromises. In addition, the TEE 250 can enable remote attestation, which can be used by node 102( Figure 1 ) to prove to other node 102s that the TEE 250 is trusted and is running approved computer - executable instructions for the protocol implemented by the conference 110. The remote attestation can be provided by the TEE 250 by running a specific code segment and sending the hash of the code within the enclave, and the hash of the code is signed with an internal proof key for the enclave.

[0066] When a member of session 110 who previously used a private key share on electronic device 200 chooses to leave the session, TEE 250 can be used to prove the secure deletion of the private key share. The electronic device 200 can provide a deletion proof to other session members through the remote attestation protocol provided in TEE 250. A deletion proof may be required before allowing a member to withdraw their member deposit. That is, the return of the deposit can be conditional on proving the deletion of the private key share within the enclave of the member.

[0067] TEE 250 can be equipped with a secure random number generator, which is inside the enclave of the TEE and can be used to generate private keys, random challenges, or other random data. TEE 250 can also be configured to read data from external memory and can be configured to write data to external memory. This data can be encrypted with a secret key that is only kept inside the enclave.

[0068] Various platforms (such as Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX)) can be used to implement TEE 250. For example, SGX supports remote attestation, which enables an enclave to obtain a signed statement from the processor on which a particular enclave is executing, and the particular enclave has a given member called a reference. A third-party attestation service such as Intel Attestation Service (IAS) can attest that these signed statements originate from a trusted CPU that complies with the SGX specification.

[0069] Electronic device 200 acts as a node 102 ( Figure 1 ) in blockchain network 100 ( Figure 1 ), and can join or otherwise participate in session 110 ( Figure 1 ). A session 110 forms when a group of digital asset holders pool digital assets (such as digital currency, tokens, or other rights or values supported by blockchain network 100 ( Figure 1 )).

[0070] Sessions and Threshold Signatures

[0071] Session 110 can be a permissioned or non-permissioned group. That is, any node 102 ( Figure 1 ) in blockchain network 100 ( Figure 1(i.e., any node that monitors and stores at least a portion of the information in the blockchain) can join Conference 110. To join Conference 110, Node 102 transfers one or more digital assets to a digital asset pool associated with Conference 110 (i.e., transfers to a common group address associated with one or more digital assets, which are correspondingly associated with other members). This digital asset pool can be referred to as the conference pool. For example, Node 102 can join Conference 110 by transferring (i.e., depositing) such digital assets to an address associated with the conference pool (i.e., transferring to a "conference address" which can also be referred to as a common group address). The digital assets are placed under the control of a group threshold signature with a single public key (referred to as the conference public key). Conference members hold distributed private key shares. The number of shares held can be proportional to the amount deposited in the pool.

[0072] The digital assets controlled by Conference 110 (including any digital assets transferred to the conference address) are placed under the control of a threshold signature scheme. Under the threshold signature scheme, a set of members holding a total private key share exceeding the threshold is required to generate a valid signature that allows the digital assets to be transferred out of the control of Conference 110. That is, at least the threshold number of private key shares must be generated to produce a valid signature for any outward transfer of the digital assets controlled by Conference 110.

[0073] The conference public key blocks the digital assets deposited by the members of Conference 110 in exchange for private key shares, as well as any digital assets deposited by members or non-members of Conference 1100 at an address associated with the conference pool (i.e., placed under the full, partial, or conditional control of the conference) (any such digital assets that have been deposited for reasons other than obtaining private key shares). Members or non-members can deposit digital assets at an address associated with the conference for various reasons. In one example explained in more detail below, a member or non-member can deposit digital assets into Conference 110 to move these assets to another blockchain, which can be referred to as an alternative chain, such as a side chain. A side chain can be a blockchain that runs parallel to the main blockchain (i.e., parallel to the main chain).

[0074] Because the same conference public key can control member deposits (i.e., digital assets provided by conference members in exchange for private key shares) as well as digital assets provided by members or non-members for other purposes, at least a portion of the deposits to the address associated with the conference may be specially marked to indicate the type of deposit. For example, a transaction transferring digital assets to the conference address may include a tag, identifier, or other attribute indicating the nature of the deposit being made. By way of example, a transaction transferring digital assets to the conference address that is not for the purpose of joining the conference or increasing the stake in the conference membership may include a special identifier to indicate that the deposit is being made for other purposes. These identifiers can be used by node 102 associated with conference 110 when managing private key generation. More specifically, node 102 that deposits digital assets to join the group is assigned a private key share for conference 110 (as a result of making the digital asset deposit), while other nodes 102 that deposit digital assets for other purposes (e.g., transfer to a side chain) do not necessarily hold the conference private key share for the conference (i.e., corresponding to the conference public key).

[0075] Conference 110 can act as an autonomous group where cooperative behavior is enforced by the threat of forfeiting all or part of the member deposits. Non-cooperative or malicious members may have such digital assets forfeited due to joining a cooperative agreement in which many honest members participate. That is, to ensure that all nodes 102 operate according to a predefined protocol or guideline, member deposits entering the conference pool may be forfeited. Forfeiture means permanently preventing the return of the member deposits deemed forfeited. The (one or more) digital assets forming the member deposits that are not returned due to malicious activity can remain in the conference pool but not be returned (e.g., if there is a consensus (on an alternative chain) that they should not be returned), be transferred immediately or in the future to another non-spendable address, or otherwise forfeited, and the nature of the forfeiture may depend on whether the conference acts as a bonded validator set for a side chain.

[0076] In addition, when conference members wish to leave conference 110, they can withdraw their member deposits (i.e., request that conference 110 transfer the member deposits back to the member's personal address). However, the funds are only withdrawn when the group members (i.e., the conference) use multiple private key shares (the number of which exceeds the threshold required to generate a valid digital signature) to approve the withdrawal.

[0077] The threshold signature scheme implemented by Conference 110 can be of various types. A threshold signature scheme allows the sharing of the signature right among n parties, as long as at least the threshold number of private key shares contribute to generating a valid signature. Any subset smaller than the threshold cannot generate a valid signature. More specifically, each party controls a share of the private signature key and must use the threshold number of key shares to generate a valid signature by combining partial signatures. Any subset of key shares smaller than the threshold cannot generate a valid signature.

[0078] The threshold signature scheme can be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. For example, the ECDSA scheme can 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, which is an algorithm based on elliptic curve cryptography, where t + 1 key shares from n key share holders are required to reconstruct the private key. This scheme can be used to construct a valid signature without reconstructing the private key, and no party has to disclose its key share to another party.

[0079] Since t + 1 key shares are sufficient to reconstruct the secret, the maximum number of allowed adversaries according to this technology is t. In the model of Ibrahim et al., an adversary is an entity that compromises a party holding a secret share and can access that secret share. Adversaries can be of various types. For example, Byzantine adversaries are those who may pretend to participate in the protocol while actually sending incorrect information. The ECDSA scheme proposed by Ibrahim is robust against up to t <= n / 4 malicious adversaries. This robustness can be increased to t <= n / 3, but at the cost of higher complexity.

[0080] The ECDSA scheme of Ibrahim et al. is robust against t <= n / 3 stopping adversaries. Stopping adversaries can prevent a compromised party from participating in the protocol or from stopping participation midway.

[0081] The ECDSA scheme includes various mechanisms that can be used by node 102 to identify malicious or uncooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials required for Shamir secret sharing (SSS). SSS is a form of secret sharing in which a secret is divided into several parts and each participant is provided with its own unique part. These parts can be used to reconstruct the secret. In the case where inconsistent shares are provided to different nodes 102, or in the case where shares different from the blinded shares broadcast to all nodes are secretly sent to a node, node 102 can use VSS to identify malicious nodes 102 or members. Inconsistent shares can be identified by any one of the nodes 102. The sharing of the secret can be made verifiable by including auxiliary information that allows node 102 to verify its share as consistent.

[0082] Sending incorrect shares (i.e., shares different from the broadcast blinded shares) to individual nodes can be identified by the intended recipient nodes of the shares. The identification of incorrect shares secretly sent to a node can be publicly verified using publicly verifiable secret sharing (PVSS) techniques. Such techniques can avoid the possible delays that may occur in the identification of cheating senders when PVSS is not used, and when incorrect shares are sent, the recipients of the incorrect shares are offline or cut off from a substantial part of the network.

[0083] Misconduct such as providing inconsistent shares to different nodes can be addressed by the session 110 to deter malicious behavior. For example, when a node 102 ( Figure 1 ) is identified as a malicious party by other nodes 102, multiple nodes 102 (i.e., nodes associated with the session members) exceeding a threshold (e.g., t + 1) can cooperate to punish the malicious party. For example, node 102 can take actions involving digital assets (such as digital currency, tokens, or other rights or values) deposited by the malicious party into the session. For example, the session can burn them by transferring the digital currency, tokens, rights, or values to an unspendable address, or the session can confiscate these digital assets by reaching a consensus with other nodes to deny them. Nodes 102 that are not misbehaving can also deter misconduct 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 session protocol, or by resharing the private key instead of allocating shares to the misbehaving node).

[0084] The above ECDSA technology can be enhanced by using a TEE. For example, consider a powerful form of adversary, called a Byzantine adversary here, based on the threshold ECDSA signature technology of Ibrahim et al. This type of adversary can act arbitrarily. For example, they can not only refuse to participate in the signature process or stop participating midway, but may also pretend to participate honestly and send incorrect information. However, by using a TEE and generating data for signing within the enclave of the TEE that stores the secret private key shares, additional security can be provided because it is highly unlikely that a large number of enclaves will be compromised. For example, if each TEE is assigned no more than one key share, then it can be reasonably expected that the number of TEEs that may be compromised will not be close to the robustness threshold of the Byzantine adversary, assuming n is large enough. This allows the protocol to be secure if it can tolerate a small fraction of malicious adversaries relative to the total number of key shares.

[0085] For example, if all nodes have a TEE, then access to the secrets stored within the enclave can only be achieved through physical access to the nodes with great effort and expense, and only if the manufacturer of the TEE has not been compromised. This level of manufacturer compromise is expected to be manageable. For example, if the manufacturer falsely claims that many public keys correspond to genuine TEEs, they can directly access 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 a valid signature without the help of other nodes. This would mean accumulating a large portion of the total stake, which would be very expensive. Additionally, by carrying out the attack, a large portion of the value of the stake holdings would be destroyed.

[0086] When using a TEE, it is useful to consider the robustness of the protocol against "compromised nodes". Compromised nodes cause the hardware outside the TEE to be compromised, but the integrity of the TEE remains unimpaired. Compromised nodes can control what information the enclave receives and does not receive. Specifically, a compromised node can stop, i.e., refrain from participating in the protocol. If the information provided to the protocol is signed using a private key secretly held in the enclave (where the corresponding public key is authenticated during the proof), the private key is as trustworthy as the enclave itself. Thus, a compromised node cannot send arbitrary (authenticated) information to the protocol and can only attempt to interfere by stopping or trying to deceive the enclave into acting incorrectly (e.g., by providing it with outdated information). Therefore, for a compromised node, a successful attack would require collecting a sufficient number of partial signatures to produce a complete signature. Through the TEE, the protocol by Ibrahim et al. is robust against 2t compromised nodes. Because if n - 2t >= 2t + 1 can produce a signature, then any eligible subset of key shares of size 2t + 1 <= (n + 1) / 2 suffices. Thus, when using a TEE, the threshold of the threshold signature scheme can be configured as a number greater than or equal to 50% of the key shares, so as to produce a valid signature in the presence of compromised nodes.

[0087] Other threshold signature schemes can also be used. For example, some types of ECDSA threshold schemes. This protocol allows t + 1 parties to produce a valid signature. Thus, the number of key shares that an adversary must control to produce a valid signature is equal to the number of key shares that an adversary must possess to reconstruct the private key. In cases where unanimous consent is required to produce a valid signature, this technique can provide an effective solution. In the most general case, this solution imposes a space requirement that scales exponentially with the number of conference members, because for any threshold, the entire protocol needs to be repeated for any possible subset of t + 1 players out of n players. Thus, for large values of both n and t, a large amount of key shares will need to be stored. To mitigate this storage requirement, standard multisignatures can be combined with threshold signatures. Specifically, multisignatures can be used to lock digital assets, thereby dividing each private key into multiple shares. In terms of space requirements, this technique will make larger conferences more efficient. The scalability property can also be improved by composing the scheme for a large number of participants from smaller-sized parties in a recursive manner at multiple levels. For example, the threshold signature scheme can be combined with the technique proposed by Cohen et al. in "Efficient Multiparty Protocols via Log-Depth Threshold Formulas (2013), Advances in Cryptology - CRYPTO 2013 pp 185 - 202".

[0088] Other threshold schemes can be used, including non-ECDSA signature schemes. For example, node 102 can use a threshold scheme based on the Schnorr scheme to implement session 110.

[0089] Node 102( Figure 1 ) in blockchain network 100( Figure 1 ) can implement the session protocol based on the selected threshold signature scheme. Such a node 102 may include computer-executable instructions stored in memory 220( Figure 2 ) that implement the session protocol. When executed by processor 210( Figure 2 ), such instructions cause node 102 (such as the type of electronic device 200 described with reference to Figure 2 ) to perform one or more methods of the session protocol. These methods may include Figures 4 to 8 any one or combination of methods 300, 400, 500, 600, 700, 800 of Figures 4 to 8 . Thus, the session protocol may include

[0090] a combination of one or more of methods 300, 400, 500, 600, 700, 800 of

[0091] . These methods may be performed by the node in cooperation with other nodes associated with other session members. Figure 3

[0092]

[0093]

[0094] Session startup

[0091] Next, with reference to Figure 3 , method 300 for starting session 110 is shown. Method 300 may be performed by an initial trust party to establish session 110. That is, node 102 associated with the initial trust party may perform method 300.

[0092] Method 300 includes providing a session public key in operation 302. The session public key may be provided to other nodes 102 to allow other nodes to pay to the session public key when they wish to join the session. That is, others may transfer digital assets to the address associated with the session public key, thereby joining the session.

[0093] In operation 304, node 102 performing method 300 allows payments to the public key until one or more conditions are met. For example, for a determined time period or a determined number of blocks, the node may allow payments to the public key. After the conditions are met (e.g., after the time period expires or the number of blocks is mined), node 102 performing method 300 identifies the initial members of the session in operation 306.

[0094] After identifying the parties including the initial membership of the meeting, at operation 307, the private key is divided into private key shares according to a threshold signature scheme. Then at operation 308, the private key shares are distributed from node 102 performing method 300 to the identified parties. The private key shares are associated with a threshold signature scheme, which can be of the type described herein.

[0095] During operation 308, node 102 identified as a meeting member cooperates to generate new private key shares and a new public key. The original key shares sent to these nodes by the initial trust party can be used to sign and broadcast transactions to send all digital assets in the meeting pool to the new public key, which then becomes the meeting public key. That is, during operation 408, a new group public address is established, and the digital assets under the control of the meeting are transferred to this new address, which becomes the new address of the group and is associated with the meeting public key. After confirming this transfer, the meeting can operate without trust. The new group public address is formed as an address where deposits of digital assets can be received in the future from other nodes that wish to join meeting 110, or for other purposes as described above. Now the meeting members are considered to have joined the meeting, and these nodes can now operate without the help of the initial trust party. In addition, the initial trust party no longer plays any role in the operation of the meeting.

[0096] Joining the meeting after the meeting has started

[0097] The following refers to Figure 4 , Figure 4 illustrating method 400 for joining a meeting. Figure 4 Method 400 of Figure 3 can operate in combination with Figure 4 method 300 of Figure 3 , however, Figure 1 method 400 of Figure 4 is performed by a different node among nodes 102 operating in the same blockchain network 100 ( Figure 3 ) in which method 300 of Figure 1 is performed. Figure 4 Method 400 of Figure 3 includes obtaining the meeting public key at operation 402. The meeting public key can be obtained directly from a party initiating the meeting, such as the node performing Figure 1 method 300, or can be obtained from a third party, such as a third-party system operating outside of blockchain network 100 ( Figure 1 ). For example, the meeting public key can be obtained from a public web server accessible via the public Internet.

[0098] The node 102 performing method 400 pays to the conference public key in operation 404 by broadcasting a transaction of digital assets from a private account associated with the node 102 to the conference address (i.e., the address associated with the conference 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 conference public key. The public group address is the address of the conference pool. The conference pool includes other digital assets associated with other members of the conference. Thus, once the transaction in operation 404 is added to the block by the mining node 104, the digital assets are transferred to the conference pool that includes the digital assets of other members. The public group address can receive transfers from parties who wish to join the conference and also from parties who do not wish to join the conference. The parties who do not wish to join the conference transfer digital assets to the conference pool so that the conference can exercise full, partial, or conditional control over these digital assets by using the threshold signature scheme adopted by the conference.

[0099] The transaction in operation 404 may include a tag, identifier, or other attribute that indicates that the party transferring the digital assets wishes to join the conference and that the deposit is made for this purpose.

[0100] After depositing digital assets through the conference pool, the node 102 performing method 400 receives a private key share in operation 406. Then, the node 102 regenerates the private key share in operation 408 by running a single instance of the protocol. The generation of the private key share can be performed within the TEE of the node 102.

[0101] In operation 408, the node 102 generates a private key share to be used in the threshold signature scheme, where at least a threshold of the private key shares must be used to represent the conference to generate a valid signature for a transaction. The holders of the other private key shares are the other members of the conference who join the conference on a permitted or unpermitted basis by transferring the corresponding digital assets to the public group address.

[0102] To regenerate the private key share, in operation 408, the existing conference members can cooperate to update the key share. For example, the node 102 can generate a random polynomial of degree t with a zero constant term Then, the node 102 can compute the points and set them as their private key shares. Then, the node 102 can broadcast the polynomial Points on the are assigned to each existing conference member \(i = 1,\ldots,n\). Then, each existing conference member \((i = 1,\ldots,n)\) adds the received value to its existing private key share to obtain a new private key share. Node 102 now has a private key share equivalent to that of all other members, and the corresponding public key remains unchanged. As described above, the threshold signature scheme can be of various types, including the Elliptic Curve Digital Signature Algorithm or a threshold scheme based on the Schnorr scheme.

[0103] The private key share can be generated within the TEE 250( Figure 2 ) and can be securely stored in node 102. For example, the private key share can be stored in the TEE 250.

[0104] After the private key shares are generated by the respective nodes, funds under the control of the previous conference public key, such as funds transferred to a common group address associated with the original conference public key (through the cooperation of a sufficient number of group nodes to generate a valid signature under the threshold signature scheme), can be transferred to a new conference public key associated with the new private key share.

[0105] After the private key shares are generated in operation 408, they can be used under operation 410 of method 400. The private key shares can be used to cooperatively generate a valid signature for a transaction from a common group address that can be broadcast by members. That is, the private key shares can be used in the threshold signature scheme to assist in signature generation. Under the threshold signature scheme, a threshold number of private key shares of the conference need to be used by the respective members to produce a valid signature, and the signature allows the transfer of digital assets out of the conference. Node 102 performing method 400 can retrieve the private key shares from storage and use the private key shares to assist in signature generation. If a sufficient number of other conference members also use their respective private keys to assist in signature generation, then the signature is generated and a valid outgoing transaction can be broadcast. When the mining node 104 of the blockchain network 100 adds the transaction to the mined block added to the blockchain through the consensus of the nodes in the blockchain network 100 and the block is confirmed, the outgoing transaction is completed. At this time, the digital assets represented in the transaction can no longer be controlled by the conference. That is, such digital assets can no longer be blocked by the conference public key.

[0106] The use of the private key shares in operation 408 can be performed within the TEE of node 102. The TEE protects the private key shares such that no other part of the system or the members themselves can access any data stored in the enclave, such as the private key shares. In addition, the TEE protects the private key because if a member wants to get back their deposit and withdraw their deposit, it cannot retain a copy of the private key because it must delete the private key before proving the return of the member's deposit.

[0107] Figure 4Method 400 can be performed during or after the initial setup phase. That is, method 400 can be performed before the initial key shares are allocated (e.g., during operation 308 of method 300 of Figure 3 ) or after (e.g., during rebalancing, which will be discussed in more detail below).

[0108] At operation 410, a transaction can transfer the digital assets back to the party that initially deposited the digital assets into the conference pool. That is, the transfer can return the digital assets to the depositor. The transfer can also transfer the digital assets elsewhere. For example, the digital assets can be transferred to a third party or an unspendable address.

[0109] Confiscation of Digital Assets

[0110] Reference is made below to Figure 5 to illustrate an exemplary method 500 for confiscating digital assets. Figure 5 Method 500 can be performed by node 102, which can be the same node as the node performing Figure 4 method 400. Method 500 can be performed after operation 408 of method 400, such that when method 500 is performed, node 102 already has access to the private key share. Figure 4 Figure 5

[0111]

[0112] At operation 502, node 102 detects malicious activity by a malicious party. The malicious party can be another member of the conference. Malicious activity is detected when node 102 determines that a member of the conference has violated a predetermined protocol or guideline. For example, when a node that is a member of the conference reports incorrect information (i.e., errors, inconsistencies, or other unacceptable information) to other members of the conference, that member can be considered a malicious member.

[0113] At operation 503, in response to detecting the malicious activity, node 102 can cooperate with other nodes in the conference to suspend the member that is the malicious party. That is, the conference can exclude the malicious party from further participating in the conference.

[0113] In order to ensure that all nodes 102 operate in accordance with a predetermined protocol or criteria, member deposits entering the conference pool may be confiscated. Confiscation means permanently preventing the return of member deposits that are deemed confiscated. (One or more) digital assets that constitute member deposits that are not returned due to malicious activity may remain in the conference pool but not be returned (in response to a consensus that the action should be taken), be transferred to another non-consumable address immediately or in the future, or be confiscated in other ways, and the nature of the confiscation may depend on whether the conference acts as a collateral validator set for the side chain. For example, in operation 504, in response to detecting malicious activity by a malicious party, the node 102 performing method 500 may use a private key share to provide a partial signature on a confiscation transaction (which is a transaction that transfers a digital asset to a non-consumable address or another node as a reward for exposing the malicious activity). That is, the node cooperates with other nodes of the conference to confiscate at least a portion of the digital assets previously transferred to the public group address (i.e., transferred to the conference pool) by the malicious party. That is, in response to observing a group member violating a predetermined protocol or guideline, a private key share is used to facilitate authorization of a transaction of one or more digital assets associated with the group member and held in the conference pool.

[0114] Because the threshold signature scheme is used with the conference public key, individual nodes acting alone cannot transfer the deposit of another conference member's digital assets out of the conference pool (e.g., to an unconsumable address). In contrast, when a threshold number of private key shares are used by their respective members to generate a valid signature to transfer digital assets (multiple) to another address, or when a member group with at least a threshold number of private key shares reaches a consensus to suspend a member (in operation 503), digital assets can only be confiscated by transfer, which causes any withdrawal request from the suspended member to be automatically ignored. When a digital asset is confiscated by transfer, other addresses to which (one or more) digital assets can be transferred can be associated with an unconsumable address. For example, another address can be an address where a private key does not exist, so no party can access the digital assets bound by the public key of the address. When confirming a transaction to transfer a digital asset to an unconsumable address or when a consensus is reached on the side chain that a digital asset should be confiscated, the digital asset may be considered to have been burned because they can no longer be consumed by any member of the conference or in fact by any node in the blockchain network 100.

[0115] Thus, at operation 504, the node may confiscate the digital asset by using the private key share in cooperation with other members of the conference to generate a valid signature for a transaction to a non-spendable address, and in some embodiments may involve reaching a consensus on the second blockchain that the member's deposit should be permanently deprived of all or part of it.

[0116] In addition, in some embodiments, the meeting can act as a set of guarantee verifiers to ensure the proof-of-stake side chain, and this side chain can be used as a broadcast channel. For example, the meeting members can reach a consensus on the side chain that a member has acted maliciously. This consensus can correspond to the confirmation of a side chain transaction that includes evidence of the accusation of malicious activity. After reaching the consensus, any request by the malicious member to withdraw the member's deposit will be rejected, and the deposit will be considered forfeited. The forfeited digital assets may be burned at some point in the future. That is, at some later time, a threshold number of members (excluding the malicious member) can cooperate to authorize the transfer of the forfeited digital assets to an unspendable address.

[0117] Since the meeting is an open group that can be joined by any node 102 of the blockchain network 100 by storing digital assets, the group membership can change periodically. When such a change occurs, the private key share distribution can be updated. The following refers to Figure 6 to show an exemplary method 600 for updating the private key share distribution. The method 600 can be carried out by the node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0118] Updating the private key share distribution using a new public address

[0119] In operation 602 of method 600, the node 102 detects a reallocation request, which is a request whose implementation involves reallocating key shares. For example, the node 102 can detect that a potential new member has transferred digital assets to the public group address or an existing member has requested to withdraw the member's deposit.

[0120] Digital assets can be transferred to the public group address by the following nodes: nodes that request to join the meeting or increase their participation in the meeting and other nodes that do not request to join the meeting but transfer digital assets to the meeting for other purposes (such as transferring digital assets to the side chain, as described below). In operation 602, the node 102 can use one or more attributes included in at least a part of the transaction of the digital assets to the public group address to identify the meeting members (i.e., the parties that transfer digital assets to the meeting public key to join the meeting rather than for other purposes). For example, certain transactions can be marked as special transactions using the attributes in the transaction. These attributes (whether present or not) can indicate the purpose of the transfer. For example, a mark can be included in the transaction when the transferrer does not request to join the meeting.

[0121] In response to detecting a request whose implementation involves reallocating key shares in operation 602, in operation 604, the node 102 acts in a similar manner as in Figure 4Operation 408 of method 400 generates a private key share in a way that generates a new private key share. Other member nodes of the meeting also generate corresponding private key shares. These private key shares can be used with a threshold signature scheme for the new meeting public key. Members leaving the meeting at this time do not generate new private key shares during operation 604 and since they will not be assigned private key shares to be used with the new meeting public key, they lose the ability to participate in the meeting and are no longer considered meeting members.

[0122] In addition, in response to detecting a reallocation request (a reallocation request is a request whose implementation involves reallocating key shares), at operation 606, node 102 cooperates with other meeting members to transfer all digital assets in the public group address to a new public address associated with a new public key (which will later become the new meeting public key).

[0123] Thus, according to Figure 6 method 600, when the distribution of deposits changes or when a request to withdraw a deposit is received from a member, the private key shares can be regenerated, and all digital assets under meeting control can be moved to the new public key. The frequency at which meeting membership can be updated is limited by the block time of blockchain network 100. Many applications may only require rebalancing at a low frequency.

[0124] Updating the private key share distribution while retaining the existing public group address

[0125] Reference is now made to Figure 7 to illustrate another exemplary method 700 for updating the private key share distribution. Method 700 can be carried out by node 102 of blockchain network 100 in cooperation with other nodes of blockchain network 100.

[0126] In Figure 7 method 700, each time the distribution of member deposits changes, the meeting public key does not change. When a request to allocate new key shares is detected (at operation 702, which can occur by depositing digital assets into the public group address), node 102 cooperates with other members of the meeting to (at operation 704) issue new private key shares for the same public key to new members of the group. The number of cooperating nodes is at least the threshold number of nodes required to generate a digital signature under the threshold signature scheme. At operation 704, additional key shares can be allocated while other key shares remain unchanged. This may involve a change in the threshold (of the threshold signature scheme), but in practice the change may be small. Alternatively, at operation 704, additional key shares can be allocated while updating other key shares. Such an update requires proof of deletion of any previous generation key shares. In this case, new shares can be allocated while maintaining the same threshold (in the context of SSS, this involves sharing a new polynomial of a higher order).

[0127] At operation 702, node 102 may identify meeting members using one or more attributes included in at least a portion of a transaction of a digital asset to a common group address (i.e., parties that transfer a digital asset to a meeting public key to join a meeting rather than for other purposes). For example, certain transactions may be marked as special transactions using attributes in the transaction. These attributes (whether present or not) may indicate the purpose of the transfer. For example, a marker may be included in the transaction when the transferor did not request to join the meeting.

[0128] When members leave a meeting using method 700, they may securely delete their private key shares. To ensure that the private key shares of old members are not available, members of the meeting may be required to use node 102 with a special TEE. A TEE is an architecture implemented at the hardware level that guarantees that instructions and data executed therein are protected from access and manipulation from the rest of the system. The TEE may employ hardware mechanisms to respond to remote attestation queries, which can be used to verify the integrity of the system to an external party (e.g., other nodes in the meeting).

[0129] Each member node may use a proven TEE that is configured to generate one or more random secret values that remain inaccessible to the host system without compromising the hardware at the integrated circuit level. Secret values generated in this manner will be used for the distributed generation of private key shares (e.g., in operation 410 of method 400 of Figure 4 . The secret value may also be used to establish a shared public key during the setup phase of the meeting. Computations associated with the setup protocol are performed within the TEE enclave such that no member or former member can derive any information about their own or other private key shares based on member - to - member communication or any other means. The enclave within the TEE enables a remote attestation protocol, which can be used to prove to other nodes that the TEE enclave is trustworthy and that it is running approved computer - readable instructions.

[0130] Computations associated with group changes are performed within the TEE enclave. For example, the generation of a new secure random secret is performed within the TEE enclave, which can be used for computing a new polynomial for SSS purposes.

[0131] In addition, the purpose of the TEE enclave is to ensure the secure deletion of previous key shares and previous secrets that are no longer in use before returning the member deposits. More specifically, in order to return the member deposits, the proof protocol may require the TEE enclave to prove the deletion of the key shares. Through the remote attestation protocol, each node 102 can interpret such a proof as an acknowledgement that the required deletion has occurred on other nodes. Therefore, method 700 may also include confirming that the private key shares previously held within the TEE of the member leaving the meeting have been deleted from the nodes associated with that member. This confirmation can be made by receiving a proof of the deletion of the private key shares. Therefore, the remote attestation protocol can be used to obtain a proof of the deletion of the private key shares previously held in the TEE of the member leaving the meeting.

[0132] Figure 6 Method 600 and Figure 7 Method 700 both provide various benefits. For example, Figure 6 Method 600 does not rely on secure deletion and does not require relying on trusted hardware. However, Figure 6 Method 600 can benefit from such hardware because in some cases, such hardware can make the malicious pooling of key shares less likely.

[0133] Figure 7 Method 700 avoids having to relock digital assets under a new meeting public key every time there is a membership change. For example, an implementation of method 700 that employs a TEE can allow the use of a persistent group address, where group members can join and leave without compromising security. Conveniently, in this way, the overhead of having to change the group address can be avoided while still providing sufficient security. Additionally, in some cases, method 700 can update membership faster compared to Figure 6 Method 600 because under Figure 7 Method 700, there is no need to add a transaction to the blockchain to move all digital assets to a new public key because the digital assets are not moved to a new public key. That is, method 700 can be used to update membership without waiting for several blocks to be generated to confirm the transfer of digital assets to a new public key because the public key does not change. Figure 7

[0134] Logging out of the meeting

[0135] As described above, group members can sometimes request to leave the meeting, and when group members log out of the meeting, the digital assets they deposited in the meeting pool may be returned to them. The following refers to Figure 8 to show an exemplary method 800 for returning deposits in the form of a flowchart. This method can be carried out by node 102 in cooperation with other nodes 102 of the meeting.

[0136] ​At operation 802 of method 800, node 102 receives a withdrawal request from a requester who is a meeting member. The withdrawal request may also be referred to as a cancellation request. The withdrawal request is a request to withdraw a digital asset that was previously deposited by the requester and is currently under the control of the meeting. The request may have been broadcast by the requester to all meeting members.

[0137] In response to receiving the request, node 102 evaluates the request against certain criteria at operation 804. These criteria may be predefined criteria. If the meeting operates according to a meeting protocol in which the meeting public key does not change each time group membership changes, then at operation 804, node 102 may confirm that the requester has deleted the private key share. A remote attestation protocol associated with the TEE may be used to obtain such confirmation.

[0138] If the meeting protocol is a protocol in which the meeting public key is changed when membership changes, then node 102 may not confirm the deletion of the private key share because the private key share is no longer valid. Instead, a new meeting key may be used, and other digital assets under the control of the meeting may be transferred to the new meeting key.

[0139] If node 102 approves the withdrawal request based on the evaluation, then at operation 806, the node helps to withdraw the digital asset. That is, node 102 uses its private key share to cooperate in generating a digital signature and uses the digital signature to transfer the digital asset previously deposited by the requester back to the requester. For example, the digital asset may be sent back to the address from which it was previously received. Operation 806 operates according to a threshold signature scheme such that the withdrawal occurs only when at least a threshold number of meeting members authorize the withdrawal. Operation 806 occurs after a period of time during which the member wishing to cancel is suspended from activity. This waiting period prevents the member from engaging in improper behavior while the protocol for returning their member deposit is being carried out.

[0140] The meeting protocol can be used for many different purposes. The meeting provides a security mechanism for performing various functions. The meeting can operate without trust and provides control over digital asset ownership.

[0141] For example, a meeting protocol can be used to implement a two-way peg between a secure permissionless proof-of-work blockchain and a secure permissionless proof-of-stake blockchain. A two-way peg is a mechanism that allows digital assets to be effectively transferred from one blockchain to another and back. More specifically, digital tokens can be transferred from a main blockchain network (which can be referred to as the main chain) to a separate secondary blockchain network (which can be referred to as a side chain or alternative chain). The main chain is not necessarily a specially configured main chain. In fact, the techniques described below will operate with existing protocols on the main chain. These techniques will operate with any main chain that uses digital signatures to authorize the transfer of digital assets. As described in more detail below, the transfer from the main chain can be achieved by temporarily locking digital assets on the main chain by minting corresponding digital assets on the side chain by mining nodes of the side chain. When there is a mechanism that causes an equal amount of digital assets to be unlocked on the main chain as a result of such an action, the transfer from the side chain to the main chain can also be made by burning digital assets on the side chain.

[0142] System with multiple blockchain networks

[0143] Now refer to Figure 9 , which shows a block diagram of exemplary first and second blockchain networks. The first blockchain network 900 is a proof-of-work blockchain network. The first blockchain network 900 can be of the type referred to above with reference to Figure 1 . The first blockchain network 900 includes a plurality of nodes 102a, 102b that are coupled to each other using suitable communication techniques, which may include wired and wireless communication techniques.

[0144] The nodes 102a, 102b of the first blockchain network 900 maintain a global ledger of all transactions on the first blockchain (which can be referred to as the main chain). At least a portion of the nodes 102a, 102b operate as mining nodes 104 of the first blockchain network 900.

[0145] The second blockchain network 902 is a proof-of-stake blockchain network. The second blockchain network 902 includes a plurality of nodes 102c, 102b that are coupled to each other and maintain a global ledger of the second blockchain network 902. The global ledger of the second blockchain network 902 is independent of and different from the global ledger of the first blockchain network 900. The global ledger of the second blockchain network 902 can be referred to as a side chain.

[0146] The second blockchain network 902 based on proof-of-stake 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, mining nodes 906 deposit collateral of digital assets, and the probability of being selected as a node to mine a block is proportional to the amount of digital assets provided as collateral. A proof-of-stake blockchain system can be used to avoid the computational costs and energy required to mine a proof-of-work blockchain. In addition, compared with a proof-of-work blockchain, a proof-of-stake blockchain can allow for higher frequency and more regular block creation.

[0147] The second blockchain network 902 also includes a plurality of nodes 102b, 102c coupled together using appropriate communication technologies. These nodes 102b, 102c maintain the global ledger of the second blockchain network 902.

[0148] A plurality of nodes 102b act as mining nodes 906 of the second blockchain network 902. Since the second blockchain network 902 is a proof-of-stake blockchain network, the mining nodes 906 deposit digital assets in order to be included as mining nodes. More specifically, the mining nodes 906 for the side chain form a set of collateral verifiers in order to mine on the second blockchain network 902. These mining nodes 906 are also members of the session 110 associated with the first blockchain network 900. That is, the nodes 102b that are part of both the first blockchain network 900 and the second blockchain network 902 act as mining nodes 906 of the second blockchain network 902 and as members of the session 110 established on the first blockchain network 900. These mining nodes 906 join the session 110 and participate in the session 110 according to the above method. Their deposit of digital assets into the session pool is carried out in the main chain. That is, the session members deposit their "stakes" on the proof-of-work first blockchain network 900 to become members of the first blockchain network 900, and also act as mining nodes 906 on the second blockchain network 902 by forming a set of collateral verifiers. The member deposits on the first blockchain network 900 act as collateral for the second blockchain network 902.

[0149] In addition, since the number of private key shares held by a member is based on the amount of the member's margin, and since such deposits are forfeited for malicious behavior, members who have a greater impact on the meeting activities (i.e., members who hold more private key shares) have more losses than members with lower influence. Meeting 110 is an open member group that can be joined by any node when sufficient stake is submitted to the pool associated with Meeting 110. Since the meeting members are mining nodes on the second blockchain network 902, they can create new digital assets on the second blockchain network 902, effectively transferring digital assets from the first blockchain network 900 to the second blockchain network 902. Meeting 110 can be used to provide a two-way anchor between a proof-of-work blockchain and a proof-of-stake blockchain.

[0150] Figure 9 The illustrated nodes 102a, 102b, 102c can be electronic devices 200 of the type described above with reference to Figure 2 the type described.

[0151] Two-way anchor

[0152] Reference is made below to Figure 10 , Figure 10 and a method 1000 for providing a two-way anchor is shown in the form of a flowchart as an example. Method 1000 can be performed by node 102b, which operates in both the first blockchain network 900 (i.e., in a proof-of-work blockchain network) and the second blockchain network 902 (i.e., in a proof-of-stake blockchain network). Computer-readable instructions can be stored in the memory of such a node, and when these instructions are executed by the node's processor, the processor is configured to perform method 1000.

[0153] In operation 1002, node 102b joins the meeting. The meeting can be joined in the manner described above with reference to Figure 4 the manner described. For example, node 102b can transfer one or more digital assets to a public group address associated with the meeting public key. The public group address has one or more other digital assets associated with other members of the meeting (e.g., other nodes 102b). When node 102b joins the meeting, node 102b generates private key shares for a threshold signature scheme, where at least a threshold of the private key shares must be used to generate a valid signature on behalf of the meeting. As described above, the threshold signature scheme can be of various types, including an elliptic curve digital signature algorithm or a threshold scheme based on the Schnorr scheme.

[0154] Other private key share holders are other members of the meeting who join the meeting on a permitted or unpermitted basis by transferring their respective digital assets to the public group address.

[0155] At operation 1004, the node 102b that joins the meeting forms a collateral validator set with the other members of the meeting on a proof-of-stake blockchain network (e.g., on the second blockchain network 902). That is, after depositing digital assets as collateral (the deposit thereof may be referred to as "collateral"), the members of the meeting (formed by deposits on the first blockchain network 900) now act as mining nodes on the second blockchain network 902 to periodically generate new blocks for the second blockchain network 902.

[0156] After the meeting has been formed, the node 102b, which is a member of the meeting, may detect, at operation 1006, the confirmation of a special transaction of digital assets to a group public address on the proof-of-work blockchain network. A transaction is determined to be special if it meets a predetermined criterion that differentiates it from the transaction used to join the meeting. For example, a transaction may be determined to be special if it includes a specific tag, variable, or attribute.

[0157] After detecting the special transaction, the node 102b may wait until at least a threshold number of blocks have been added to the blockchain of the proof-of-work blockchain network. This waiting period can reduce the risk that the blockchain may be reorganized on the proof-of-work blockchain network, and a reorganization of the blockchain on the proof-of-work blockchain network may invalidate the transaction of operation 1006. Thus, although not shown, the method may include an operation of determining that at least a threshold number of blocks have been added to the blockchain of the proof-of-work blockchain network after detecting the special transaction. Figure 10 After at least a threshold number of blocks have been added to the proof-of-work blockchain, the node 102b mints the corresponding digital assets on the proof-of-stake blockchain network (at operation 1008). These digital assets are minted in response to detecting the special transaction and are minted in an amount corresponding to the amount of digital assets in the special transaction detected at operation 1006.

[0158] The minted digital assets are placed in an account associated with the public key owner on the proof-of-stake blockchain network, which caused the special transaction to be detected at 1006. Thus, the transfer of digital assets on the proof-of-work blockchain network to a party of the meeting continues the control of the digital assets on the proof-of-stake blockchain network. This party can now freely use these digital assets in various ways, including, for example, transferring these digital assets to other accounts.

[0159]

[0160] ​The casting is performed by selected council members. More specifically, council members who also act as mining nodes 906 for the proof-of-stake blockchain network are selected to generate blocks through the proof-of-stake blockchain network. The probability of selecting a node is based on the amount of digital assets the node has staked. The probability can be proportional to the amount of digital assets the node has deposited into the council public key.

[0161] After a period of time, the owners of digital assets may wish to transfer them back to the proof-of-work blockchain network (i.e., back to the main chain). To do this, they can issue a request to transfer the digital assets back to the proof-of-work blockchain network. Such a request can be published on the proof-of-stake blockchain network in the form of a special transaction. The transaction may be special because it is a transaction to a special non-spendable address, which is the address to which funds should be sent when the sender wishes to transfer these funds back to the main chain. That is, the transaction can be special because the address is a special address. At operation 1010, node 102b can detect a request to transfer digital assets on the proof-of-stake blockchain network back to the proof-of-work blockchain network. For example, at operation 1010, there may be mining of a transaction that sends funds to the special address.

[0162] To prevent reorgs, node 102b can wait until at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network after the request is detected at operation 1010. Thus, although not shown in Figure 10 the method 1000 may include an operation of determining that at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network after the request is detected.

[0163] In response to detecting such a request and determining that a threshold number of blocks have been added to the proof-of-stake blockchain, node 102b cooperates at operation 1012 to generate a valid signature for the transaction from the public group address using its private key share for the council. For example, among council members, the transaction can be passed directly or via a side chain by including the information required in the transaction on the side chain, and members can add their partial signatures until a valid signature is obtained, at which point the transaction can be broadcast to the mining nodes 104 of the proof-of-work blockchain network. The transaction transfers the digital assets to an address on the proof-of-work blockchain network, which can be the address associated with the node that issued the request detected at operation 1010.

[0164] At operation 1010, the special address to which the digital assets are transferred is a non-spendable address. Thus, the transfer of digital assets at operation 1010 burns the digital assets on the proof-of-stake blockchain to prevent double spending (i.e., the duplication of digital assets on two blockchains).

[0165] To enhance security, at least a portion of the operations that can be transferred can be performed within a trusted execution environment in a node. For example, a determination of adding at least a threshold number of blocks to a blockchain of a proof-of-stake blockchain network can be made within a trusted execution environment on a node. Before using a private key share, a node can also confirm the validity of a request detected in operation 1010 within the trusted execution environment. The generation and use of private key shares can also be performed within the trusted execution environment.

[0166] Ensuring against one-way betting attacks

[0167] To further enhance security, the protocol can include one or more safeguards to prevent one-way betting attacks. An example of a one-way betting attack occurs when a fraudster (i.e., a node associated with a malicious party) constructs a transaction on the main chain that consumes all or a portion of a digital asset under the control of a session (i.e., blocked by a session public key). The fraudster can offer the transaction to other members to add partial signatures. If a threshold number of private key shares associated with the members participate, a valid signature can be generated. If the threshold signature scheme used in the protocol is not an aggregate signature scheme (e.g., if ECDSA is used), it may be difficult to identify the members contributing partial signatures. If a member who may be due for payment if the fraud is successful can add their partial signature to the transaction and pass the transaction without risking exposure as a party to the fraudster. Then the addition of the partial signature can be considered a one-way bet because the worst-case scenario that can occur is not collecting enough partial signatures to obtain a complete signature.

[0168] Accordingly, the protocol can include one or more features for protecting the protocol against one-way betting. For example, the TEE of each node can be configured to periodically prove to all transactions that they have partially signed and / or may require them to broadcast such a proof before demanding the return of their deposits. If a node proves that it has added a partial signature to a transaction that is later determined (by a threshold of session members) to be a fraudulent transaction, then such malicious activity can be detected by other honest member nodes (e.g., in Figure 5 operation 502 of method 500). When such malicious activity is detected, the honest member nodes can cooperate to suspend the member (as described in operation 503 of method 500 above with reference to Figure 5 and / or confiscate the digital assets of the member (as described in operation 504 of method 500 above with reference to Figure 5 ). While this technique can be used to help protect the protocol against one-way betting, it may incur overhead when using periodic proofs. Additionally, fraud may not be detected for a long time in cases where a proof is required before returning deposits.

[0169] The protocol may include additional security measures to prevent one-way betting. For example, an aggregate signature scheme such as the "BGLS" scheme of Boneh, Gentry, Lynn, and Shacham (Aggregate and Verifiably Encrypted Signatures from Bilinear Maps. International Conference on the Theory and Applications of Cryptographic Techniques, EUROCRYPT 2003: Advances in Cryptology - pp 416 - 432) may be used. Aggregate signatures allow different signers to sign different messages while producing only one signature, which can be verified in a "single-shot".

[0170] To use BGLS, the TEE of each member can maintain a single private key share for the threshold signature scheme used on the main chain and the BGLS private key. The public key corresponding to the BGLS private key can be referred to as the share ID ("SID"). The BGLS private key can be a random number generated using a secure random number generator within the TEE. The private key share of the threshold signature scheme is a share calculated within the TEE using a multi-party key generation protocol.

[0171] BGLS can provide protection against one-way betting in the following way. When a node pays into the conference public key for registration purposes (which can occur in operation 404 of method 400 in Figure 4 ), the registration transaction may include: i) the number and hash of the latest block on the main chain that the enclave has seen, and the number and hash of the latest block on the second blockchain (i.e., the side chain), which can be used as a broadcast channel for communication between members; ii) a reference (a hash of the initial contents of the memory within the enclave signed by the proof key of the TEE and bound to the SID).

[0172] Before requesting the TEE to provide the data required for the registration transaction, members must send all the blocks on the main chain and the second blockchain to their TEEs in sequence, starting from the genesis block of each blockchain. The TEE is configured to check the proof of work on the main chain and maintain a record of the current membership, which can be obtained by analyzing registration and deregistration transactions. This allows the TEE to independently (e.g., independently of its owner) establish the current SID. That is, it allows the TEE to establish the SIDs corresponding to all the current members of the conference.

[0173] For registration (e.g., during operation 404 of method 400 in Figure 4 ), a (potential) member sends to the blockchain network acting as the main chain (e.g., to Figure 9The first blockchain network 900 constructs, signs, and broadcasts a registration transaction for a public group address payable to the meeting. The registration transaction references UTXOs sufficient for at least one key share. When the registration transaction is confirmed on the main chain, members of the meeting can cooperate to release new key shares to the TEE of the registered members (e.g., as described in operation 704 of method 700 above). Figure 7 as described in operation 704 of method 700.

[0174] When the meeting wishes to initiate a transaction for a digital asset blocked by the meeting's public key, nodes in the meeting can propose a transaction T(M) on a second blockchain network (i.e., on an alternative chain such as a side chain). At this time, the transaction T(M) is an unsigned transaction whose purpose is to transfer digital assets on the main chain M that are proposed on the side chain A. That is, the second blockchain network (i.e., the side chain) can be used as a broadcast channel. When a member wishes to pass some information to all other members, they can place it in a transaction and send it to the side chain.

[0175] When at least a threshold number of blocks are mined at the top of the second blockchain, the transaction T(M) is considered to be approved on that second blockchain network (side chain). When the TEE observes that the transaction is approved (i.e., proposed and confirmed) on the second blockchain network (i.e., on an alternative chain such as a side chain), they broadcast a pre-commit. The pre-commit consists of the BGLS signature T(M) on the transaction and the SID corresponding to the BGLS signature. The pre-commit is sent to the second blockchain network, thereby sharing it with other meeting members. That is, the pre-commit can be encapsulated in a transaction on the second blockchain network.

[0176] Once a node observes a threshold of pre-commits, and more specifically, the TEE into which blocks from both the main chain and the second blockchain network are input, the node outputs a commit (partial signature) on the transaction T(M) that has been pre-committed. For example, the threshold can be set to a simple majority of all current SIDs. The commit included in the transaction is sent on the second blockchain network that includes the partial signature on T(M), which references T(M).

[0177] When at least a threshold number of commits are observed in the second blockchain network to construct a complete signature, the signed transaction T(M) is constructed and broadcast to the first blockchain network (e.g., to the main chain).

[0178] Using pre-commits can provide additional security because the properties of the aggregate signature scheme mean that members cannot contribute a pre-commit without revealing their identity. That is, their identity is revealed in the form of the SID, which is associated with the member's deposit during the registration process.

[0179] In addition to the above measures, the TEE associated with the node can be further configured such that the transaction is submitted or pre-submitted only if the transaction has been approved on the second blockchain network. For example, all blocks can be constructed within the TEE, and the TEE is configured such that the blocks always contain a pre-submission or submission to approve the transactions that require them (corresponding to the SID of the TEE that constructs them). Thus, members cannot avoid sending a submission or pre-submission to an approved transaction and continue mining on the side chain.

[0180] A node that observes a pre-submission of an unapproved transaction on the second blockchain network can report such malicious behavior to other members of the set of guarantee verifiers. As described above, malicious members (identified by their SID) can be penalized by suspending and / or forfeiting the member's deposit. For example, in response to observing a pre-submission of an unapproved transaction, the membership can cooperate to immediately suspend the SID such that no further pre-submissions are accepted, and the faulty member is suspended such that it does not participate in the protocol. Additionally, once a transaction containing evidence of the accusation is confirmed in the second blockchain network, the deposits of the faulty members can be forfeited and burned. Honest members can cooperate to reward the node that reports the malicious behavior (e.g., by transferring at least a portion of the forfeited digital asset(s) to the node that reports the malicious behavior). Thus, applying an aggregate signature scheme in the pre-submission phase can enhance the security of the protocol, e.g., by preventing one-way betting attacks.

[0181] To prevent members from attempting to deceive the TEE into determining that the difficulty of the proof-of-work in the current main chain is less than its current difficulty, the TEE can be configured to take action when a sharp drop in difficulty is observed. More specifically, if a block is submitted to the TEE upon arrival, the difficulty can be established based on the time interval between blocks. Any decrease in difficulty is expected to be gradual, and a member attempting to deceive the TEE by not providing a block upon arrival may cause a sharp drop (which can be determined to be "sharply" based on a predetermined criterion) such that it appears as if the difficulty has decreased, and thus it is easier to forge blocks for the proof-of-work main chain. To provide further security, the TEE can be configured to respond to a sharp drop in the difficulty observed on the main chain by outputting a pre-submission to the new difficulty to be mined into the second blockchain network (along with the hash of the block and the block number). The hash of the block is included to allow verification that the block corresponds to the new difficulty and the block number is included to allow other members to quickly compare the stated difficulty / block hash with the block at the same height on their copy of the blockchain.

[0182] It only recalibrates the main chain difficulty and accepts any new members registered on the main chain when blocks of a second blockchain containing a pre-submitted threshold are provided to it at the same difficulty (corresponding to other members who had their deposits in place before the sharp drop in difficulty), as a sharp drop in difficulty has been observed.

[0183] If an aggregation signature scheme such as BGLS is used, the procedure for returning a member's deposit may include additional requirements. For example, it may be required that the node requesting the return of the deposit prove the deletion (through its TEE) of both the private key share and the BGLS private key. If the withdrawing member has proven the deletion of both the private key share and the BGLS private key, then other member nodes may be configured to include only their pre-commits or partial signatures in the transaction returning the member's deposit to that withdrawing member.

[0184] The node for the withdrawing member may also need to prove through its TEE all the transactions it has pre-committed or committed. If the withdrawing member has not pre-committed any transactions determined to have been approved, then other member nodes may be configured to include only their pre-commits or partial signatures in the transaction returning the member's deposit to that withdrawing member.

[0185] Due to the above procedures, it is extremely unlikely that malicious members will benefit from withholding blocks from the TEE. Other than the TEE corresponding to the confirmed SID, the only pre-commits that the TEE will consider valid are those corresponding to BGS private keys that no longer exist (and the only way this could happen is if members did not provide the TEE with the latest blocks, and in fact, when they left the session, deleted their key shares and requested the return of their member deposits, the TEE registered some members as current members). Additionally, as a result of the above, members cannot induce their TEEs to provide pre-commits for fraudulent (i.e., unapproved) transactions and then be authorized by the session to return their deposits. Therefore, members are incentivized to ensure that the TEE has an up-to-date copy of the blockchain (i.e., the main chain and alternative chains).

[0186] Thus, the protocol can be protected by configuring nodes to operate according to one or more protocols including the following features: i) configuring the TEE to require a threshold of pre-commit observed on a second blockchain network (e.g., a proof-of-work sidechain) before it outputs a partial signature on a pre-committed transaction; ii) returning the member deposit only if the TEE for that member a) proves the deletion of the private key share and the BGLS private key and b) all the transactions it has pre-committed, and none of these have been judged to be not yet approved (by consensus on the second blockchain network); iii) any block built within the TEE will always include the (pre-)commit for approved transactions that require them (i.e., those approved / pre-committed transactions that have not yet collected the (pre-)commit threshold); iv) the TEE can be configured to respond to a sharp drop in the difficulty observed on the main chain by outputting the pre-commit to a new difficulty to be mined into the second blockchain network (along with the hash of the block). It re-calibrates the main chain difficulty and accepts any new members registered on the main chain only when provided with a block of the second blockchain containing the pre-commit threshold at the same difficulty (corresponding to other members who had their deposits in place before the sharp drop in difficulty) as it observed the sharp drop in difficulty.

[0187] The protocol supporting the second blockchain network described herein can be layered on top of an existing permissionless proof-of-work public blockchain protocol as it interacts by constructing digital signatures via a multi-party protocol external to the main chain, meaning it can operate without the consent of the main chain mining nodes or developers. Thus, the protocol can be implemented via an existing public proof-of-work blockchain and does not depend on modifications to the protocol of that public proof-of-work blockchain. In this sense, the protocol can be added to the blockchain without permission (as the blockchain protocol itself does not need to be modified to accommodate further protocols).

[0188] The methods described above are generally described as being executed at nodes, but the features of the methods rely on cooperation with other nodes and can be carried out elsewhere.

[0189] While the above description generally describes implementing a session on a proof-of-work blockchain network, alternatively, a session can be implemented on a proof-of-stake blockchain network.

[0190] In addition to certain benefits and features already mentioned, the techniques described herein can provide additional benefits. For example, two-way anchoring can allow for the addition of Turing-complete smart contract functionality to a binary blockchain system consisting of an existing proof-of-work blockchain and a proof-of-stake sidechain. In a specific example, although some existing scripting languages are not Turing-complete, one or more of the techniques described herein can provide a Turing-complete script. In another specific example, the proof-of-stake sidechain can be endowed with a Turing-complete scripting language to implement such functionality. Additionally, at least some of the techniques described herein can provide a proof-of-stake blockchain that is not subject to the nothing-at-stake problem of previous proposed implementations of proof-of-stake blockchains; and can provide the advantages of faster and more regular block creation associated with traditional proof-of-stake schemes. Further, at least some of the techniques described herein provide an incentive for mining nodes of the proof-of-stake main chain to hold a large amount of digital assets, which increases the security of the proof-of-work main chain.

[0191] It should be noted that the above embodiments are illustrative and not restrictive of the invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention. In the claims, any reference signs in parentheses shall not be construed as limiting the claims. The word "comprising" etc. does not exclude the presence of elements or steps other than those listed as a whole in any claim or specification. In this specification, "comprising" means "including" or "consisting of". The singular reference to an element does not exclude the plural reference to such elements, and vice versa. The invention can be implemented by means of hardware including several different elements, and by means of a suitably programmed computer. In a device claim enumerating several devices, several of these devices can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A computer-implemented method for seizing digital assets, the method being implemented by processing resources, the method comprises: i) detecting malicious activities of a malicious party, where the malicious party is one of the other members of a meeting; and ii) seizing at least a portion of the digital assets previously transferred by the malicious party to a public group address.

2. The method according to claim 1, wherein, seizing at least a portion of the digital assets comprises: transferring to an unspendable address.

3. The method according to claim 2, wherein, transferring to an unspendable address comprises: cooperating with other members of the meeting to use a private key share to generate a valid signature for a transaction to the unspendable address.

4. The method according to claim 1, wherein, malicious activities are detected when it is determined that a node associated with the malicious party violates a predetermined protocol or criterion.

5. The method according to claim 4, wherein, malicious activities are detected at a node that reports error information to other members of the meeting.

6. The method according to claim 1, wherein, seizing a portion of the digital assets comprises transferring to an unspendable address.

7. The method according to claim 1, wherein, seizing comprises: cooperating with other members of the meeting to use a private key share to generate a valid signature for a transaction to a spendable address.

8. The method according to claim 1, wherein, verifiable secret sharing is used for malicious behavior.

9. The method according to claim 8, wherein, malicious behavior is detected by determining that a node provides inconsistent key shares.

10. The method according to claim 1, wherein the method further comprises: i) detecting a reallocation request; ii) cooperating with other meeting members to transfer all digital assets in the public group address to a new public address associated with a new public key; and iii) generating new private key shares.

11. A computer-readable storage medium comprising computer-executable instructions that, when executed, configure a processor to perform the method according to claim 1.

12. An electronic device, comprising: an interface device; 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 the method according to claim 1.

13. The electronic device according to claim 12, wherein, the processor includes a trusted execution environment, and wherein the computer-executable instructions are executed within the trusted execution environment.

Images