search

urbit / urbit-key-generation

Key derivation and HD wallet generation functions for Urbit
MIT License
15 stars 8 forks source link

Shard #10

Closed g-a-v-i-n closed 5 years ago

g-a-v-i-n commented 5 years ago
g-a-v-i-n commented 5 years ago

@c-johnson @jtobin I'm not 100% sure if we want to use an npm module for sharding because I'm biased towards not using 3rd party modules. I'm not sure if its a big deal in this case.

c-johnson commented 5 years ago

Looks fine to me. If the shard algorithm is simple / self-contained enough you could just copy it in plaintext. If not, we're already using dependencies (which will still get audited?), so it seems fine.

As a sidenote, we should probably remove the ^ from version numbers in package.json and require explicit minor versions before release.

galenwp commented 5 years ago

The only thing that comes to mind for me with the 2/3 vs k/n discussion is that there are other processes / documentation that were designed around the 2/3 approach. I expect @msutherl can weigh in on the complexity of changing this, but worth noting.

cgyarvin commented 5 years ago

Great thing about 2/3 is: split 384 bit key into 3 parts, each shard is 2/3, yr done, no math. That said, I’m really not at all afraid of SSS either. It’s the producer’s call.

Sent from my iPhone

On Sep 19, 2018, at 8:28 AM, Galen Wolfe-Pauly notifications@github.com wrote:

The only thing that comes to mind for me with the 2/3 vs k/n discussion is that there are other processes / documentation that were designed around the 2/3 approach. I expect @msutherl can weigh in on the complexity of changing this, but worth noting.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

g-a-v-i-n commented 5 years ago

Who is the person responsible for making this decision?

jtobin commented 5 years ago

(Check out #11 for a simple 2-3 alternative to this one.)

iamwillkim commented 5 years ago

We don’t need k/n sharding for the ceremony. Short of wanting to include k/n sharding in Bridge (which to my knowledge it is not), we don’t need to have k/n.

On Sep 20, 2018, at 1:35 AM, Jared Tobin notifications@github.com wrote:

(Check out #11 for a simple 2-3 alternative to this one.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

g-a-v-i-n commented 5 years ago

Merged #11, need to address the fact owner.seed isn't the entropy ticket.

jtobin commented 5 years ago

Closing this as it went in with #18.