I'm a little late to this party, but stumbled across the thread as I was looking into the same idea myself. It's simple enough to generate base-32 keys (same as base-58 but all caps) and they work fine within the existing framework. (I did try your existing standard for base-32 but some characters weren't recognised by blockchain.) 145 bits of entropy so should do the job ok. I'm looking at stamping/engraving them on jewellery for long-term cold storage, possibly with another tier of protection.
Did you get anywhere further with the idea?
Topic: Base32 keys? (Read 2884 times)
Just wondering if I'm missing something important here or if I might have stumbled upon something reasonable...
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string, of which one character is a checksum. These mini private keys would then have log2(58^21) or approximately 123 bits of entropy. For the sake of this question, let's assume that 123 bits is adequate - I know the counterargument but just assume that 123bits = reasonable as a premise and tell me if the rest of my argument holds up.
There exists a base 32 standard consisting of the letters A-Z and the numbers 2-7, leaving out the numeric digits to avoid confusion with similar letters, thus avoiding confusion. If we assume that 123 bits of entropy is adequate then log2(32^25)=125 bits should also be adequate. Add the one-digit checksum back in and you have a 26 digit string instead of a 22 character string, but with only 4 additional characters (about an 18% increase in length) you've bought the ability to use a case-insensitive mechanism. This means such keys could easily be scribbled down for someone, read out over the phone, etc without spending the time and complexity to describe the mixed-case of the aplha bits. At 32 digits (33 including a checksum digit), such a string would represent log2(32^32)=160 bits of entropy, exactly the same as present in an actual Bitcoin address.
Mechanically this could function in much the same way a base58 mini privkey does, simply take sha256(x) and use that as the privkey - or more accurately either sha256(upper(x)) or sha256(lower(x)) depending on how the standard gets written.
Is there some problem I've overlooked or is this a viable method? Would there be any interest in a product utilizing case-insensitive privkeys or am I wasting my brainpower on this?
I agree.For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string, of which one character is a checksum. These mini private keys would then have log2(58^21) or approximately 123 bits of entropy. For the sake of this question, let's assume that 123 bits is adequate - I know the counterargument but just assume that 123bits = reasonable as a premise and tell me if the rest of my argument holds up.
There exists a base 32 standard consisting of the letters A-Z and the numbers 2-7, leaving out the numeric digits to avoid confusion with similar letters, thus avoiding confusion. If we assume that 123 bits of entropy is adequate then log2(32^25)=125 bits should also be adequate. Add the one-digit checksum back in and you have a 26 digit string instead of a 22 character string, but with only 4 additional characters (about an 18% increase in length) you've bought the ability to use a case-insensitive mechanism. This means such keys could easily be scribbled down for someone, read out over the phone, etc without spending the time and complexity to describe the mixed-case of the aplha bits. At 32 digits (33 including a checksum digit), such a string would represent log2(32^32)=160 bits of entropy, exactly the same as present in an actual Bitcoin address.
Mechanically this could function in much the same way a base58 mini privkey does, simply take sha256(x) and use that as the privkey - or more accurately either sha256(upper(x)) or sha256(lower(x)) depending on how the standard gets written.
Is there some problem I've overlooked or is this a viable method? Would there be any interest in a product utilizing case-insensitive privkeys or am I wasting my brainpower on this?
And besides, dividing and multiplying big numbers without a reason - what base58 does - is just stupid. Like compressing a zip over again...
But well, after the things are already there, sometimes is best just to deal with them instead of complicating by simplifying
Thanks for the info Casascius. Now if I could just get whatever Bitcoin lib you used in your address utility to convert between a byte array and a base58 string reliably I might actually have something to offer up 
I can't for the life of me figure out why someone would write two converter functions in the form a2b and b2a such that b2a(a2b(x)) != x. I'm assuming it's something you took from the mainstream since I think the great Casascius would write better code than that
I can't for the life of me figure out why someone would write two converter functions in the form a2b and b2a such that b2a(a2b(x)) != x. I'm assuming it's something you took from the mainstream since I think the great Casascius would write better code than that
For what it is worth, I have switched all of my coins (other than the Series1) to 30-character keys, and have advised anyone who has asked for minikey advice to stick strictly to the 30 character format. For example, BitPay is using 30-character minikey on their cards. Only the first 11,000 of my keys were produced in the 22-character format.
30 characters gives over 160 bits of entropy - putting it on par with the amount of entropy in a Bitcoin address.
The first physical bitcoins I hand-punched the private keys out of paper using an oversize hole punch. Precision is tedious if the punching itself isn't already. For my sake, ever since I got that laser cutting machine, I can be pretty precise in cutting those private key circles, and can consistently cram 30 characters into my coins, including my 25BTC coin which has the smallest diameter recess for the private key. I'm doing six lines: 4, 5, 6, 6, 5, 4 characters, so they fit nicely on a circle.
But even if you did a single-cased 30-character minikey (29 unique symbols with 32 possibilities), that's still 145 bits, and plenty reasonable. Nothing says you can't declare a "32 character minikey" as valid and stipulate that when it's 32 characters, it's case insensitive as well.
30 characters gives over 160 bits of entropy - putting it on par with the amount of entropy in a Bitcoin address.
The first physical bitcoins I hand-punched the private keys out of paper using an oversize hole punch. Precision is tedious if the punching itself isn't already. For my sake, ever since I got that laser cutting machine, I can be pretty precise in cutting those private key circles, and can consistently cram 30 characters into my coins, including my 25BTC coin which has the smallest diameter recess for the private key. I'm doing six lines: 4, 5, 6, 6, 5, 4 characters, so they fit nicely on a circle.
But even if you did a single-cased 30-character minikey (29 unique symbols with 32 possibilities), that's still 145 bits, and plenty reasonable. Nothing says you can't declare a "32 character minikey" as valid and stipulate that when it's 32 characters, it's case insensitive as well.
I ended up switching to zbase32 since most of the keys and such aren't multiples of 5 bits, saves even more space. Now I just need to hack together the code to convert between Casascius-style base58 mini keys and their (z)base32 equivalents. Given that I've already got libs on both sides that speak hex I think I'll use it as an intermediate value. We'll see how it works out...
Well, I've already tweaked Casascius' Bitcoin Address Utility to output in b32 as well as hex/b58 and to convert keys entered in b32 back to hex/b58 and I am the weird sort of geek who calls that "fun"... More curious whether I should bother making my tweak available
Ok so let's ignore the 123-bit keys and just focus on a 32-character base32 key that would have the same 160 bits of entropy found in a standard base58 Bitcoin address. The fundamental question remains the same: are there sufficient benefits to a case-insensitive privkey format that I should even waste my time formalizing this crazy thought I had?
Also, as I mentioned, the base 32 standard uses A-Z 2-7. It's explicitly designed for the same things Bitcoin's base58 was designed for - expressing binary data in a way you can write down and type back in elsewhere - it's just not case sensitive. The price you pay for that is that base58 has log2(58) or ~5.86 bits of entropy per character while base32 has log2(32)=5 bits of entropy per character, so the keys will be longer. At 5 bits per character, you'd need 26 digits (not counting optional checksum) to surpass the 128-bit mark you mentioned.
Also, as I mentioned, the base 32 standard uses A-Z 2-7. It's explicitly designed for the same things Bitcoin's base58 was designed for - expressing binary data in a way you can write down and type back in elsewhere - it's just not case sensitive. The price you pay for that is that base58 has log2(58) or ~5.86 bits of entropy per character while base32 has log2(32)=5 bits of entropy per character, so the keys will be longer. At 5 bits per character, you'd need 26 digits (not counting optional checksum) to surpass the 128-bit mark you mentioned.
I don't think it's worth time formalizing it unless you're having fun in the process. We already think the keys and addresses are too long and generally want to move away from humans directly handling them where we can. One fun point about base-32 is that since log2(32) is an integer, the digits form a Galois field and you can easily use either a reed-solomon error correcting code or a well tuned CRC for much better error handling (e.g. absolute certainty that no N point mutations are also valid).
Just wondering if I'm missing something important here or if I might have stumbled upon something reasonable...
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format#Entropy_considerations
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string,
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format#Entropy_considerations
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string,
The thing you're missing is that Casascius was of the opinion that he had absolutely no room for longer. Otherwise the keys would absolutely have been >=128 bit just to meet the normal good standards practice.
Base-58 already omits the most easily confused characters, including 'l' (which can be confused with 1 e.g. under a base 32 scheme).
Ok so let's ignore the 123-bit keys and just focus on a 32-character base32 key that would have the same 160 bits of entropy found in a standard base58 Bitcoin address. The fundamental question remains the same: are there sufficient benefits to a case-insensitive privkey format that I should even waste my time formalizing this crazy thought I had?
Also, as I mentioned, the base 32 standard uses A-Z 2-7. It's explicitly designed for the same things Bitcoin's base58 was designed for - expressing binary data in a way you can write down and type back in elsewhere - it's just not case sensitive. The price you pay for that is that base58 has log2(58) or ~5.86 bits of entropy per character while base32 has log2(32)=5 bits of entropy per character, so the keys will be longer. At 5 bits per character, you'd need 26 digits (not counting optional checksum) to surpass the 128-bit mark you mentioned.
Just wondering if I'm missing something important here or if I might have stumbled upon something reasonable...
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format#Entropy_considerations
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string,
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format#Entropy_considerations
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string,
The thing you're missing is that Casascius was of the opinion that he had absolutely no room for longer. Otherwise the keys would absolutely have been >=128 bit just to meet the normal good standards practice.
Base-58 already omits the most easily confused characters, including 'l' (which can be confused with 1 e.g. under a base 32 scheme).
Just wondering if I'm missing something important here or if I might have stumbled upon something reasonable...
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string, of which one character is a checksum. These mini private keys would then have log2(58^21) or approximately 123 bits of entropy. For the sake of this question, let's assume that 123 bits is adequate - I know the counterargument but just assume that 123bits = reasonable as a premise and tell me if the rest of my argument holds up.
There exists a base 32 standard consisting of the letters A-Z and the numbers 2-7, leaving out the numeric digits to avoid confusion with similar letters, thus avoiding confusion. If we assume that 123 bits of entropy is adequate then log2(32^25)=125 bits should also be adequate. Add the one-digit checksum back in and you have a 26 digit string instead of a 22 character string, but with only 4 additional characters (about an 18% increase in length) you've bought the ability to use a case-insensitive mechanism. This means such keys could easily be scribbled down for someone, read out over the phone, etc without spending the time and complexity to describe the mixed-case of the aplha bits. At 32 digits (33 including a checksum digit), such a string would represent log2(32^32)=160 bits of entropy, exactly the same as present in an actual Bitcoin address.
Mechanically this could function in much the same way a base58 mini privkey does, simply take sha256(x) and use that as the privkey - or more accurately either sha256(upper(x)) or sha256(lower(x)) depending on how the standard gets written.
Is there some problem I've overlooked or is this a viable method? Would there be any interest in a product utilizing case-insensitive privkeys or am I wasting my brainpower on this?
For physical bitcoins and other scenarios where representing a private key in the fewest possible characters is a plus, the standard current format appears to be the mini private key format: https://en.bitcoin.it/wiki/Mini_private_key_format
The standard mini private key format (as used on Casascius' coins anyway) uses a 22-character base 58 string, of which one character is a checksum. These mini private keys would then have log2(58^21) or approximately 123 bits of entropy. For the sake of this question, let's assume that 123 bits is adequate - I know the counterargument but just assume that 123bits = reasonable as a premise and tell me if the rest of my argument holds up.
There exists a base 32 standard consisting of the letters A-Z and the numbers 2-7, leaving out the numeric digits to avoid confusion with similar letters, thus avoiding confusion. If we assume that 123 bits of entropy is adequate then log2(32^25)=125 bits should also be adequate. Add the one-digit checksum back in and you have a 26 digit string instead of a 22 character string, but with only 4 additional characters (about an 18% increase in length) you've bought the ability to use a case-insensitive mechanism. This means such keys could easily be scribbled down for someone, read out over the phone, etc without spending the time and complexity to describe the mixed-case of the aplha bits. At 32 digits (33 including a checksum digit), such a string would represent log2(32^32)=160 bits of entropy, exactly the same as present in an actual Bitcoin address.
Mechanically this could function in much the same way a base58 mini privkey does, simply take sha256(x) and use that as the privkey - or more accurately either sha256(upper(x)) or sha256(lower(x)) depending on how the standard gets written.
Is there some problem I've overlooked or is this a viable method? Would there be any interest in a product utilizing case-insensitive privkeys or am I wasting my brainpower on this?
Jump to: