Closed g-a-v-i-n closed 5 years ago
I'm realizing that, to reconstruct the original ticket from shards, keygen-js needs to know the numbers/order of the shards. Good thing the paper wallets already mention this in huge font! (:
Yeah it's more annoying to mechanically reassemble the shards here than under the XOR scheme. Another win for XOR! 😄
Do we need to be able to mechanically reassemble shards anytime soon? One of the advantages of trivial splitting is that it's easy for a human to reassemble shards just from eyeballing them (if you know what you're looking at -- 2/3 of the raw key for each shard).
Just wondering if I should do this now, or if it can wait.
A note: I hadn't realised it would actually be impossible to recombine shards without knowing the precise ones you're using (I intuited that one could mechanically do it via some annoying series of conditionals), but yeah, it is. Trivially, for ~nidsut-dozzod-tomdun
, you can get these shards:
~nidsut-dozzod ('shard 1')
~nidsut-tomdun ('shard 3')
and it's ambiguous as to how they should be combined, unless you know which shards you're working with (you could do ~nidsut-dozzod-tomdun
or ~nidsut-tomdun-dozzod
).
The XOR sharding was nice in that you could just combine two or even three of them willy-nilly without having to know which exact ones you were dealing with.
You could also mechanically try both the possibilities ;) I think there can only ever be the two you mentioned, possibly in mirror "tail matches" form?
On Thursday, 8 November 2018, Jared Tobin notifications@github.com wrote:
A note: I hadn't realised it would actually be impossible to recombine shards without knowing the precise ones you're using (I intuited that one could mechanically do it via some annoying series of conditionals), but yeah, it is. Trivially, for ~nidsut-dozzod-tomdun, you can get these shards:
~nidsut-dozzod ('shard 1') ~nidsut-tomdun ('shard 3')
and it's ambiguous as to how they should be combined, unless you know which shards you're working with (you could do ~nidsut-dozzod-tomdun or ~nidsut-tomdun-dozzod).
The XOR sharding was nice in that you could just combine two or even three of them willy-nilly without having to know which exact ones you were dealing with.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/urbit/keygen-js/issues/46#issuecomment-437115332, or mute the thread https://github.com/notifications/unsubscribe-auth/ABxXhnVABae4UZKykwfS-pDyiHDMBc_Tks5utH5pgaJpZM4YTJj0 .
@ohAitch Yeah there are four ambiguous cases: the above two, plus the same with s/1/2
(so, any case in which you use shard 3). But the problem with just trying them (other than that it is unsatisfying 😄) is that all will derive valid wallets.
TBH the known-order requirement here, and the double-secret-length property of the XOR-based shards, have re-piqued my curiosity about Shamir's secret sharing. That's probably the only algo that has optimum UX, if not trivial implementation.
Ooh that's got to be fixed...
On Thu, Nov 8, 2018 at 10:56 AM Jared Tobin notifications@github.com wrote:
A note: I hadn't realised it would actually be impossible to recombine shards without knowing the precise ones you're using (I intuited that one could mechanically do it via some annoying series of conditionals), but yeah, it is. Trivially, for ~nidsut-dozzod-tomdun, you can get these shards:
~nidsut-dozzod ('shard 1') ~nidsut-tomdun ('shard 3')
and it's ambiguous as to how they should be combined, unless you know which shards you're working with (you could do ~nidsut-dozzod-tomdun or ~nidsut-tomdun-dozzod).
The XOR sharding was nice in that you could just combine two or even three of them willy-nilly without having to know which exact ones you were dealing with.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/urbit/keygen-js/issues/46#issuecomment-437115332, or mute the thread https://github.com/notifications/unsubscribe-auth/AALyAV6hsucRE3CkATVSLqNhJN4ly1P-ks5utH5ogaJpZM4YTJj0 .
Hey, hey, address collection and wallet generator are going live in a matter of hours I'm pretty sure. It seems ill-advised to try and push for such a change right now.
We can totally fix this UI-side. Inputting sequence numbers for the shards isn't pretty, but still very workable. If anything, trying with two shards only takes two tries max if you don't know the order, and Bridge can probably make a good guess for you by deriving ownership and checking if it actually owns anything.
Agreed w Mark On Thu, Nov 8, 2018 at 4:35 PM Fang notifications@github.com wrote:
Hey, hey, address collection and wallet generator are going live in a matter of hours I'm pretty sure. It seems ill-advised to try and push for such a change right now.
We can totally fix this UI-side. Inputting sequence numbers for the shards isn't pretty, but still very workable. If anything, trying with two shards only takes two tries max if you don't know the order, and Bridge can probably make a good guess for you by deriving ownership and checking if it actually owns anything.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/urbit/keygen-js/issues/46#issuecomment-437207680, or mute the thread https://github.com/notifications/unsubscribe-auth/AFBWfV1stYJs4-K4naKvfDWFMZ0qN-Y-ks5utM3OgaJpZM4YTJj0 .
Yeah :+1: on not changing anything right now -- what's there at the moment is perfectly serviceable. We can move to Shamir or whatever in a future version.
Shards can't actually 'just be catted together'.
if I have
~ridlur-figbud
and~marbus-nimbus
as shards and I want to concat, I have to replace the '~' in the 2nd shard with a '-'. keygen-js should expose this function.