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
Why can’t a sub-account request to sign transactions associated with its BTC, so that when the private key is reconstructed, it can only sign transactions for the account that triggered it?
The t-ECDSA signers know the canister principal id of the canister that requests the signature and the derivation path. Both those together determine the ECDSA key they are signing for.
1 Like
The way you phrased I think could bring it home for most. That would be alien tech, true decentralization, yet act as one computer.
2 Likes
Do any of the problems stated mean that we are not going to have BTC integration released on mainnet this year?
Two more months. Just two more months.
Dear community!
Since our most recent update, we have been spending substantial effort on improving the performance of the threshold ECDSA protocol: We could reach a throughput of around 0.5 signatures per second on a reasonably large subnet. The main focus of the team will soon shift towards security-related aspects such as addressing findings of a recent internal security review we have performed.
11 Likes
Is there still room for improvement with future optimizations? What do you consider as “reasonably large”?
2 Likes
Can multiple tECDSA subnets be ran in parallel to increase the overall throughput? How would the IC load balance that?
1 Like
They can, I’m worried about tokenomics implications tho. A tECDSA subnet has to be as secure as possible, so high node count is a must, that means to for the IC to be deflationary the cycle cost per tx has to be at least expensive enough so that a subnet with 24/7 usage burns more cycles than it mints. But estimating real world usage is not easy and 100% utilization might be a pipedream, so cycle cost has to be higher which could make it less appealing to devs.