You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trezor finally has developed SSS support (though it lacks some of the expansion and strong verification features we have -- their design where they use interpolation as part of their polynomial generation also looks a little strange). They've also implemented an interesting mode called "super shamir" where after creating key shards for your bitcoin key, you then further split the shards into sub-shards.
I suspect this was done in order to work around their 16-share limitation by making reconstruction more performant. But the interesting aspect of this feature is it allows you to create segregated groups of shard holders that may completely betray you and still would not gain any information.
However I'm not entirely convinced that this is solving a real threat model -- if you can confidently segregate N people into A group of size B, where you will never have inter-group betrayals above the threshold you could create the same amount of shares but use a B*2 or higher threshold (the bound is probably lower depending on the thresholds of each group but this is the worst case).
The text was updated successfully, but these errors were encountered:
Were it 6 of 15, one betraying executor could collude with heir to inherit early or 5 betraying executors could steal one share from you or your heir to recover. This requires stealing 3. Raising threshold to 8 of 15 would be easier to lose; any of the 3 groups could then only lose 2 shares Total and recover rather than lose 2 Each and recover.
Aside from some minor quibbles about how we would store the structure (and whether/how we would want to hide the structure of the sharing setup), my main concern is the UX for doing this. At the moment all shares are identical and we can use the same format (both in terms of line format and the PDF version) for all of them.
But if we have to do a recovery of multiple layers of shares then each share would need to provide printed information about how it fits into the share structure (in a way that a non-technical user could understand). I'm not sure if there is a nice way of doing that... You don't want to end up in a situation where you have 12 people coming together but it turns out that they don't have enough shares, and there was no way for them to figure that out beforehand.
Trezor finally has developed SSS support (though it lacks some of the expansion and strong verification features we have -- their design where they use interpolation as part of their polynomial generation also looks a little strange). They've also implemented an interesting mode called "super shamir" where after creating key shards for your bitcoin key, you then further split the shards into sub-shards.
I suspect this was done in order to work around their 16-share limitation by making reconstruction more performant. But the interesting aspect of this feature is it allows you to create segregated groups of shard holders that may completely betray you and still would not gain any information.
However I'm not entirely convinced that this is solving a real threat model -- if you can confidently segregate
N
people intoA
group of sizeB
, where you will never have inter-group betrayals above the threshold you could create the same amount of shares but use aB*2
or higher threshold (the bound is probably lower depending on the thresholds of each group but this is the worst case).The text was updated successfully, but these errors were encountered: