New Address each time for Ledger Nano

[expertschoice]

I have a balance of a few Bitcoin in my Ledger Nano.

I find my Ledger Nano Bitcoin "Deposit to" address and look it up on BlockChain Explorer and it shows NO Activity, zero balance.

Is this because the Nano generates a new address after each use of a present address?

Sorry, I'm a newbe.

H

[1713495923]

1713495923

[HCP]

Yes, by default, the ledger wallet will give you an "unused" address when you want a "deposit to" address. If you have had multiple transactions, your coins are most likely spread across multiple addresses.

If you want to see the addresses your coins are currently in, you would need to look at the individual transactions in your transaction history, and get the individual addresses from there.

[XXX_BTC1@]

I have a balance of a few Bitcoin in my Ledger Nano.

I find my Ledger Nano Bitcoin "Deposit to" address and look it up on BlockChain Explorer and it shows NO Activity, zero balance.

Is this because the Nano generates a new address after each use of a present address?

Sorry, I'm a newbe.

H

yes by default it can be generate new address. it has more secure so by default generating new address is really good to use. it can generate like that then no hack to this. so try to use once it is really it gives you more security.

[bob123]

I have a balance of a few Bitcoin in my Ledger Nano.
I find my Ledger Nano Bitcoin "Deposit to" address and look it up on BlockChain Explorer and it shows NO Activity, zero balance.
Is this because the Nano generates a new address after each use of a present address?
Sorry, I'm a newbe.

H

yes by default it can be generate new address. it has more secure so by default generating new address is really good to use. it can generate like that then no hack to this. so try to use once it is really it gives you more security.

Actually it does not really give you more security.
Security-wise its ok to use an address more than once. Its the privacy you want to protect with new addresses each transaction.
I dont understand what you mean with "it can generate like that then no hack" since there is no possible "hack" or whatever to addresses used more than once.

[Galahad]

I had the exact same problem. I couldn't figure out why the blockchain on the Ledger showed 2000 confirmations but blockchain.info had 0 and 0 balance.
But I don't see any settings for this as suggested here.

[coinomy.net]

Ledger Nano wallet changes the address each time I recieved BTC, but is it possible to use the same address again?
What happen if I send BTC to the address which is not shown right now, former address?
Is it still my address or can't recieve BTC with the old address?

[Lucius]

Ledger Nano wallet changes the address each time I recieved BTC, but is it possible to use the same address again?
What happen if I send BTC to the address which is not shown right now, former address?
Is it still my address or can't recieve BTC with the old address?

You can use one and the same address forever if you want to do that.An address that was once generated in your wallet always remains valid.Ledger Nano S is HD(hierarchical deterministic wallet) and for every transaction send/receive it create new address.This is only for your privacy,so if someone wants to keep track of your transactions and know how much coins you have, this option will in some ways protect your privacy.

[SirArthur]

Also don't forget that each time you send Bitcoins your "change address" also changes, so probably you don't even know it.

Let's say you've 5 BTC at address A and want to send 3 BTC to address B.
Bitcoin can't split coins off-chain, so it has to send the whole 5 BTC and the thing will go like this:

Input from address A of 5 BTC with 2 outputs:
3 BTC to address B
2 BTC to address C, where address C is another address from your wallet that, depending on your client, you may not know yourself.

And then if you send 1 BTC to address D, the process will be:

1 input from C of 2 BTC with two outputs:
1 BTC to D
1 BTC to E, where E is another change address.... and so on, and so on.

Despite these change addresses aren't shown to you, your software has the proper private keys.

[coinomy.net]

Thanks for the advice!!!
I wanted to use ledger nano address to withdraw from Hashflare, but if I change the wallet address, they don't send payout for 2 weeks.
So I thought I can't use ledger nano address for another payments, because if I use it, they change it.

So helpful this forum is.
Thanks so much.

[SirArthur]

Thanks for the advice!!!
I wanted to use ledger nano address to withdraw from Hashflare, but if I change the wallet address, they don't send payout for 2 weeks.
So I thought I can't use ledger nano address for another payments, because if I use it, they change it.

So helpful this forum is.
Thanks so much.

Your old address will remain attached to your wallet. So you can send how many times you want to that address.
It will provide you a new address, but the old ones remain there. Means you can use it for that you want.

[HCP]

People need to stop thinking of Bitcoin addresses as "account numbers"... it is not like a bank account where you only have one account number.

Hierarchical Deterministic (aka "HD") wallets can generate an unlimited number of addresses from a single "seed"... but just because they try to get you to use a new address for each transaction, it doesn't mean your old addresses have disappeared or will stop working.

A wallet is a "collection" of addresses... so you can continue to reuse old addresses from the same wallet and you'll still get your coins... it just isn't "recommended" for privacy reasons.

[NorrisK]

People need to stop thinking of Bitcoin addresses as "account numbers"... it is not like a bank account where you only have one account number.

