Can someone explain the different address->keys to me?

[kaggie]

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?

[1713942613]

1713942613

[1713942613]

1713942613

[EYC_ONE]

https://bitcointalk.org/index.php?topic=4992632.0

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

[odolvlobo]

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.

[pooya87]

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

Code:

private key -> public key -> public key hash <-> address

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:

Code:

private key:
L2PjeW8wtzsVU5wQAt5C65KPErswtatMToGbQW3yFnwpW4ap9yYR

public key (compressed):
03B44AE69F9E39BE1B51ABF1726B3D7F4F71138CDED04D297A112F6FFB7364DA51

public key hash160:
0f62fd75318dff4dd4f780e3901399bef2ec1ed7

P2PKH script
OP_DUP OP_HASH160 <0f62fd75318dff4dd4f780e3901399bef2ec1ed7> OP_EQUALVERIFY OP_CHECKSIG

P2PKH address (base58check encoding of hash160 with version=0)
12QMiq2bvj23EXxQgLZBCNNbPJDBvVLCuP

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.

[BitMaxz]

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

Are there different types of addresses besides 32-bytes?

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.

[o_e_l_e_o]

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.

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.

[kaggie]

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

Are there different types of addresses besides 32-bytes?

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.

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.

[o_e_l_e_o]

My question is, are there private keys that are not fundamentally 32 bytes?

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.

Or, what is the difference between legacy and newer private key import formats inside core?

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.

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

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.

[kaggie]

My question is, are there private keys that are not fundamentally 32 bytes?

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.

Or, what is the difference between legacy and newer private key import formats inside core?

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.

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

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.

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.

[o_e_l_e_o]

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.

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):

Code:

C4BBCB1FBEC99D65BF59D85C8CB62EE2DB963F0FE106F483D9AFA73BD4E39A8A

And from it, generate all of the following addresses:

Code:

Uncompressed P2PKH: 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
Compressed P2PKH: 1C7zdTfnkzmr13HfA2vNm5SJYRK6nEKyq8
P2WPKH-P2SH: 3KToBU4ykTWfjnu4kAUV1q8QosnxT61sbf
P2WPKH: bc1q08alc0e5ua69scxhvyma568nvguqccrv4cc9n4

In bits, it wouldn't matter other than endianness.

Private and public keys are big endian.

[odolvlobo]

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.

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.

[kaggie]

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.)

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.

Indeed, the same 32 byte private key can be used to generate a P2PKH, a P2SH, and a P2WPKH address.

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

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.

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.

[odolvlobo]

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

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

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.

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.

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.

[o_e_l_e_o]

I should have started with "what's the difference between segwit and legacy keys or import formats?".

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.

[kaggie]

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.

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.

[hd49728]

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

[Macadonian]

*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.

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

[ranochigo]

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

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.

[o_e_l_e_o]

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

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.