How to generate public and private key.

[Clegive8V]

I did not find a topic explaining how to generate addresses in a technical, detailed, and direct answer, I am asking here for direct detailed answer.

Previous topics I read:

https://bitcointalk.org/index.php?topic=5223167.msg53772308#msg53772308
https://www.youtube.com/watch?v=8es3qQWkEiU

From what I understood that we have a private and public key correspond to a point on the secp256k1 curve.
We have the option to choose the private key and then derive the public key from that private key.
address is derived from the public key by performing a ripemd160 hash.

Blockchain does not verify addresses, so if we mistake it for the right address, we will lose our money.


Now suppose I choose a 99 random bytes to generate the private key, it is not a perfect idea but I want to know. How is the addreess, public and private key generated?

In one of the YouTube videos I found this educational tool, it has many details, I hope someone will explain it better or give me an article link for that.
https://www.mobilefish.com/services/cryptocurrency/cryptocurrency.html

[1715017898]

1715017898

[ranochigo]

From what I understood that we have a private and public key correspond to a point on the secp256k1 curve.
We have the option to choose the private key and then derive the public key from that private key.
address is derived from the public key by performing a ripemd160 hash.

Address is derived from the public key by taking the public key and:
1) Hash it using SHA256 once
2) Hash it using RIPEMD-160
3) Put the version byte at the front
4) SHA256 hash it twice
5) You'll be able to extract the checksum from the first few bytes
6) Insert the SHA256 hash at the end of the RIPEMD160 with version byte and BASE58 encode it.

Blockchain does not verify addresses, so if we mistake it for the right address, we will lose our money.

Every address comes with a checksum. If you accidentally capitalise a character in the address, it'll not be valid.

Now suppose I choose a 99 random bytes to generate the private key, it is not a perfect idea but I want to know. How is the addreess, public and private key generated?

As long as your 99 random bytes is within the range of acceptable values for an ECDSA private key, it's alright.

Let's take it as 01.
Your ECDSA private key is 01

From there, we'll convert it to an ECDSA public key by multiplying it against the generator point. The number of times the number gets multiplied against the generator point is dependent on the number of your private key which is once.

I thus obtain the ECDSA public key to be 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C 4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8.


After this, I'll do my steps 1 to 6.
1) SHA256 Hash of my ECDSA Public key
50929B74C1A04954B78B4B6035E97A5E078A5A0F28EC96D547BFEE9ACE803AC0
2) RIPEMD160 Hash of the above
91B24BF9F5288532960AC687ABB035127B1D28A5
3) Apprehending the network byte to the front (for P2PKH addresses on Bitcoin mainnet, it is 00)
0091B24BF9F5288532960AC687ABB035127B1D28A5
4) SHA256 the above
79FA926BF4AC874060B244D6E985C694233EED0D5562C0B88CDF37BFBB80B44F
5) SHA256 the above
0074FFE0526D823BE09B39865422A1D6135AFC85AFB0A6863C58E9FE89989170
6) Take the first 4 bytes as our checksum
0074FFE0
7) Apprehend the checksum to the end of the SHA256 hash
0091B24BF9F5288532960AC687ABB035127B1D28A50074FFE0
Use BASE58 encoding
1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm

The address generated is an uncompressed P2PKH address. There are different standards which may (P2PWSH, P2PWKH) or may not utilise ECDSA for a keypair (P2SH).

[BrewMaster]

there are so many questions smashed together here. so lets start from the beginning: creating a private key.
to create a new private key you have to choose a random number between 1 and N (which is a little smaller than 2^256 but lets skip that for now) you can't choose any arbitrary size bytes like 99 bytes, it needs to be close to the final size which is 32 bytes otherwise you'll have to reduce it and it can create bias (which 99 bytes would).

now that you have chosen that number, it means you have also chosen a corresponding point (x and y coordinates) on the secp256ik1 curve which is called your public key and can be shared freely. it is computed by performing Elliptic curve point multiplication (https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication).

address is derived from the public key by performing a ripemd160 hash.
Blockchain does not verify addresses, so if we mistake it for the right address, we will lose our money.

to understand that you have to first understand how bitcoin works.
when someone sends bitcoin they are basically creating a "lock" that can be "unlocked" by providing an "unlocking mechanism" like a key that can only unlock that "lock".
some of these "locks" have a certain standard pattern that we have defined a human readable form for them. for example if the pattern is OP_DUP OP_HASH160 <160-bit hash> OP_EQUALVERIFY OP_CHECKSIG we use the version 0 bitcoin address for it.
but this locking mechanism could simply be OP_DUP OP_HASH256 <256-bit hash> OP_EQUALVERIFY OP_CHECKSIG where we don't have any human readable form (aka address) defined for it but it does the exact same thing.

