如何防止离线节点线下作恶控制钱包中的资产?

[readygo586]

在 http://www.xiaomaojia.com/zixun/12407.html中提到" Swingby Skybridge 采用动态重组机制，当节点退出、离线或者发送恶意数据时，会被候选节点取代；当节点大规模离线时，原有的 TSS 组可以将跨链资产的所有权转移到另外一个新的 TSS 组，在旧节点仍然拥有秘密份额的同时，新节点也会接管对托管钱包的控制权。"

假设n=7, t=4，开始是的时候node1～7(TSS1)参与BTC 地址 A的生成过程，然后node1～node4 决定退出，此时会替补node8~11进来形成新的TSS组(TSS2). 此时TSS2 控制了BTC 地址 A 的私钥。

如果node1～node4线下协商盗取BTC 地址A的资产， 这种情况如何处理？

[roy1210]

你好！ 这不是一个问题，因为我们所使用的网络比这个n=7t=4的例子要大得多。并且大量生产的节点数量变得 >= quorum-1 时，密钥会重新生成。 swips即将把这种情况纳入考量。

[readygo586]

你说的是BTC 的私钥重新分片吗？如果是，那么旧的TSS 节点如果要做恶，把他们旧的私钥通过MCP 计算也可以得到完整的私钥， 这个问题你们怎么防？

[readygo586]

比如旧的TSS 节点直接把硬盘中的数据copy， 然后私下组网，再模拟用户发转账交易，这个时候，他们MCP 就可以得正确的签名。

[roy1210]

网路会生成全新的密钥（也因此会生成新的地址）。 旧节点是不可能收集足够数量的‘shares'去用旧的key shares来进入funds。

It’s not splitting(重新分片). An entirely new key (therefore a new address) is generated. It’s impossible for old nodes to gather the number of ‘shares’ required to access funds using old key shares.

[readygo586]

设想一下，如果我能够贿赂所有的旧节点，让他们把含有db 的硬盘给我， 也不可以恢复出就的私钥吗？

[creamwhip]

It would be easier to explain in English. The short answer is no, old shares would not be usable.

consider this scenario with n=25, t=15:

1. 4 nodes churn out. 4 nodes keep 4 old shares. 4 < t.
2. 5 more nodes churn out. 4 + 5 nodes keep old shares. 4 + 5 < t.
3. 5 more nodes churn out. 4 + 5 + 5 nodes keep old shares. 4 + 5 + 5 < t.
4. 2 more nodes churn out. t < 4 + 5 + 5 + 2. nodes move to a new address. funds are moved.

in reality, the threshold for triggering a full churn would not equal t. it would perhaps be set to something like t*0.66 and occur regularly every interval T which could be dynamically adjusted based on churn rate.

even if t old shares can be recovered through 'bribery', the funds would have moved away from the old address. the balance would be 0.

current 'churned in' nodes are disincentivized to reveal their current key shares:

• a hack or a breach of the active network would have a negative affect on bonded token value.
• the node owners are generating revenue (cash flow) by keeping the network running.

[readygo586]

@creamwhip Thanks for your clear explain. Though such method can avoid asset loss by address migration, which mens user has to be caution about whether his address change or not when he try to deposit. it is not friendly enough.

Maybe we should find another way to improve it

[creamwhip]

I get your point, but the address migration is not even necessary. It's a redundant extra layer of security that may be an optional configuration setting.

Here's why: Re-sharing generates a new polynomial for distributing private key x, and the nodes update the indexes k_i of each node for a re-share. This means that old shares that were produced during older churn cycles cannot be combined into later ones.

Using the previous example:

1. 4 nodes churn out. 4 nodes keep 4 old shares. 4 < t. Churn cycle #1: 4 old shares.
2. 5 more nodes churn out. 4 + 5 nodes keep old shares. 4 + 5 < t. Churn cycle #2: 5 old shares.
3. 5 more nodes churn out. 4 + 5 + 5 nodes keep old shares. 4 + 5 + 5 < t. Churn cycle #3: 5 old shares.

These 'churned out' nodes could not combine 5 + 5 + 4 shares to produce 14 'shares'. It would only really be a problem if t nodes were 'churned out' in a single churn cycle, leaving a threshold t of old shares that could be interpolated on a single polynomial.

I hope this makes sense.

[readygo586]

@creamwhip Yes, this is my point.

Another question, at the first create private key, should all N nodes necessary attended? in t=4/n=7 case, if only 6 nodes online when user request to create a new private key, is ok to create the private key first by 6 nodes, then re-share to 7 nodes when the absent appear again?

[creamwhip]

Yes, that is how the network gets bootstrapped.