Codex32

[larry_vw_1955]

Codex32 is an error-correcting code designed to be computable without the use of electronic computers. Users can compute and verify checksums by hand; we have provided lookup tables, volvelles and worksheets to assist with this process.

https://secretcodex32.com


I guess if you don't need a passphrase and don't mind downloading (and printing out?) a 48 page pdf file and have alot of time to waste on generating your shares then this might be perfect for you. That way you can pull out k of your shares every so often just to make sure that checksum is still good. We all know that's a big problem is checksums going bad on seed phrases backed up on metal...so of course this thing needed to exist! 

[1714246086]

1714246086

[1714246086]

1714246086

[digaran]

Cool project, but WTF? I read your site for 10 minutes and I'm just more confused. You must consider that 99% of bitcoin users don't understand any of the terms you have used on your site. Btw, there are some typos, such as "die" instead of "dice".
I'm watching this project.😉

[larry_vw_1955]

Cool project, but WTF? I read your site for 10 minutes and I'm just more confused.

I have nothing to do with that project. so it's not my site obviously. i'm not that smart to come up with something that complicated and yeah, it's complicated sh***stuff.

You must consider that 99% of bitcoin users don't understand any of the terms you have used on your site. Btw, there are some typos, such as "die" instead of "dice".

die is the plural of dice just so you know.

I'm watching this project.😉

if they can get some wallet support they might have a fighting chance.

[larry_vw_1955]

Before anyone rushes to judgement on Codex32, I would recommend giving this video a listen:

https://www.youtube.com/watch?v=kf48oPoiHX0&t=1057s

After you finish watching it you'll probably be ready to give up your bip39 seed phrase and starting doing Codex32 instead. 

[NotATether]

Cool project, but WTF? I read your site for 10 minutes and I'm just more confused.

I have nothing to do with that project. so it's not my site obviously. i'm not that smart to come up with something that complicated and yeah, it's complicated sh***stuff.

Your topic post makes this point ambiguous:

Codex32 is an error-correcting code designed to be computable without the use of electronic computers. Users can compute and verify checksums by hand; we have provided lookup tables, volvelles and worksheets to assist with this process.

Anyway, I see it's copyrighted by Blockstream, so no big deal. But it should've been licensed under some free documentation license - MIT is not particularly suitable for printed material.

Do you happen to know how any of those tables in the booksheet are supposed to be used? I count at least 10 different kinds (some with weird pictures for some reason).

[larry_vw_1955]

Your topic post makes this point ambiguous:

Codex32 is an error-correcting code designed to be computable without the use of electronic computers. Users can compute and verify checksums by hand; we have provided lookup tables, volvelles and worksheets to assist with this process.

that was just copied and pasted from their website as a summary of what this project is all about.

Anyway, I see it's copyrighted by Blockstream, so no big deal. But it should've been licensed under some free documentation license - MIT is not particularly suitable for printed material.

why not? it seems fine to me.

Do you happen to know how any of those tables in the booksheet are supposed to be used? I count at least 10 different kinds (some with weird pictures for some reason).

no except the whole process seems like a huge pain in the ass. all it basically is is shamir's secret sharing but you can compute checksums "by hand".

they even want to derive addresses and be able to spend by hand someday. i bet that will be even MORE complicated. 

[ABCbits]

We all know that's a big problem is checksums going bad on seed phrases backed up on metal...so of course this thing needed to exist!  

While Codex32 does better job due to bigger checksum (13 bits) and error correction (up to 8 string/character), i expect most Bitcoiner (even geek ones) would find it's too complicated or afraid to make mistake.

Before anyone rushes to judgement on Codex32, I would recommend giving this video a listen:

https://www.youtube.com/watch?v=kf48oPoiHX0&t=1057s

After you finish watching it you'll probably be ready to give up your bip39 seed phrase and starting doing Codex32 instead.  

Interesting explanation, although i didn't find explantion about what happen if corruption happen on checksum part. It's viable replacement for SLIP39/generic SSS, but i expect many people wouldn't give on BIP39 when it's far simpler.

Anyway, I see it's copyrighted by Blockstream, so no big deal. But it should've been licensed under some free documentation license - MIT is not particularly suitable for printed material.

why not? it seems fine to me.

