Wallets Addresses per private key

[IAM_AWAK3]

Hey, I'm newish to BITCOIN. At first I was under the assumption that you would generate your PRIVATE and PUBLIC key and use those to create numerous wallet addresses, but I was told that it doesn't work like that. I'll give you some background basically I'm trying to handle payments, do I need to create a new set of KEYS for each payment then once its goes through transfer the money to my main wallet, or am I wrong and I can have numerous wallet addresses.

Thanks.

[PrimeNumber7]

You generate a private key with randomness, and you use the private key to calculate the public key. In other words, your private key can be described as a random number, while your public key is a derivative of your private key.

You are correct, you should generate a new set of keys for each time you receive bitcoin.

It would probably be best in most cases to use a deterministic wallet to generate your keys. You would create a 'master' private key that is used to calculate an unlimited number of private keys, and those private keys can be used to calculate each public key. This makes backing up your keys much easier, and you will have effectively pre-generated all your keys at once.

[IAM_AWAK3]

Thanks, I'll take a look at it.

[o_e_l_e_o]

I'll give you some background basically I'm trying to handle payments, do I need to create a new set of KEYS for each payment then once its goes through transfer the money to my main wallet, or am I wrong and I can have numerous wallet addresses.

If you set up your own wallet using something like Bitcoin Core or Electrum, then you will be able to generate as many addresses as you want. Each address will have its own public key and private key, but your wallet software will handle all this for you. You can give out a new and unique address to each customer who is trying to pay you. This lets you easily track which payments are coming from which customer, as opposed to all the payments just arriving at the same address.

Once you have received a number of payments, then you can move them all to your main wallet in one single transaction. Moving them altogether like this rather than individually will save you on fees as well as consolidate them all in to one input, which will save you even more on fees down the line.

[PrimeNumber7]

Once you have received a number of payments, then you can move them all to your main wallet in one single transaction. Moving them altogether like this rather than individually will save you on fees as well as consolidate them all in to one input, which will save you even more on fees down the line.

Doing this will reduce privacy for the OP because all of his incoming transactions will be associated with each other. It will also be more expensive in terms of total transaction fees he pays because he is paying transaction fees to send bitcoin to himself.

[o_e_l_e_o]

Doing this will reduce privacy for the OP because all of his incoming transactions will be associated with each other.

It will also reduce the privacy for his customers since each customer could look at other customer's payments, if they were so inclined. However, it is still how most services which take payments from multiple customers, be that merchants, casinos, exchanges, etc. operate.

It will also be more expensive in terms of total transaction fees he pays because he is paying transaction fees to send bitcoin to himself.

I would disagree with that. The bitcoin he receives is going to have to be moved somewhere eventually, whether that is to an exchange to sell for fiat, to a merchant to buy goods or services, or somewhere else. If he doesn't consolidate all his received payments, then he must make an individual transaction for each one which will be much more expensive. His other option would be to consolidate his payments directly when he moves coins to an exchange/merchant/etc., but then will be paying whatever the current fee rate is for the large consolidation payment, when he could instead pay 1 sat/vbyte to consolidate his payments when the mempool is empty.

[nc50lc]

Hey, I'm newish to BITCOIN. At first I was under the assumption that you would generate your PRIVATE and PUBLIC key and use those to create numerous wallet addresses, but I was told that it doesn't work like that. -snip-

Perhaps you had been remembering the wrong term.
Based from your previous assumption, it looks like you're thinking about "Master Private Key" and "Master Public Key".
With the Master Public key in your website lets say a "merchant wallet", it'll be able to produce a numerous amount of addresses that the Master Private key in your main wallet can also create.

Here's an example usage: https://electrum.readthedocs.io/en/latest/merchant.html

-snip- I'll give you some background basically I'm trying to handle payments, do I need to create a new set of KEYS for each payment then once its goes through transfer the money to my main wallet, or am I wrong and I can have numerous wallet addresses.

Most HD (hierarchical deterministic) wallets keep a "keypool" which contains a number of private keys (and their pairs) derived from the master key. The number is usually set by the client by default or by the user.
Plus mostly all clients handles the generation of the next batch of addresses when needed, automatically.

In short: Yes, you can have numerous addresses as many as the client can handle.

[PrimeNumber7]

It will also be more expensive in terms of total transaction fees he pays because he is paying transaction fees to send bitcoin to himself.

I would disagree with that. The bitcoin he receives is going to have to be moved somewhere eventually, whether that is to an exchange to sell for fiat, to a merchant to buy goods or services, or somewhere else. If he doesn't consolidate all his received payments, then he must make an individual transaction for each one which will be much more expensive. His other option would be to consolidate his payments directly when he moves coins to an exchange/merchant/etc., but then will be paying whatever the current fee rate is for the large consolidation payment, when he could instead pay 1 sat/vbyte to consolidate his payments when the mempool is empty.

I was not suggesting that the OP not spend for example 3 inputs in one transaction if he optimally needs to spend those three inputs to pay for what he needs to pay for. The OP needs to pay for block space for each input in any transaction he wants to be confirmed.

If the OP has 10 unspent outputs and consolidates the outputs, he will need to pay for 10 inputs to consolidate the outputs, plus one for when he spends the consolidated output. If the OP does not consolidate his outputs, he will only need to pay for 10 inputs.

You do make a fair point that consolidating outputs with a very low fee may save on transaction fees. This may be true historically, however it is always possible that market transaction fee rates will never be as high as they are when the OP consolidates his outputs.