Hierarchical Deterministic (aka "HD") wallets can generate an unlimited number of addresses from a single "seed"... but just because they try to get you to use a new address for each transaction, it doesn't mean your old addresses have disappeared or will stop working.

A wallet is a "collection" of addresses... so you can continue to reuse old addresses from the same wallet and you'll still get your coins... it just isn't "recommended" for privacy reasons.

Do you know what the impact is on transaction fees if you combine multiple outputs from multiple addresses compared to multiple outputs from a single address? Would there be a difference in transaction size if they originate from multiple addresses or is it only related to the number of incoming transactions that now need to be pooled?

[SirArthur]

Do you know what the impact is on transaction fees if you combine multiple outputs from multiple addresses compared to multiple outputs from a single address? Would there be a difference in transaction size if they originate from multiple addresses or is it only related to the number of incoming transactions that now need to be pooled?

Yes, it has an impact on the tx size, therefore you'll pay higher fees if you store small amounts through multiple addresses. Each address has an unique private key, those coins are associated to that private key, so each input has to be signed by it.
If you've 1 BTC stored through addresses A to J each with 0.1 BTC, when you send 1 BTC to someone it will have 10 inputs -> 1 output, making a much bigger tx in size than if you've 1 BTC at a single address.

The concerns of privacy on opposing end is that, if you have too many coins stored at a single address, you will undisclose your whole amount upon a tx.
If you've 1000 BTC at a single address and want to send 1 BTC to someone, it will cause 1 tx of 1 input (1000 BTC) and 2 outputs (1 BTC to whoever you're sending + 999 BTC returning to your change address) - ignoring fees on the examples.

[HCP]

Do you know what the impact is on transaction fees if you combine multiple outputs from multiple addresses compared to multiple outputs from a single address? Would there be a difference in transaction size if they originate from multiple addresses or is it only related to the number of incoming transactions that now need to be pooled?

It is only related to the number of inputs that are being "pooled". The number of addresses those UTXOs are spread across is irrelevant. So, everything else being equal, the fee for "Multiple outputs from multiple addresses" == the fee for "Same number of outputs from one address"

For instance:

Case A:
10 addresses, each one received 10x 0.01 BTC deposits... => (10 * 10 * 0.01) => 1 BTC total, over 100 UTXOs

Case B:
1 address, which has received 100x 0.01 BTC deposits => (1 * 100 * 0.01) => 1 BTC total, over 100 UTXOs

In both cases, if I want to send 1 BTC... I need to use 100 UTXOs, which creates 100 inputs... For "legacy" transactions, you're generally looking at around 148 bytes PER INPUT (assuming compressed addresses)... so your transaction is going to be overt 14,800 bytes!!

If fees are 100 sats/byte, you're looking at 1,480,000+ sats (or 0.0148+ BTC) in fees! Now imagine what that would be like if your wallet only had a total of 0.1 BTC in 100 UTXOs... you'd be spending 15% of your balance on fees!

Now imagine what it would be like if the fees were back at 500+ sats/byte!!?!


The trick to reducing transaction size (and therefore transaction fees) is to reduce the number of inputs... so if you had:

Case C:
10 addresses, each received 1x 0.1 BTC deposit => (10 * 1 * 0.1) => 1 BTC total, over only 10 UTXOs
&
Case D:
1 address, which has received 10x 0.1 BTC deposits => (1 * 10 * 0.1) => 1 BTC total, over only 10 UTXOs

In these cases, if you want to send 1 BTC... you only need to use 10 UTXOs, which means only 10 inputs... so your transaction is only going to be around 1480 bytes... and a potential saving of up to 13,200 bytes!

For the same fee rate of 100 sats/byte, you're now only looking at 148,000+ sats. And, as above, if you only had 0.1 BTC over 10 UTXOs, you'd now only be spending about 1.5% of your balance on fees... which is a lot more "acceptable"


TL;DR - Avoid collecting lots of small UTXOs (or try and merge them when fees are low, like they are now) to avoid incurring very large transaction fees later


NOTE: While the use of SegWit addresses will reduce the "size" of your transaction to some extent (thereby reducing the total fee paid), the general theory still holds... the more UTXOs (aka inputs) you "pool" into your transaction, the larger it is going to be... regardless of how many addresses those UTXOs are split across

Yes, it has an impact on the tx size, therefore you'll pay higher fees if you store small amounts through multiple addresses. Each address has an unique private key, those coins are associated to that private key, so each input has to be signed by it.
If you've 1 BTC stored through addresses A to J each with 0.1 BTC, when you send 1 BTC to someone it will have 10 inputs -> 1 output, making a much bigger tx in size than if you've 1 BTC at a single address.

That is only true if the 1 BTC at a single address is stored in 1 output... if that single address has received 10 deposits of 0.1 BTC (1 BTC Total), and you try to send 1 BTC, it will generate a transaction with the same size as using the 1 BTC (10 inputs) from addresses A to J.

The OP specifically asked about "multiple outputs from multiple addresses" versus "multiple outputs from a single address"

[maarx]