Because MIT is designed for open source software. It's more suitable if they use either or CC (Creative Commons) or license specifically for documentation[1] instead.

[1] https://www.gnu.org/licenses/license-list.html#DocumentationLicenses

[n0nce]

We all know that's a big problem is checksums going bad on seed phrases backed up on metal...so of course this thing needed to exist! 

Wait, what exactly is a big problem? That checksums on metal seed phrase backups 'go bad'? How exactly do they go bad? And why only the checksum and not the other words? I mean, is the last word somehow affected by corrosion and such (assuming this is why you mention metal specifically) more than the previous words?

[larry_vw_1955]

Interesting explanation, although i didn't find explantion about what happen if corruption happen on checksum part.

Well, nothing happens. Since you can create and verify the checksum using the worksheets.

Because MIT is designed for open source software. It's more suitable if they use either or CC (Creative Commons) or license specifically for documentation[1] instead.

[1] https://www.gnu.org/licenses/license-list.html#DocumentationLicenses

alot of geeks have no idea about documentation licenses. i guess? 

Wait, what exactly is a big problem? That checksums on metal seed phrase backups 'go bad'? How exactly do they go bad? And why only the checksum and not the other words? I mean, is the last word somehow affected by corrosion and such (assuming this is why you mention metal specifically) more than the previous words?

no i was just using a bit of hyperbole. the fact is that checksums on metal don't "go bad" nothing goes bad. but you still might want to verify your checksum 10 years down the road and without using a computer. that's where this project comes in...

[n0nce]

Wait, what exactly is a big problem? That checksums on metal seed phrase backups 'go bad'? How exactly do they go bad? And why only the checksum and not the other words? I mean, is the last word somehow affected by corrosion and such (assuming this is why you mention metal specifically) more than the previous words?

no i was just using a bit of hyperbole. the fact is that checksums on metal don't "go bad" nothing goes bad. but you still might want to verify your checksum 10 years down the road and without using a computer. that's where this project comes in...

But why? I think you're more likely to need / want to verify the whole backup and not just the checksum. And you will need a computer for that, either way.
I mean verifying that funds are still there and everything. It is quite easy / cheap to acquire a computer of some kind, remove disk & networking, boot off USB and restore the BIP39 seed phrase backup. Then you can query some of the addresses using your full node to check that it has the balances you expect.

[Saint-loup]

But why? I think you're more likely to need / want to verify the whole backup and not just the checksum. And you will need a computer for that, either way.
I mean verifying that funds are still there and everything. It is quite easy / cheap to acquire a computer of some kind, remove disk & networking, boot off USB and restore the BIP39 seed phrase backup. Then you can query some of the addresses using your full node to check that it has the balances you expect.

Yes and I would add that nobody is able to create a seed without a computer because a seed without funds is useless, and you need to know at least one address derived from this seed to be able to fill it with funds. And as everybody knows, deriving an address from a seed without a computer is not feasible.
So doing all this work manually doesn't seem to be very useful at the end, I don't see any real use case requiring it at least.
In addition you can split manually a seed into shares without using complex procedures, if you need a kind of SSS scheme to dispatch it in several places (without checksum though).

[larry_vw_1955]

That's true, but only assuming you're confident the data itself is in intact condition.

they claim it can detect up to 8 errors and correct up to 4. which is better than slip39. and if you agree with them that bip39 offers no error correction capabilities then bip39 isn't even on the table...

Forget about choosing appropriate license, documentation itself is biggest problem on open source[1]. Everyone wants good documentation, but it seems only few people willing to work on it. BTW, it's not criticism to Codex32 since their documentation is great.

[1] https://opensourcesurvey.org/2017/

right.

So doing all this work manually doesn't seem to be very useful at the end, I don't see any real use case requiring it at least.

that's why they're asking people to email them if they know how to include those functionalities. just because you use a computer at some point to fund the wallet doesn't mean the entire scheme doesn't have a purpose. the title of the video should give you a hint though: MIT Bitcoin Expo 2022: Breaking Through - Long Term Trust and Analog Computers, Andrew Poelstra

In addition you can split manually a seed into shares without using complex procedures, if you need a kind of SSS scheme to dispatch it in several places (without checksum though).

that would literally be like a terrible idea. 

[Saint-loup]