keeping that in mind, the answer to your question is one of the common addresses known as P2PKH and a new address that is also common P2WPKH are using the HASH160 of public key which is RIPEMD160 of SHA256 of public key.
but there are some other addresses that are more complicated than that. for example P2SH addresses that are HASH160 of a script that may or may not contain a public key. they also are defining a "locking mechanism".

[AdolfinWolf]

Blockchain does not verify addresses, so if we mistake it for the right address, we will lose our money.

Every adress has a checksum so it's pretty hard (impossible) to send to an adress with a typo.

https://gobittest.appspot.com/Address

Now suppose I choose a 99 random bytes to generate the private key, it is not a perfect idea but I want to know. How is the addreess, public and private key generated?

Needs to be below

Code:

0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140

due to the curvature

then you ecsda it (get a public key), so you take a scalar (private key below ^) and repeat that along the the curve.
That results in a public key on which you perform the necessary operations.

for a standard address, see https://gobittest.appspot.com/Address

So let's say we have scalar

Code:

97668528691423002059228747364507275544785515506959736128404960720826822156012n

which is valid, because it's below

Code:

115792089237316195423570985008687907852837564279074904382605163141518161494337

and hex

Code:

d7ee6da182177c6be9cf2a14e6c41fb6a692663849f09cb947c3b27c6cdddeec

