tECDSA subnet id and takeover threshold

I would like to know for sure which subnet is running the tECDSA functionality, and which subnet is storing the backup of the private key. If those who know could post the subnet ids that would be great.

I would also like to know for sure the exact number of colluding node operators or hacked node operators it would take to effectively gain control of the master key and steal all BTC/ckBTC or any other asset stored with any derived key from the master key.

My understanding is that it would take 1/3 (or maybe 1/3 + 1) to pull of this kind of attack. Exact clarification is appreciated.

So for the different subnet replication levels currently in existence, my best guesses are:

40 nodes - 14 for takeover
34 nodes - 12 for takeover
28 nodes - 10 for takeover (currently the main tECDSA subnet)
13 nodes - 5 for takeover

2 Likes

I found this information.

The NNS will act as a key backup subnet.

Yes that was the plan. I’d like to know for sure if the NNs subnet is being used to backup the master key.

If we could have someone from DFINITY post the subnet ids of the tECDSA subnet and backup subnet that would be great. The forum, documentation, and GitHub repo aren’t clearly showing this information to me. I spent the last 1-2 hours searching for this information in those various places, but giving up for now.

2 Likes

Just got confirmation that it’s the fiduciary subnet with 28 nodes: Subnet: pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae - IC Dashboard

Subnet id: pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae

2 Likes

Hi! The ECDSA key was generated on subnet uzr34. This subnet, which is also the II subnet, is the one that is used as a backup. The key was later reshared to subnet pzp6e when this was created. This subnet is the one that can issue ECDSA signatures.

4 Likes