Topic: Private keys starting with L or K instead of 5? (Read 3656 times)

This is because you intuitively see the advantage of having a bitcoin transaction consume fewer resources (bytes) in the blockchain, but are not yet convinced that scanning private keys will allow bitcoin to take fewer resources (neurons) in the brains of those non-developers who would consider adopting it.

Bitcoin could take "be your own bank" to a whole new level if the vision were more widespread.  Bitcoin can let the common man replace the ATM, which for the public, would be a huge way to fire their bank.

It is simple: rather than withdrawing cash from an ATM, you withdraw cash from your computer and print it.  You take it to the store and spend it.  Spending happens when they scan the cash to validate the key and make the money theirs.  You get back your change when they capture only part of a bill's balance and give it back, or they print you a new bill with your change.  If you are concerned the merchant or the clerk might later steal your change, you tear an unused bill in half and give them only the bitcoin address and ask for your change to go there.  Screw the banks, be your own ATM, and never pay an ATM fee to a bank ever again.

The part I have bolded compresses the concept of "Bitcoin - be your own bank" best into the fewest layman-neuron-bytes.  If we want Bitcoin to exceed beyond the domain of people with technical brilliance, then we should not brush aside some of the most practical applications that would make sense to the public because it doesn't sit well with the cryptographic unorthodoxy of human eyes ever seeing a private key.

Compressed public keys help the size of the blockchain. Unless you negotiate full public keys (like will be necessary for multisig, probably), compressed public keys don't help you for scanning (an address is still 160 bits, shorter than a public key).

Though there are uses, I don't think scanning private keys will (or should) be common.

Compressed keys were not used initially because either Satoshi didn't know about them, or preferred avoiding them for legal reasons (those appear very limited, anyway).

A compressed public key is definitely useful because they will often be scanned at distance where scanning resolution may be a factor. Private keys will be scanned at close range. There is a real world reason to use compressed keys. Why used uncompressed keys at all?

Actually having people to believe in magic work very well, just looks at apple proucts, they are MAGICAL

Some of us need to understand and I think there is large benefit in making that simper anywhere reasonable. But we're going to be asking most people to believe in magic and it's going to be fine because they've been doing it all along.

I can't agree with this.  They do need to see it, if they want to.  It is important for people to understand how Bitcoin works in detail for them to have confidence in it, and to blackbox the implementation is to spread people's trust budget needlessly thin.

Asking people to believe in "magic" rather than allowing them to understand the basic fundamental concepts (including "your money is represented by a secret number" and "yes, the number is a number you can see, print, say, hold") is to prevent them from understanding the system well enough to put their faith in it.  Once they understand this much, then QR codes are a useful shortcut for convenience's sake.
 

I hope a typical human never needs to see a base58 private key.

Actually, I hope they don't need to see anything base58 at all (think URL's, files, QR codes, ...).

It still will be copy-pasted in practical use, but allowing people to see private keys, internalize the heuristic of "5 blah blah blah", and know that when they look at such a number that it's likely a private key, has real value that shouldn't be taken lightly.

The same way that in aviation, airplane registration numbers are gibberish, but they conform to certain prefix and length rules so someone can look at or hear an airplane call sign, and know that it is an "airplane", rather than an airport or a waypoint or other navigational resource, which also have alphanumeric identifiers.  Things would get confusing fast, and needlessly if pilots and air traffic controllers had to memorize a convoluted flowchart of mental tests to decipher an identifier... resources much better spent on learning to fly the plane etc.

The real estate of "256 possible version bytes" is a far less endangered resource compared to the amount of neurons a human being needs to dedicate to Bitcoin to feel comfortable that they understand it.  Besides, there are two factors that uniquely identify a base58check-encoded string as being a Bitcoin private key: the version byte 0x80 and the fact that exactly 32 bytes follow it.  Private keys truly occupy a very small slice of the base58 "spectrum"... there is plenty to go around for the sake of keeping things reasonably simple for the user.

What you suggest was my first idea.

I changed it not to further pollute the version byte namespace. It was originally a version number, and after time it grew into something that contains informations about data types, network, ... as well. I preferred not to add a new number for a variant of the exact same thing. Or put otherwise: i feel that secret keys are linked to addresses - one shouldn't change version if the other doesn't, and obviously addresses don't change because they're using compressed pubkeys (they can't for compatibility reasons).

I mailed about this suggestion to the development mailinglist(*), including several test vectors. As far as I know, nobody complained.

I must admit I didn't take human recognizability into account too much. Even though base58 was designed for ease of human transmission, things with the length of a secret key will always be copy-pasted anyway.

(*) URL: http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development

I notice in the Wiki article for "Private key" that:


I am wondering who came up with this idea and why?

I would hope that if we needed to signal a "compressed" flag in a private key, we would do so by using some identifier other than 0x80, perhaps one slightly higher, so as to not needlessly burden people with understanding why there are different kinds of private keys.  By doing so, we'd be consuming the attention span of the average user needlessly, the same as if we flagshipped "tonal bitcoins" in the mainline client.

If an identifier of 0x88 is used, for example, a private key will still be 51 characters starting with '5', and those who really need to know it's compressed at a glance can do so by the second character.  (regular private keys start with 5J, 5K, or 5L... keys in this range would start with something else in the 2nd character).

Can we deprecate the 52-character private keys, or is there some technical reason or advantage it should be done this way?