Yes, this is a real project, and one of us (Pearlwort) is storing a nontrivial amount of Bitcoin with it. However, because of the lack of hardware wallet support, we don't yet recommend anybody else do this.
As far as security, this scheme uses the simple mathematics of Shamir's Secret Sharing Scheme. It avoids complications related to random number generation by asking users to use dice, and avoids complications related to implementation details by basically having users do the math by hand, using simple lookup tables (in the form of volvelles) to assist.
Mathematically inclined readers can read the mathematical companion for more information.
This scheme is essentially the same as SLIP39, with the following differences:
BIP39 is a trainwreck of a protocol with the following issues, shared with neither codex32 nor SLIP39:
I do not mean to disparage the authors of BIP39, who are intelligent, well-meaning, and have all made great contributions to the space. But BIP39 was designed in 2013 when the Bitcoin ecosystem as a whole was lacking the institutional knowledge that we take for granted today, and you can tell.
Unfortunately BIP39 is by far the most widely-supported mechanism for producing BIP32 seeds today, both because of its advanced age and because the aforementioned protections against converting BIP39 words into anything better.
See the booklet for more detail, but essentially the reason to use this scheme, even though it is very time consuming (see next question) and inconvenient, is that you do not want an indefinite trust requirement on electronic computers. codex32 lets you generate and distribute shares, and verify the checksums on said shares, entirely by hand.
This means, for example, that if you are holding a codex32 share, you can check its integrity every year (say), and have a record that the share was recently intact and safe, even if it is years or decades old. To accomplish something using computers, you would need to use the hardware of the day, and at some point in the next century the "hardware of the day" will turn out to have some fatal security bug.
Additionally, even during setup, codex32 gives you assurances that are impossible for computers to provide: that the randomness used during generation was uniform and un-tampered-with; that all intermediate computations were stored on specific sheets of paper and nowhere else; that the contents of said paper can then be securely and permanently destroyed; that there are no electromagnetic sidechannels; and (for a mathematically-inclined user) that the algorithms used are exactly what they are supposed to be.
As a final benefit, anybody who is able to find a copy of the booklet will be able to recover your secret, even if the rest of the world has moved on and no protocols or hardware from the time of share creation is in use anymore.
After some practice, you will likely be able to produce a 128-bit checksum worksheet (and a copy, to check against) in 30-40 minutes; translate shares in about 5 minutes, and add them in another 5.
For a 2-of-3 scheme this works out to 3×40 + 3×5 = 2 hours and 15 minutes to set up; then recovery takes about 10 minutes (but 40 minutes to check, if you check the recovered secret by hand).
For a 3-of-5 scheme the same math gives works out to a bit under 5 hours to produce the shares, 15 minutes to recover and 40 minutes to check the recovery.
Inexperienced users can expect to take 2-3 times this long.
As long as you keep your incomplete work in a secure location, you can spread this work over several days, and/or enlist a highly-trusted accomplice.
Yes, but you will need to modify the checksum worksheet to be much shorter, and the resulting passwords may not contain any I's, 1's, B's or O's. We do not recommend or endorse this.
But it's possible.
As of September 2022, none.
In general, we do not recommend doing this, because the resulting composite scheme will be complicated and non-standard, greatly increasing the risk that you will lose funds simply by forgetting how your scheme works.
Having said that, SLIP39 words represent 10-bit numbers, or two 5-bit bech32 characters, so there is a natural way to convert a 128-bit or 256-bit seed from their wordlist to our encoding (and back), after which you can simply append the codex32 checksum.
You can therefore drop your SLIP39 header and checksum, convert the encoding, the attach a codex32 header and checksum. To recover your funds, do the reverse process. (You will very likely need a computer to recover the SLIP39 checksum.)
If you retain the SLIP39 header and checksum, you won't need to recompute these things, but your data will be longer than 128 or 256 bits, and you will need a special purpose checksum worksheet. Our Documents page has such worksheets [TODO produce these and add links here]. But again, we strongly discourage this.
For BIP39, the same caveats apply as for SLIP39 (see previous question), but worse: BIP39 words represent 11 bits, so the only way to convert them into 5-bit words by hand is to go through binary. This is error-prone and it is basically impossible to detect mistakes. (You should probably do the conversion multiple times, taking a break in between, and compare results.)
BIP39 doesn't have any header; it has a checksum that you can drop from the binary encoding (which is the last 4 bits for a 12-word seed, last 8 bits for a 24-word seed). If you drop this you'll definitely need computer assistance to get it back.
If you insist on doing this, there is a worksheet and conversion table here.
Yes, or else the results could be biased.
One way to illustrate the problem is to imagine that you have a die that comes up one 99% of the time. Then with high probability, you will roll two ones; if you then just kept rolling the die until it came up with a different number, you'd be guaranteed to get a "1 bit" because the first roll was less than the final roll.
To contrast, if you repeatedly rolled that die twice until finally one of the rolls was not 1, then there's a 50% chance that the non-1 roll would come first (a "1 bit") and a 50% chance it'd come second (a "0 bit").
If you are really certain your dice are unbiased, it is also technically possible to directly generate characters instead of the Random Character Worksheet. But if you do this wrong, you might introduce bias anyway. We will not condone or endorse this, and we will not tell you how to do it.
The other processes are safer to speed up: keep practicing until you've memorized much of the volvelles! Or, get a partner to help fill in the worksheets (but make sure you trust this person with your Bitcoin secrets!)
You will need to translate threshold-many shares and them add them all together. Take any translation worksheet, and ignoring the spacing between the lines, write the first two translated shares on consecutive lines. Write the remaining shares leaving a blank line above each one.
Once you have written the shares out, add them together, starting with the first two lines. Put the result in the blank line below them; then add the newly-filled-in line to the line below it, and so on.
There are custom worksheets available in the Documents section [FIXME add these] to make this a bit easier, if you like.