How to generate Bitcoin Address?

[realdos]

I understand that to create a bitcoin address, one has to have a private ECDSA key first. What I don't know is how to take the corresponding public key generated with it. Are the private/public keys of ECDSA generated at the same time? Or is there any algorithm for us to calculate the public key based on the private one?

[kjj]

The private key is a random 256 bit number.  Every 256 bit number is a private key, but some are safer than others.  You should use the strongest entropy source that you can get your hands on to generate them.

The public key is then simply pubkey = G * PrivKey.  The catch is that * is EC multiplication in the appropriate modular elliptic curve field and G is the base point of that curve.

From there, it is just a matter of hashing and encoding to generate the address.

All of this is well published.  Would you like some tips on searching?

[realdos]

The private key is a random 256 bit number.  Every 256 bit number is a private key, but some are safer than others.  You should use the strongest entropy source that you can get your hands on to generate them.

The public key is then simply pubkey = G * PrivKey.  The catch is that * is EC multiplication in the appropriate modular elliptic curve field and G is the base point of that curve.

From there, it is just a matter of hashing and encoding to generate the address.

All of this is well published.  Would you like some tips on searching?

Yes, plz. I'm quite interested in this and would like to know more.. please show me some keywords on the searching..

[Stephen Gornick]

Yes, plz. I'm quite interested in this and would like to know more.

 - http://bitcoin.stackexchange.com/q/4675/153
 - http://bitcoin.stackexchange.com/q/3041/153\
 - http://bitcointalk.org/index.php?topic=78132.0
 - http://github.com/weex/addrgen
 - http://bitcointalk.org/index.php?topic=187269.msg1939621#msg1939621

[realdos]

The private key is a random 256 bit number.  Every 256 bit number is a private key, but some are safer than others.  You should use the strongest entropy source that you can get your hands on to generate them.

The public key is then simply pubkey = G * PrivKey.  The catch is that * is EC multiplication in the appropriate modular elliptic curve field and G is the base point of that curve.

From there, it is just a matter of hashing and encoding to generate the address.

All of this is well published.  Would you like some tips on searching?

a small gift of 0.02btc has been sent to your address for your help..

[realdos]

Yes, plz. I'm quite interested in this and would like to know more.

 - http://bitcoin.stackexchange.com/q/4675/153
 - http://bitcoin.stackexchange.com/q/3041/153\
 - http://bitcointalk.org/index.php?topic=78132.0
 - http://github.com/weex/addrgen
 - http://bitcointalk.org/index.php?topic=187269.msg1939621#msg1939621

thanks..would you give me your bitcoin address?

[jp]

I wrote on article on how to create a Bitcoin Address with JavaScript. It's very in depth, and explains step by step the entire process. Hopefully it helps.

[phatsphere]

Every 256 bit number is a private key,…

nitpicking mode: that's not true. there is a very very very small range of numbers, which do not lift properly on the underlying elliptic curve.

[jackjack]

Every 256 bit number is a private key,…

nitpicking mode: that's not true. there is a very very very small range of numbers, which do not lift properly on the underlying elliptic curve.

nitpicking mode: that's not true. They perfectly lift on the EC, it's just that their resulting public key are shared by two private keys from the range [0,2^256-1].
But as we're using Bitcoin addresses and not public keys, each address is shared by 2^96 private keys anyway so I'm rather sure that one more won't change anything...

[jp]

Every 256 bit number is a private key,…

nitpicking mode: that's not true. there is a very very very small range of numbers, which do not lift properly on the underlying elliptic curve.

nitpicking mode: that's not true. They perfectly lift on the EC, it's just that their resulting public key are shared by two private keys from the range [0,2^256-1].
But as we're using Bitcoin addresses and not public keys, each address is shared by 2^96 private keys anyway so I'm rather sure that one more won't change anything...

@jackjack, you should read my article @phatsphere is correct. Almost every 256 bit number could be a private key, but according to the secp256k1 curve parameters used by Bitcoin, any number in the range of 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1 could be a private key.

[jackjack]

Every 256 bit number is a private key,…

nitpicking mode: that's not true. there is a very very very small range of numbers, which do not lift properly on the underlying elliptic curve.

nitpicking mode: that's not true. They perfectly lift on the EC, it's just that their resulting public key are shared by two private keys from the range [0,2^256-1].
But as we're using Bitcoin addresses and not public keys, each address is shared by 2^96 private keys anyway so I'm rather sure that one more won't change anything...

@jackjack, you should read my article @phatsphere is correct. Almost every 256 bit number could be a private key, but according to the secp256k1 curve parameters used by Bitcoin, any number in the range of 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1 could be a private key.