Do you know what the impact is on transaction fees if you combine multiple outputs from multiple addresses compared to multiple outputs from a single address? Would there be a difference in transaction size if they originate from multiple addresses or is it only related to the number of incoming transactions that now need to be pooled?

It is only related to the number of inputs that are being "pooled". The number of addresses those UTXOs are spread across is irrelevant. So, everything else being equal, the fee for "Multiple outputs from multiple addresses" == the fee for "Same number of outputs from one address"

For instance:

Case A:
10 addresses, each one received 10x 0.01 BTC deposits... => (10 * 10 * 0.01) => 1 BTC total, over 100 UTXOs

Case B:
1 address, which has received 100x 0.01 BTC deposits => (1 * 100 * 0.01) => 1 BTC total, over 100 UTXOs

In both cases, if I want to send 1 BTC... I need to use 100 UTXOs, which creates 100 inputs... For "legacy" transactions, you're generally looking at around 148 bytes PER INPUT (assuming compressed addresses)... so your transaction is going to be overt 14,800 bytes!!

If fees are 100 sats/byte, you're looking at 1,480,000+ sats (or 0.0148+ BTC) in fees! Now imagine what that would be like if your wallet only had a total of 0.1 BTC in 100 UTXOs... you'd be spending 15% of your balance on fees!

Now imagine what it would be like if the fees were back at 500+ sats/byte!!?!


The trick to reducing transaction size (and therefore transaction fees) is to reduce the number of inputs... so if you had:

Case C:
10 addresses, each received 1x 0.1 BTC deposit => (10 * 1 * 0.1) => 1 BTC total, over only 10 UTXOs
&
Case D:
1 address, which has received 10x 0.1 BTC deposits => (1 * 10 * 0.1) => 1 BTC total, over only 10 UTXOs

In these cases, if you want to send 1 BTC... you only need to use 10 UTXOs, which means only 10 inputs... so your transaction is only going to be around 1480 bytes... and a potential saving of up to 13,200 bytes!

For the same fee rate of 100 sats/byte, you're now only looking at 148,000+ sats. And, as above, if you only had 0.1 BTC over 10 UTXOs, you'd now only be spending about 1.5% of your balance on fees... which is a lot more "acceptable"


TL;DR - Avoid collecting lots of small UTXOs (or try and merge them when fees are low, like they are now) to avoid incurring very large transaction fees later


NOTE: While the use of SegWit addresses will reduce the "size" of your transaction to some extent (thereby reducing the total fee paid), the general theory still holds... the more UTXOs (aka inputs) you "pool" into your transaction, the larger it is going to be... regardless of how many addresses those UTXOs are split across

Yes, it has an impact on the tx size, therefore you'll pay higher fees if you store small amounts through multiple addresses. Each address has an unique private key, those coins are associated to that private key, so each input has to be signed by it.
If you've 1 BTC stored through addresses A to J each with 0.1 BTC, when you send 1 BTC to someone it will have 10 inputs -> 1 output, making a much bigger tx in size than if you've 1 BTC at a single address.

That is only true if the 1 BTC at a single address is stored in 1 output... if that single address has received 10 deposits of 0.1 BTC (1 BTC Total), and you try to send 1 BTC, it will generate a transaction with the same size as using the 1 BTC (10 inputs) from addresses A to J.

The OP specifically asked about "multiple outputs from multiple addresses" versus "multiple outputs from a single address"

The trasactions as well is delayed when there is a multiple inputs to the same address from differenct out put addresses. These issues do occure with all the wallets? or with any particular wallets? I had to face this issue when transacting btc from coinbase address to localbitcoin address. Every bitcoin wallet generates a new address once a trasaction is complete on the old address. This is to keep the account so secured from hackers attacks.

[HCP]

The trasactions as well is delayed when there is a multiple inputs to the same address from differenct out put addresses. These issues do occure with all the wallets? or with any particular wallets?

Transactions are not "delayed" by having multiple inputs... they simply have a larger "data" size (NOTE: this is NOT related to the value of the bitcoin being transacted)...

It also doesn't matter if it is multiple inputs from different output addresses or multiple inputs from one address. The issue is just "multiple inputs".

And this is simply a fact of the way Bitcoin works... so it will affect ALL bitcoin wallets.

I had to face this issue when transacting btc from coinbase address to localbitcoin address. Every bitcoin wallet generates a new address once a trasaction is complete on the old address.

That is incorrect. Not ALL bitcoin wallets generate new addresses. Paper wallets obviously cannot generate a new address... and a lot of "older" wallets, which are still functional do not generate new addresses... and you can even create a wallet in Electrum by importing a single private key that will NEVER create new addresses.

Granted, the majority of "new" wallets tend to be HD (Hierarchical Deterministic) that DO generate new addresses... but not ALL.

This is to keep the account so secured from hackers attacks.

No... generating new addresses achieves pretty much NOTHING from a security perspective[1]. It is simply a way to try and prevent address re-use to help protect PRIVACY... both yours and anyone who transacts with you.