Topic: Can someone explain the different address->keys to me? (Read 257 times)

As ranochigo says, there is no benefit to using uncompressed keys. When bitcoin was first created, all keys were uncompressed. Compressed keys weren't introduced until version 0.6. They have the advantage of being smaller, making transactions cheaper, allowing more transactions to fit in a block, and slowing down the growth of the size of the blockchain. With newer address types such as segwit, compressed keys became the default for these reasons.

Any person or service still using uncompressed keys is likely very outdated, or trying to do something manually and messing up.

No one should. It would just increase the size of their transaction unnecessary. The quote probably isn't trying to encourage to do so, but just to state that it is still possible generate sw addresses with uncompressed keys. There are services still using uncompressed keys but probably due to laziness.

Why would someone want to create uncompressed keys? Is there a benefit that I am missing?

List of address prefixes
Invoice address

Mnemonic Code Converter: https://iancoleman.io/bip39/
Mastering Bitcoin. The chapter 4 is for Key, addresses.

How Bitcoin addresses are generated
[Full Guide+Code]Seed Phrase & The Process of Deriving Bitcoin Addresses from It

Oh my, just thinking of all of the ways that "1" can be represented...

1
0x01
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
00000000 00000000 00000000 00000000 00000000 00000000 00000000 10000000
00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
10000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0000000000000000 0000000000000000 0000000000000000 1000000000000000
1000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000001 0000000000000000 0000000000000000 0000000000000000
00000000000000000000000000000000 10000000000000000000000000000000
00000000000000000000000000000001 00000000000000000000000000000000
r
11111111111111111111111111111112
5Fe7g7ksGZWd6kKpr4wzm68kLXKau9ghwipGHWRbVwYnCtMosnezXRgnXoxK8EJdPQFJcLHswC3uxUj P3pxTkX1hq
MQ==
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMQ==

...and plenty more.

The only difference is that the Wallet Import Format key must be compressed for segwit addresses,* whereas it can be either compressed or uncompressed for legacy inputs (although all good wallets now use compressed keys because they create smaller, and therefore cheaper, transactions). There is no difference in the base hexadecimal key, and as above, every private key can generate both types of addresses.

*Note that it is possible to create segwit addresses using uncompressed keys, but these will create non-standard (although still valid) transactions which will not be relayed by nodes.

A Bitcoin private key is a number between 1 and FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140.


Yes, but on a hypothetical 512-bit little-endian processor, it might be better to represent the key in a 64-byte little-endian format, and convert to a 32-byte big-endian format only when needed.

This is what I was missing before this thread.
I should have started with "what's the difference between segwit and legacy keys or import formats?".
I wasn't sure whether there was a difference, and did not realize how to describe my question.

At any rate, a key is a 32 byte number.

That I didn't know previously.. Thanks.
Also, that was new info to me regarding the compressed vs uncompressed.
Well, sure.

It would be confusing to have software that imported keys as little endian, instead of the standard big endian.
Storing or hashing as big or little endian would depend on the software used, although it would be ridiculous to not use the standard - especially as it has to interact with users, miners and node formats.

Endianness is a description of the encoding of a number into data, or vice versa. Once a number stops being a number and becomes data, then it is important to agree on how the number is encoded.

Correct. Although I'm not sure what you are referring to when you say "legacy" and "new keys". Private keys do not differ between the different types of addresses they generate (with the exception of segwit addresses only being created from compressed keys and not their uncompressed equivalent.) Indeed, the same 32 byte private key can be used to generate a P2PKH, a P2SH, and a P2WPKH address.

For example, I can take the following private key (a brain wallet generated from the string correct horse battery staple):


And from it, generate all of the following addresses:


Private and public keys are big endian.

That answers my question!
And, actually a lot of other questions.
Cool. Thanks.

To restate it then, all key formats are based off of 32 bytes, 64 character hexadecimal numbers, or 256 bit, (all three of which are saying the same thing) which includes both legacy and new keys prior to checksum, encoding, and marking into their imported formats.  

