Threshold ECDSA Signatures

I think it’s Keccak for Ethereum.

1TPS? We may therefore need more fees to resist similar DOS attacks?Can the same signature be replicated to multiple subnets? Could we be temporarily frozen funds in the signature by a DOS attack?

1 Like

1TPS? We may therefore need more fees to resist similar DOS attacks?

Yes, the fees will be set to make sure that a subnet burns more ICP than is minted for node providers if all it does is create ECDSA signatures as fast as it can.

Can the same signature be replicated to multiple subnets?

Yes, this 1 signature per second estimate is for one subnet. It can scale out such that many subnets can create ecdsa signatures.

1 Like

I think ic/lib.rs at b8b2eca5bc092b1bba072b1fb6c019489f9b7fb3 · dfinity/ic · GitHub does what you are looking for, does that answer your question?

1 Like

Note also that extended BIP32 is compatible with the standard (non-hardened) BIP32 derivation: chain codes and public keys are used in the same way. So if you stick to non-hardened BIP32 derivation paths you should be able to use existing libraries. The only difference with extended BIP32 is that it allows to use longer strings inside the derivation path.

Upon further reflection over the last little while, I’m becoming increasingly concerned about the node operator collusion attack vector. tECDSA has worse BFT properties than ICC, only 1/3 of node operators (secret key share holders) are necessary to collude to create a threshold signature. The current tECDSA subnet has 34 STATIC node operators, meaning that 12 are necessary to collude to sign anything they want.

Is this acceptable security? Is the tECDSA subnet composed of truly independent node operators? Are there 12 independent entities that need to collude, or fewer?

The fact that the subnets are static seems to greatly increase the probability of successful collusion. ICC is based on a static adversary (I’m not sure how related ICC is to tECDSA). Why was this assumption made? This seems woefully inadequate when applying a BFT protocol to the real world.

The decentralization properties (and thus the security properties) of subnets are so very concerning right now. I don’t even feel comfortable calling the IC decentralized at this point, I prefer the term progressively decentralizing. But when are we going to address the static node operator collusion attack vector? It may be of the absolute utmost importance compared with everything else when you consider the consequences.

11 Likes

Another quick point maybe to summarize. tECDSA and the Bitcoin Integration are touted as decentralized and non-custodial solutions. Well actually, we depend in the worst case on only 12 known static entities to custody the key shares and use them appropriately. This seems rather custodial to me. Definitely better than 1 party, but seems pretty similar to other bridging solutions that have a small set of validators tasked with security and bridging.

The obvious solution in my mind is truly weaving the node operators and canisters into one giant logical computer, by making subnet node and maybe even canister membership ephemeral and random. At any time node operators could shuffle and perhaps even canisters, so that subnet membership is not static.

The static threat really scares me.

8 Likes

As someone going on the road and trying to defend and promote this feature at various places like ETHMexico, Science of Blockchain, and the coming DevCon in Bogata…it would be really helpful to have subnet shuffling on the road map in the highest priority slot(along with boundary node decentralization).

We have the feature set that is years ahead of the market if we can follow through with the decentralization part.

8 Likes

Holy moly. Invoke a proposal, if we need subnet shuffling & boundary node decentralisation we need it fast. The IC cannot afford a security blunder, especially with other peoples BTC

1 Like

Another problem though is that we don’t have that many independent node operators. To achieve sufficient levels of decentralization through shuffling, I would think we need many more node operators first.

4 Likes

I share many of your concerns; but, all node provider identities are public knowledge and I wonder if this offers some protection. I don’t think it would be too difficult to identify the guilty parties and initiate some legal action against them. In fact, it seems like a pretty significant deterrence.

That being said; I definitely support the message that we need to prioritize the on-boarding of independent node providers.

3 Likes

Unique node ownership is probably even more important in the short term. The NNS should prioritize unique independent providers for the next batch of nodes coming to the internet computer. It doesn’t matter if you will take the nodes if company LLC is still running them.

1 Like

I wonder how can the NNS make sure the providers are indipendent though. Dfinity probably knew the genesis providers and had a legal team review their request.

KYC them and have them sign a contract if necessary. sorry

2 Likes

I feel like IC should just do whatever Chainlink does since everyone trusts their providers.

1 Like

I would also like to know more why low tECDSA was deemed secure enough and the security features of ICs implementation.

In the tECDSA CC, Victor Shoup talks about proactive security of the threshold shares being reshared/refreshed frequently, is that currently part of the protocol?

He also states that high threshold security isn’t necessary for ICs protocol and low threshold ECDSA is good enough. I’d like to know more and why that is the case.

3 Likes

I asked about this on Twitter and @Manu replied saying that they are only reshared when subnet membership changes. https://twitter.com/manudrijvers/status/1563152150816911362?s=21&t=pGOnr4aqkIFS-QIDw8rKjA

1 Like

Node shuffling reduces one attack vector but opens another. I would look at it very carefully before jumping to it. With node shuffling new (malicious) node providers could sign up with the sole intention of hoping that they get shuffled on the Bitcoin subnet someday. If you shuffle often enough they might succeed.

Can you elaborate on the particular scenario that you are worried about? How would the breach unfold? I mean who and at what time decides to collude or gets compromised? I am trying to understand if node shuffling would really help.

To provide some numbers for comparison:

  • Three Bitcoin mining pools together have >50% and can perform a large-scale double-spend (not steal)
  • Bitcoin’s Liquid sidechain requires 11 signers from a static set of known entities. The threshold is better, it is 11 out of 15, but the absolute number isn’t.
9 Likes

We already had an extensive conversation on node shuffling: Shuffling node memberships of subnets: an exploratory conversation

2 Likes

One question that would be interesting to explore is to figure out how much the tecdsa signers know what address they are signing for. For them to conspire to target a specific address they would need to know they are one of the signers of that address. Is that info they know?

I think the concern is that if there is a t-ecdsa account with $200m of btc sitting in it then it becomes awfully attractive to node providers to attempt to sign to spend it. There isn’t much evidence of what happened either…it just looks like a btc transaction. Knowing what it would look like on the IC and what would be necessary to pull it off might help everyone understand the actual risk.

5 Likes