And I think you should read my post. Phatsphere said that numbers above n doesn't lift on (I figured this means 'fit in') the EC. I said they do, and they do. Even G^gogolplex does.
By the way you can always come back to a private key between 1 and n-1 from whatever number (except those in n obviously).

[kjj]

Every 256 bit number is a private key,…

nitpicking mode: that's not true. there is a very very very small range of numbers, which do not lift properly on the underlying elliptic curve.

nitpicking mode: that's not true. They perfectly lift on the EC, it's just that their resulting public key are shared by two private keys from the range [0,2^256-1].
But as we're using Bitcoin addresses and not public keys, each address is shared by 2^96 private keys anyway so I'm rather sure that one more won't change anything...

@jackjack, you should read my article @phatsphere is correct. Almost every 256 bit number could be a private key, but according to the secp256k1 curve parameters used by Bitcoin, any number in the range of 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1 could be a private key.

It is a modular field.  Numbers bigger than the field order are still keys, just shitty keys.

[MattTau]

Every 256 bit number is a private key,…

nitpicking mode: that's not true. there is a very very very small range of numbers, which do not lift properly on the underlying elliptic curve.

nitpicking mode: that's not true. They perfectly lift on the EC, it's just that their resulting public key are shared by two private keys from the range [0,2^256-1].
But as we're using Bitcoin addresses and not public keys, each address is shared by 2^96 private keys anyway so I'm rather sure that one more won't change anything...

@jackjack, you should read my article ;) @phatsphere is correct. Almost every 256 bit number could be a private key, but according to the secp256k1 curve parameters used by Bitcoin, any number in the range of 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1 could be a private key.

I'm just starting to try and understand the inner workings of bitcoin, so please excuse my ignorance.  When I use a random number in the above mentioned range, it seems like about 50% of the time I get a key that can not be used to sign messages. The error is that the signature could not construct a recoverable key.  Is this to be expected, and I need to test my random keys for this condition before using them?  It is an error in the code I'm referencing (I'm using litecoinj as my reference because I'm most comfortable in Java)?

Here is a sample of some of the bad keys I've run across:

Code:

import java.math.BigInteger;
import com.google.bitcoin.core.ECKey;

public class ECKeyPairTest {

	public static void main(String[] args) {
		String txt = "testing testing 123";

		BigInteger[] errors = new BigInteger[]{
				new BigInteger("6c8fbf6dd62d856e3f8e8993224514e8ee85b4756f120d815dcb402bb2303fcf", 16),
				new BigInteger("0d246f6c837761942350e7316d21b48c14f2c3f5d2880c1e1adeff521d7495bb", 16),
				new BigInteger("d628aeec2ad502840fa4b713fb89d1f3cd3b0e88820a913ca850bf62a4a48a5f", 16),
				new BigInteger("50c2d4262e96bbee3572b54e7b24172dcf7f88e3727d8c8536c2b1a2716489d4", 16),
				new BigInteger("32d2b2ea40e6bb360c8bced87ff0a234f372eb8e997b1c6ee5d6c3d7712f9826", 16),
				new BigInteger("0d1c709622f19433e7174049694dd1a5cb459a8eb9b8a52c2dbeb09f26dc4dc3", 16),
				new BigInteger("29b02e548291c07a3bb0fb086a4115220be1040649886e31c48a3b60bbbdc31f", 16),
				new BigInteger("2a4f3fb204abad5db78f157a4c7315f12b9b4c31a9956ceed7fcd59a0aaaff0f", 16),
				new BigInteger("2f4854b1af29cde02ef0bbcb3c1d93c1e33a745a442a31962e3e854c60cd894a", 16),
				new BigInteger("f725e77b326b8400842009a41c63d2b5657c26fc870dd0db647a4f0f5fe482e6", 16),
				new BigInteger("e8d0c60007408acd56de8d7b885ee7e9308107f1fa5fcead6f422a2dbccb2cb4", 16),
				new BigInteger("e1fbd323024ea8e05a859464c26368d0921ddd17c15d0c4fc2902dde8ffb1abd", 16)
		};

		int errCnt = 0;
		for (BigInteger err : errors)
		{
			try {
				ECKey x = new ECKey(err);
				String sig = x.signMessage(txt);
				x.verifyMessage(txt, sig);
			} catch (Exception e) {
				errCnt++;
				e.printStackTrace();
			}
		}

		System.out.println("errCnt: " + errCnt + "/" + errors.length);
	}
}

[TookDk]

What options are there to redeem the balance associated to a private key?

I use primarily bitcoin-QT wallet, but I don't believe that QT can import private keys?

The only other "offline" solutions that I have found (and is comfortable with) is Mycelium.

If we exclude the online wallets solutions, what applications can you recommend?
  

[DannyHamilton]