to get a public key, you simply multiply it (the starting point of the curve) by the scalar.  (You should watch a video on how exactly this is done, for example: https://www.youtube.com/watch?v=F3zzNa42-tQ

so then you get a point x,y , in my case

Code:

  x: 37429941216543900232094877115525389998977649641483690331264124109562838279185n,
  y: 30224260574053827691919187729967576172484851453209067507073176932097443187763n

Now you have an uncompressed and compressed public key, but really, you should never use uncompressed keys (due to them not working well with nested segwit et al?)

So to get the compressed public key, we look at y, and if it's odd, we add 0x02 in front of the x, otherwise 0x03,

so buffer x, append 0x02 if even, 0x03 if odd
and we get

Code:

0352c09891cd7fe1f9eed7776651805973986a9e8e6457e1095634ab72c8346411

Now to get this to an address we can perform a couple operations, for example for P2SH-P2WPKH we can do

we take the buffer of above compressed key

Code:

[
      3,  82, 192, 152, 145, 205, 127, 225,
    249, 238, 215, 119, 102,  81, 128,  89,
    115, 152, 106, 158, 142, 100,  87, 225,
      9,  86,  52, 171, 114, 200,  52, 100,
     17
]

RMD160SHA256 it.
 we get:

Code:

d9351dcbad5b8f3b8bfa2f2cdc85c28118ca9326

Then we create the redeemscript by adding 0x00 0x14 to the above result, and RDM160SHA256 it again.

Code:

7db6766dce18d816eaac1198391e8bdcf70b253a

now paste a prefix in front of it. for mainnet we use 0x05 so we get

Code:

057db6766dce18d816eaac1198391e8bdcf70b253a

calculate the checksum by double SHA256 hashing the redeemscript plus the added bytes, so we hash

Code:

057db6766dce18d816eaac1198391e8bdcf70b253a

result:

Code:

b3e8e9dd2be918e9bf078b4166180cae14a717be79d222debc3f8d50210f6596

& then take the first 4 bytes,
so

Code:

b3e8e9dd

add those to the back of the previous step, so we get

Code:

057db6766dce18d816eaac1198391e8bdcf70b253ab3e8e9dd

base58 the result ^ and you should get  

Code:

3D9iyFHi1Zs9KoyynUfrL82rGhJfYTfSG4

I came across Code enthousiast's topic half the way through, so definitely check that out as well. https://bitcointalk.org/index.php?topic=5229211.0

[Clegive8V]

Every address comes with a checksum. If you accidentally capitalise a character in the address, it'll not be valid.

I meant if you wrongly set up a valid address but you don't have a private key, or something like coin burn.
Is the only difference between these addresses is network byte?


It is more than I expected , I will read these comments again and try to understand it.

Small addition Can more than one valid address be generated from a private key?

Is knowing some private keys in HD wallets dangerous? Or sell wallet.dat files?

[BrewMaster]

Small addition Can more than one valid address be generated from a private key?

yes there are many different valid addresses that can be generated from a single public key (that is derived from a private key) like P2PKH, P2WPKH, P2SH-P2WPKH, P2SH (multisig), P2WSH (multisig),... each script hash can also contain different scripts with that same public key like P2PKH inside a P2SH.
read my comment again specifically the last paragraph.

Is knowing some private keys in HD wallets dangerous? Or sell wallet.dat files?

obviously yes!

[ranochigo]

I meant if you wrongly set up a valid address but you don't have a private key, or something like coin burn.
Is the only difference between these addresses is network byte?

No. Network byte is the distinguishing factor between different coins or mainnet/testnet. It affects the prefix of the address.

No. Bech32 in particular, only works for compressed public keys.

Bech32's address generation is particularly complicated (it involves extra steps after the RIPEMD160 hashing) and I don't think I'm the best person to explain it so I will leave it for someone else. The reference code is located here: https://github.com/sipa/bech32/tree/master/ref.

P2PWSH is just like how a P2SH address is created except the fact that there's a witness program being wrapped inside the redeem script.

Small addition Can more than one valid address be generated from a private key?

Other than what BrewMaster mentioned, each private key can be be used to generate a compressed and uncompressed address which could in turn yield two different addresses.

[BrewMaster]

No. Bech32 in particular, only works for compressed public keys.

this is a common misunderstanding of Bech32 SegWit addresses. the flags in bitcoin core policy that prevent transactions from spending a P2WPKH output that was created from an uncompressed public key are only standard flags which means you can create this address type from an uncompressed pubkey too.
but in practice since nearly all nodes and miners are already enforcing standard rules such funds sent to this type of address would be lost until a miner decides to make an exception.

[nc50lc]

Bech32's address generation is particularly complicated (it involves extra steps after the RIPEMD160 hashing) and I don't think I'm the best person to explain it so I will leave it for someone else. The reference code is located here: https://github.com/sipa/bech32/tree/master/ref.

Coding Enthusiast already did;
this is the link to his comprehensive guide: Step by step guide to go from public key to a Bech32 encoded address

Note: The replies seems to have more detailed information than the OP which looks like more of a visualization.

[Abdussamad]

there are so many questions smashed together here. so lets start from the beginning: creating a private key.
to create a new private key you have to choose a random number between 1 and N (which is a little smaller than 2^256 but lets skip that for now) you can't choose any arbitrary size bytes like 99 bytes, it needs to be close to the final size which is 32 bits otherwise you'll have to reduce it and it can create bias (which 99 bytes would).

A private key isn't 32 bits. That would be way too small. It's 256 bits.

[bob123]

Small addition Can more than one valid address be generated from a private key?

I assume you are talking about different address types?
If so, the answer is yes.

You can derive all P2PKH, P2SH and P2WPKH types from a single private key.

Is knowing some private keys in HD wallets dangerous? Or sell wallet.dat files?

Depends on whether we are talking about hardened (not dangerous; most common) or non-hardened derivation paths.
With non-hardened derivation paths, it is possible to derive the master private key by having access to a single child private key and the master public key.

But since most (all?) wallets are using hardened paths, this isn't an issue anymore.


Selling wallet.dat files? Well.. The buyer has to be stupid to do so.
Both people (buyer and seller) have access to the same seed and therefore the same private keys.

~snip~

A private key isn't 32 bits. That would be way too small. It's 256 bits.

It is quite obvious that he meant 32 bytes.

[o_e_l_e_o]

Depends on whether we are talking about hardened (not dangerous; most common) or non-hardened derivation paths.
With non-hardened derivation paths, it is possible to derive the master private key by having access to a single child private key and the master public key.

But since most (all?) wallets are using hardened paths, this isn't an issue anymore.

It is still an issue.

The standard derivation paths as defined by BIPs 44, 49, and 84 only use hardened keys for the first 3 levels of the derivation path - the purpose, the coin type, and the account. The change and the address index use non-hardened keys. As you say, knowing a child private key and the parent extended public key allow an attacker to derive all the child's sibling private keys.

In practice, this means that an attacker can't go any higher than the account they are in. Knowing the extended public key and a child private key from m/44'/0'/0' won't let them derive the keys from m/44'/0'/1' or m/84'/0'/0', for example. But knowing the extended public key and a child private key from m/44'/0'/0' will let them derive all the private keys from m/44'/0'/0'.