Support k-of-n SSS

[roconnor-blockstream]

We can create tables similar to the recovery table that can be used to generate shares for k-of-n schemes. They require more work by hand, but should be doable for dedicated people.

[apoelstra]

After thinking a bit about this, I think the changes for k-of-n would be as follows:

Generation:

1. Aside from the initial share S, you need to generate k-1 additional shares by hand. (Currently this is just 1, the A share.)
2. Pairing the above shares (including S), for every two of them you need to look up a value in a set of ~30 volvelles/tables. If there is an odd one out, it also contributes, but you can use a single volvelle/table for every share.
3. You need to add together all the results of the above step. (Currently, you just need to look up A/S characters in a single set of volvelles/tables so this step is not applicable)

From a user perspective it's not that much work, but for the postscript file it could result in a significant amount of additional pages: currently for 2-of-N you need 30 tables/volvelles (the current draft has all the tables but only two volvelles). If my counting is right, for 3-of-N you'd need 29+1 = 30 again, for 4-of-N you'd need 28+27 = 55, for 5-of-N 27+26+1=54, 6-of-N 75, etc etc... and none of these volvelles are reusable across the different k values since they are all computing evaluations of lagrange basis polynomials.

On the other hand, the maximum number (again, assuming my arithmetic is right..) is for 12-of-N, at which point we'd need 105 volvelles or tables. So while it'd be unreasonable to provide tables for every single k in one document, if we let the user set k in the PostScript preamble and then generated based on that, the worst-case result wouldn't be too bad.

Recovery:

1. Look up the recovery symbols (there will be k of them) in a giant 31-choose-k-entry table, corresponding to the set of shares you have
2. Translate the shares using the recovery wheel
3. Add up the results of step (2).

So aside from the size of the recovery table, the recovery process is actually pretty-much unchanged for k-of-n. On the other hand, 31 choose 15 (or 16) is 300,540,195, so the current "recovery table" model will not scale and we will probably need to come up with a volvele-assisted way for the user to look up his own recovery symbols.

[apoelstra]

We could also limit n by default to something less than 31, which would greatly reduce the amount of generated material.

[apoelstra]

This can be closed.