IMPORTANT NOTE: If you import a private key, you should consider that key to no longer be "secure".  If you want to maintain any portion of the balance that was originally at the private key on a "paper wallet" (printed private key), then you should create a new one and send the intended portion there. Importing and exporting private keys is an advanced function of Bitcoin and you can permanently lose your bitcoins if you make a false assumption about how it works.  For example, if you import a private key, and then spend a small portion of the funds of the private key with the Bitcoin-Qt wallet, Bitocin-Qt will have moved the remaining balance to a new private key that it keeps hidden from you.  It will no longer be at the original private key.  If you don't realize this and you delete the wallet.dat (thinking you can re-import the private key again later) your bitcoins will be permanently lost.

What options are there to redeem the balance associated to a private key?

I use primarily bitcoin-QT wallet, but I don't believe that QT can import private keys?

It can.  It is an advanced function that is not part of the user interface.

Under the "Help" menu choose "Debug Window"

In the "Debug Window" select the "Console"

In the console you can type a command:

Code:

importprivkey yourPrivateKey

Where yourPrivateKey is the private key that you want to import.

If your wallet is passphrase protected, you will probably have to unlock the wallet before you issue the "importprivkey" command.  You can do this with the following command in the "Console":

Code:

walletpassphrase \"yourPassPhrase\" ###

Where yourPassPhrase is the passphrase you used to encrypt your wallet, and ### is the number of seconds that you'd like the wallet to remain unlocked (perhaps use 300, which would allow you 5 minutes to enter the importprivkey command).

The importprivkey command will at first appear to do nothing and will seem to freeze up the wallet program for a few minutes.  This is because after adding the private key to the wallet, it must scan the entire blockchain for every instance that the associated address received any bitcoins as well as any instance where those bitcoins were spent.  After several minutes the wallet balance will update with any balance from the imported private key, and the wallet will become usable again.  You will might find the imported bitcoin address in the "Addresses" section instead of the "Received" section of your wallet.  If so, give the address a label in the "Addresses" section and the wallet should move the address over to the "Received" section.

The only other "offline" solutions that I have found (and is comfortable with) is Mycelium.

If we exclude the online wallets solutions, what applications can you recommend?  

Armory, Electrum, and MultiBit are all also capable of importing a private key.  Another option would be to create a temporary blockchain.info/wallet (they take less than 5 minutes to create) and sweep the private key into that wallet.  Then you can immediately use the blockchain.info/wallet to send the entire balance to any offline wallet you like.

[TookDk]

Thank you so much DannyHamilton.

I was not aware that QT can do that.
That is really awesome, because QT is really my favorite wallet.
I will try do a few test with importing a private key with a small balance.
I assume that the key will be added to wallet.dat, once imported right?

I have tried importing private keys with blockchain.info/wallet, its pretty cool, you can also use a webcam to read QR code (If I remember correctly).
I have also tried importing private key through mtgox last year, it worked pretty well too.
But I have super paranoia when it comes to only online wallets when handling more that a few santoshi, so QT is ideal for me.   

I would like to send you a small tip for your detailed explanation, what is your tip adr. ?

[DannyHamilton]

Thank you so much DannyHamilton.

I was not aware that QT can do that.
That is really awesome, because QT is really my favorite wallet.
I will try do a few test with importing a private key with a small balance.
I assume that the key will be added to wallet.dat, once imported right?

I have tried importing private keys with blockchain.info/wallet, its pretty cool, you can also use a webcam to read QR code (If I remember correctly).
I have also tried importing private key through mtgox last year, it worked pretty well too.
But I have super paranoia when it comes to only online wallets when handling more that a few santoshi, so QT is ideal for me.   

I would like to send you a small tip for your detailed explanation, what is your tip adr. ?

I choose to use a new address for every transaction.  Therefore, I don't have a published "tip address".  I'll send you an address that you can use for this tip.  Don't re-use the address in the future, if you ever have another reason to send me bitcoins.  Once I spend the bitcoins that are received at an address, I discard the private key and will no longer be able to access additional bitcoins that are sent to the same address.

[dbwilkins]

I'm new to this topic. Can anybody explane me why we need both private and public keys?

[DannyHamilton]

I'm new to this topic. Can anybody explane me why we need both private and public keys?

private key is used to create the digital signature.

public key is used to check that a digital signature is valid.

[Stevets]

I'm new to this topic. Can anybody explane me why we need both private and public keys?

Imagine a whole bunch of uniquely numbered vaults with a slot that anybody can drop money in. The vaults are clear so you can see how much money is in them but the only way to get the money out is by knowing the combination to it's lock. The public key is the number of the vault and the private key is the combination for it's lock.

That is a stupid oversimplification but it is the way I think about it.