-
Having leading zeros is a particular case where the definition above may fail..
but I'd argue you still need to know the encoding mechanism. A 16-byte "1" would not result in the same hashes, I think. Also, since  1 can be defined by 63 leading vs trailing zeros in hex, although since key endianness is defined in a particular way in core, I would be the wrong one here. Or 31 zeros in bytes, although a human would not import in bytes..  In bits, it wouldn't matter other than endianness.

No. The smallest possible private key is 1, but it is still expressed as a 32 byte number with 63 leading 0s before the 1.

The standard private format is a 64 character hexadecimal number. Different private key formats, such as WIF or Minikey, are simply different ways of encoding the same information.

Also 0x01 appended prior the checksum being calculated for compressed keys (which almost all keys now are), and the final result being encoded in Base58.

Thank you all for your descriptions. That was very useful, but my initial mislanguage missed the target.

My question is, are there private keys that are not fundamentally 32 bytes?
Or, what is the difference between legacy and newer private key import formats inside core?

Legacy WIF is 80+[ 32 byte key ]+[checksum]

As far as I can tell, a base private key has only 32 bytes in any version / import format, but information on private keys to import formats isn't easily forthcoming. The related question is how secure are address types caused by the different import formats / keys, but I can't understand that unless I understand these initial private key methods.

You are mixing up two different classification systems here.

Bech32 refers to the format of the address. The other option is Base58Check.

P2PKH and P2SH refer to the ScriptPubKey, or the type of transaction. There are far more than just P2PKH and P2SH, such as P2PK, P2MS, P2WPKH, P2WSH, and now P2TR.

I just want to add this below.

I think you would need this "List of Bitcoin prefixes"
You can use it as your reference to know which one is your private or public keys or if it's a compressed or uncompressed WIF key, or if it's a legacy(p2pkh), p2wpkh-p2sh, and bech32(p2wpkh) wallets.

You might also need to read this one below to understand the differences between these addresses

- Everything You Should Know About Bitcoin Address Formats


I guess like the above said this is a bech32 address the only types of addresses are P2PKH, P2SH, and bech32 the link above should help you determine which one is bech32 or legacy wallet.

In short the relationship is the following where <-> means reversible and -> means one way in the direction of the arrow:

In asymmetric cryptography we have key pairs that consist of a "private key" and its corresponding "public key". Computing the public key from the private key is easy and fast but the reverse (finding private key from public key) is impossible. This characteristic alongside the signature algorithm allows us to publicly provide the signature + public key so that anyone can verify the validity of the signature.

In bitcoin to transfer coins we create "smart contracts" using the strong script language that bitcoin provides. These scripts are like "locking conditions" that can be "unlocked" or "spent" when the condition is satisfied, which usually requires a signature and the public key as explained above.

Since transferring the script around is not user friendly we have created human readable format of the most common scripts known as "addresses". We currently have P2PKH, P2SH, P2WPKH, P2WSH and by the end of this year P2TR script/address types.
Each address corresponds to one of these scripts and allows the wallet to construct it and place that script in the transaction's outputs.

For example a P2PKH address:

For different scripts we use different address types, different encodings and versions. For example for a P2TR we use Bech32m with version = 1 and the address will look differently.

1. I believe what you are referring to is called a "bech32" address, and not a "32-byte" address.
2. Keys do not come from addresses. It is the other way around. An address is derived from a public key, which is derived from a private key.

The answer to your question is that there are 2 address encoding formats:

1. Base58Check. This gives you addresses that begin with a "1" or "3", such as "1CtfcziAhqx83CtSPdufgZDGmL8ohTFTdd" or "3HPF1x3g34oeiakfmrUb8Ej6mbWSj8CpZc"
2. Bech32. This gives you an address that begins with "bc1", such as "bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4".

Security-wise, bech32 is a little safer for various reasons.

https://bitcointalksearch.org/topic/step-by-step-guide-to-go-from-public-key-to-a-bech32-encoded-address-4992632

I think you can see the 32 byte address and learn something from it

I understand the basics of bitcoin, and even how to make keys from a 32-byte address.

Are there different types of addresses besides 32-bytes? Is there a good primer (or software libraries?) on the algorithms used to make keys from those addresses? What are the security dis- or advantages of each method?