In addition you can split manually a seed into shares without using complex procedures, if you need a kind of SSS scheme to dispatch it in several places (without checksum though).

that would literally be like a terrible idea.  

I don't think it's terrible, because it will always stay as stronger as copying the initial seed, at least. So it doesn't weaken the seed, if you need to duplicate it.
The iancoleman page is offering this feature, and for a 2 of 3 split of a 24 words seed, it seems to remain very hard to break according to his calculations.


https://iancoleman.io/bip39/

So doing all this work manually doesn't seem to be very useful at the end, I don't see any real use case requiring it at least.

that's why they're asking people to email them if they know how to include those functionalities. just because you use a computer at some point to fund the wallet doesn't mean the entire scheme doesn't have a purpose. the title of the video should give you a hint though: MIT Bitcoin Expo 2022: Breaking Through - Long Term Trust and Analog Computers, Andrew Poelstra

That's why I weighed my words by saying it "doesn't seem" to be "very" useful, and by adding that "I don't see" any real use case "at least".
The obvious one is when you receive, inherit or find a seed while you have no access to a trustable device because you are in an isolated place (a boat, a jail, a place without electricity, ...) or because you are too poor to buy one. But apart from that one, I don't think there are many other use cases in real life to be honest.
 

[larry_vw_1955]

The iancoleman page is offering this feature, and for a 2 of 3 split of a 24 words seed, it seems to remain very hard to break according to his calculations.

Unless he is following some standard that can be duplicated without referring to his code then that's a "no-go". And I doubt you have inspected his code to see exactly how he is doing it. anytime a checksum is not used that's probably a terrible idea...and you mentioned the phrase "without checksum"...

I don't think there are many other use cases in real life to be honest.

there's use cases for it. it just depends if you need to verify your seed phrase checksum periodically by hand or not. some people might want that capability.

[gmaxwell]

deriving an address from a seed without a computer is not feasible.

That's not clear to me.

With sufficiently clever and large lookup tables it could be done by hand with a lot of effort.

Enough effort that probably no one would ever do it except as a joke.

So not much justification to come up with the scheme for it.

[larry_vw_1955]

deriving an address from a seed without a computer is not feasible.

That's not clear to me.

With sufficiently clever and large lookup tables it could be done by hand with a lot of effort.

something like that would definitely be useful. you could print out the entire lookup table and bind it together into a book and then anytime you need a new address you can get one without using a computer.

Enough effort that probably no one would ever do it except as a joke.

So not much justification to come up with the scheme for it.

if it has never been done but could be done then that is enough justification for it. somewhere somebody will find a need for it. for sure.

next step: spending coins without a computer. 

2. Someone point out Codex32 has limitation to store metadata (e.g. derivation path)[3].

you can't even store ANY metadata with bip39 at least with codex32 there's a 4 character bech32 id that someone gets to choose however they want. if there was some standard about how to specify a derivation path then it could be used for that assuming 4 characters are enough to specify a reasonable set of derivation paths. but then it would need to be able to decode it using the little wheel thingies or (less fun but still acceptable) a rectangular lookup table...

[andytoshi]

I'm a little late to this thread, but FYI the reason that the doc uses a MIT license rather than a "documentation license" is that the document itself is code. It is written in PostScript and can be edited or viewed with a text editor (in case you want to verify e.g. that the volvelles or tables were computed correctly).

[gmaxwell]

Anyway, I see it's copyrighted by Blockstream, so no big deal. But it should've been licensed under some free documentation license - MIT is not particularly suitable for printed material.

why not? it seems fine to me.

Because MIT is designed for open source software. It's more suitable if they use either or CC (Creative Commons) or license specifically for documentation[1] instead.

This is bad advice and I would strenuously recommend against it. Many non-software licenses do not contain an expansive waver of liability (except sometimes for representations related to the copyright status of the work) e.g. CC0, FDL, LAL. all lack one.  Many other licenses also have problematic terms such as explicit non-waving of patent-rights (e.g. CC0, CC-By-4, CC-By-SA-4).  The FreeBSD-DL is essentially the same as the MIT license but with freebsd and documentation written all over it, perhaps fine but not an improvement unless you happen to be named "FreeBSD".

Even ignoring andytoshi's point about the document itself being a postscript program, the scheme Codex32 is itself software: it's just designed to be run on meat and paper rather than on metal.