btc wallet features

[bit9999]

Hey guys,

A few questions about common bitcoin wallet functions:

1. if i have a wallet but forget the passphrase, i cannot recover the passphrase or gain access to the private keys unless i have printed them out?

2. If a wallet generates many addresses, and I use a new address for each new deposit. How do I manage all the small deposits on different addresses? If I send certain amount of btcs from this wallet, it will automatically deduct coins from multiple addresses? And in which order?

3. I heard when sending btc out, each used address's btc will all go out and then the changes will go back to a new address in the wallet. If this is true, the wallet will auto recognize / create a new btc address and pre-determine a deposit address in the wallet before sending btc out?

4. One btc wallet can generate unlimited amount of btc address (private keys)? Which btc wallet do you recommend to use to generate a large amount of btc addresses offline?

[1714777067]

1714777067

[1714777067]

1714777067

[1714777067]

1714777067

[DannyHamilton]

Hey guys,

A few questions about common bitcoin wallet functions:

1. if i have a wallet but forget the passphrase, i cannot recover the passphrase or gain access to the private keys unless i have printed them out?

That depends on how complex and random your passphrase is.

If you choose a secure passphrase, then you are correct. If you are unable to remember your passphrase, and you haven't recorded in any way, then you won't be able to recover it.

2. If a wallet generates many addresses, and I use a new address for each new deposit. How do I manage all the small deposits on different addresses?

Typically, you don't.  The wallet manages them for you.  If you want to manage them yourself, then you'd need to choose a wallet that provides "coin control" features.

If I send certain amount of btcs from this wallet, it will automatically deduct coins from multiple addresses?

That's not how bitcoin works.  Bitcoin doesn't "deduct" from an account.  Bitcoin spends unspent outputs and creates new unspent outputs.

However, as a user if you are unfamilliar with the technical details of how bitcoin works it will generally look like amounts have been "deducted from multiple addresses".

And in which order?

There are no rules about that for bitcoin.  Each wallet implements their own algroithm for choosing outputs to spend.

3. I heard when sending btc out, each used address's btc will all go out and then the changes will go back to a new address in the wallet.

That will depend on whether you have used a new address for every transaction or not, and which wallet you use.

The wallet will choose payments that you have received and spend the entire payment.  If you only ever received 1 payment at the address, then the "address's btc will all go out".  If you received more than 1 payment at the address, then the wallet might only choose to spend some of those payments, leaving behind some of the others.

If this is true, the wallet will auto recognize / create a new btc address and pre-determine a deposit address in the wallet before sending btc out?

Yes.  When you use a properly written wallet that uses unique change addresses, then the wallet generates the change addresses for you and keeps track of them internally.

4. One btc wallet can generate unlimited amount of btc address (private keys)?

Effectively in human terms, yes, it can generate as many addresses and private keys as you will ever need.

If we are talking literally though, the number is "limited".  Using the current P2PKH address scheme for bitcoin, there can't be more than 1.47 X 10⁴⁸ addresses.

Which btc wallet do you recommend to use to generate a large amount of btc addresses offline?

That depends on how you intend to use the addresses. Ethereum would might be a good choice.  If I really needed thousands or millions of addresses, then I'd probably write my own program to handle it.  Most of the popular and well supported wallets aren't really designed for that use case.

[bit9999]

If this is true, the wallet will auto recognize / create a new btc address and pre-determine a deposit address in the wallet before sending btc out?

Yes.  When you use a properly written wallet that uses unique change addresses, then the wallet generates the change addresses for you and keeps track of them internally.

So we are totally relying on bitcoin wallets to spend bitcoins? And each time we make a payment, we need to back up a new private key and the old private key will become useless?

In this case, for each transaction we have to perform a backup? For people with paper wallets, if they decide to spend the coins, each time they make a transaction, they need to print out the new keys and store them?

For multi-sign keys, each time we spend balance on that address, we also need to produce and distribute multiple private keys to different ppl?

[DannyHamilton]

So we are totally relying on bitcoin wallets to spend bitcoins?

While it is technically possible to create and sign a bitcoin transaction without any software at all (just pen and paper), it would be a difficult and extremely time-consuming thing to do.  So, yes, we are generally totally relying on wallet software to create transactions for us.

And each time we make a payment, we need to back up a new private key and the old private key will become useless?

In this case, for each transaction we have to perform a backup?

That depends on the wallet that you are using. Most well written modern wallets use a system called "Hierarchical Deterministic" (or HD).  This allows the wallet to generate a random seed value when it is first installed, and then to use that seed to generate all of its private keys in a deterministic way.  You can just back up that seed once when you first start up the wallet, and if you every need recover, the wallet can rebuild ALL of the exact same private keys that it ever used from that same seed.   

Some older wallets would pre-generate a batch of private keys that it was going to use in the future, and include those generated-but-unused private keys in the "wallet file" that users would back up.  That way, the user wouldn't need to back up as often.  As long as they hadn't used up all the pre-generated keys yet, recovery of an old backup could still recover all the keys that they recently used.

However, if the wallet you are using isn't a HD wallet, and it doesn't pre-generate keys for you then yes, you would need to back up each time you make a payment.

For people with paper wallets, if they decide to spend the coins, each time they make a transaction, they need to print out the new keys and store them?

Correct.  This is why paper wallets are used as "cold storage" for long term storage of bitcoins that won't be used in the near future.  It is a hassle to have to create a new paper wallet every time you create a transaction, but it is not a hassle to put the paper in a safe and leave it there untouched for a few years.

Occasionally someone doesn't understand this need to create a new paper wallet, and they permanently lose some of their bitcoins. I've had to explain this to more than one user after they made that mistake.

For multi-sign keys, each time we spend balance on that address, we also need to produce and distribute multiple private keys to different ppl?

With Multi-Sig, people should be generating their own keys.  They shouldn't be trusting someone else to generate a key for them. That would destroy the security of the multi-sig (since the person that creates the keys could secretly keep a copy for themselves without anybody knowing).

Just like you CAN re-use a non-multiSig address in bitcoin if you want to (even though it is not recommended), each participant in a multi-sig transaction also CAN re-use their key if they want to (even though it is not recommended).

You could build the transacitons using keys from a HD wallet, in which case the user would only need to supply you the master public key, and you could generate the additional public keys as needed.

[bit9999]

Hey Danny,

Thanks for the explanation. If I have 10 address with a total amount of 1 btc. When I try to send total 1 btc to another address, will it cost me more network fee than me sending it out from one address which contains 1 btc?

For sending to multiple address, what wallet is the best choice for us to package the multiple transactions into one to save the most network fee?

[HCP]

Given that network fees are variable... it may not necessarily result in a larger fee if you have 10 inputs making up your 1 BTC, as opposed to 1 input making up your 1 BTC. What WILL happen is that your transaction will be nearly 10 times as large.

10x 148 bytes vs 1x 148 bytes... As fees "should" be calculated on a "satoshis per byte" basis... all other things being equal... a transaction with 10 inputs is likely to need 9 to 10 times the TOTAL fee to achieve the same fee rate (for example, 100 sats/byte = 148,000 sats TOTAL for 1480 bytes, vs 14,800 sats TOTAL for 148 bytes).

Also, NOTE: that the transaction size isn't based on the number of addresses... it is based on the number of INPUTS. 10 addresses with 1 input each... or 1 address with 10 inputs... either way it is still 10 inputs.

It's not like a fiat bank account... you don't put ten separate 0.1 BTC inputs in BitcoinAddressA and you magically have 1x 1 BTC input in BitcoinAddressA... you still end up with 10 separate inputs!

[bit9999]

Given that network fees are variable... it may not necessarily result in a larger fee if you have 10 inputs making up your 1 BTC, as opposed to 1 input making up your 1 BTC. What WILL happen is that your transaction will be nearly 10 times as large.

10x 148 bytes vs 1x 148 bytes... As fees "should" be calculated on a "satoshis per byte" basis... all other things being equal... a transaction with 10 inputs is likely to need 9 to 10 times the TOTAL fee to achieve the same fee rate (for example, 100 sats/byte = 148,000 sats TOTAL for 1480 bytes, vs 14,800 sats TOTAL for 148 bytes).

Also, NOTE: that the transaction size isn't based on the number of addresses... it is based on the number of INPUTS. 10 addresses with 1 input each... or 1 address with 10 inputs... either way it is still 10 inputs.

It's not like a fiat bank account... you don't put ten separate 0.1 BTC inputs in BitcoinAddressA and you magically have 1x 1 BTC input in BitcoinAddressA... you still end up with 10 separate inputs!

let's assume wallet A contains ten btc addresses with each address contains 0.1 btc, for a total of 1 btc. wallet B contains 10 btc addresses but only one btc address contains 1 btc; others have zero balance. Now if i want to send 1 btc to another address, the fees for sending from wallet A will be much greater than fees required for sending from wallet B?

Also, I believe if we want to send different amount of btcs to 100 different addresses, if we do it in one transaction can save more network fees than doing them one by one. However, bitcoin core and electrum may handle this 'sendmany' function differently internally, resulting in different fees. I am in search of a wallet with its 'sendmany' function that will result in least fees

[DannyHamilton]

let's assume wallet A contains ten btc addresses with each address contains 0.1 btc, for a total of 1 btc. wallet B contains 10 btc addresses but only one btc address contains 1 btc; others have zero balance. Now if i want to send 1 btc to another address, the fees for sending from wallet A will be much greater than fees required for sending from wallet B?

That depends on how those bitcoins were received.

If wallet B received 20 payments of 0.05 BTC all to that same address, then wallet B has 20 unspent outputs that it needs to spend.  This means that the fees for spending from wallet B will be much greater than the fees required for sending from wallet A.

If wallet B received only 1 payment of 1.0 BTC to that address, then wallet B has only 1 unspent output that it needs to spend.  This means that the fees for spending from wallet A will be much greater than the fees required for sending from wallet B.

The size (in bytes) of a bitcoin transaction is not effected by the number of addresses you are using, it is effected by the number of unspent outputs you have.

Also, I believe if we want to send different amount of btcs to 100 different addresses, if we do it in one transaction can save more network fees than doing them one by one.

Correct.

However, bitcoin core and electrum may handle this 'sendmany' function differently internally,

I don't think that they do.

resulting in different fees.

Each wallet is making its best effort to try and guess how busy the bitcoin network is at the moment and suggest a fee-per-byte that it thinks is reasonable right then. So, Bitcoin Core and Electrum might be suggesting slightly different fees.  Sometimes Bitcoin Core might suggest a higher fee, and sometimes Electrum might suggest a higher fee.  There is no single "cheapest fee" wallet.

I am in search of a wallet with its 'sendmany' function that will result in least fees

I'm not an expert with Electrum, but with Bitcoin Core you can manually set the fees to whatever amount you want. If you don't like the suggested fee, just set a lower one. However, if you set them too low, the miners and peer nodes might ignore your transaction and refuse to confirm it if you don't set a high enough fee.

[bit9999]

That depends on how those bitcoins were received.

If wallet B received 20 payments of 0.05 BTC all to that same address, then wallet B has 20 unspent outputs that it needs to spend.  This means that the fees for spending from wallet B will be much greater than the fees required for sending from wallet A.

If wallet B received only 1 payment of 1.0 BTC to that address, then wallet B has only 1 unspent output that it needs to spend.  This means that the fees for spending from wallet A will be much greater than the fees required for sending from wallet B.

The size (in bytes) of a bitcoin transaction is not effected by the number of addresses you are using, it is effected by the number of unspent outputs you have.

If we have 10 unspent outputs in a wallet, instead of sending to one address, if it sends to 10 different addresses, the fee will also be much greater?


If we have different addresses in a wallet with different amount of unspent outputs, the choice of which output to be spent choosing by the wallet will affect the size of the transaction?

[DannyHamilton]

If we have 10 unspent outputs in a wallet, instead of sending to one address, if it sends to 10 different addresses, the fee will also be much greater?

The fee is the same on a "per byte" basis regardless of how many addresses, inputs, or outputs you have.  What changes is how many bytes it takes to create the transaction.

Creating a transaction requires approximately 10 bytes to start with. Then, each unspent output that you use as an input to fund the transaction adds approximately 149 bytes.  Each new unspent output that you create (each recipient that you send to) adds 34 bytes.

So, if you pay a fee of 0.00000100 BTC per byte, and you spend (use as inputs) 3 unspent outputs to send to 4 addresses...

10 + (149 * 3 inputs) + (34 * 4 outputs) = 593 bytes
593 bytes * 0.00000100 BTC per byte = 0.000593 BTC fee

However, if you pay the exact same fee of 0.00000100 BTC per byte, and you spend (use as inputs) 4 unspent outputs to send to 2 address...

10 + (149 * 4 inputs) + (34 * 2 outputs) = 674 bytes
674 bytes * 0.00000100 BTC per byte = 0.000674 BTC fee

As you can hopefully see, it isn't as simple as "which wallet is cheaper" or "will more addresses make it more expensive".  It all depends on how you receive the bitcoins, and how you structure the transaction.

If we have different addresses in a wallet with different amount of unspent outputs, the choice of which output to be spent choosing by the wallet will affect the size of the transaction?

Some wallets offer a feature called "coin control" that allows the user to choose which unspent outputs they want to spend as inputs in the transaction they are creating.  Also, Bitcoin Core has a command "createrawtransaction" that allows you to choose exactly which unspent outputs you want to spend as inputs, and exactly which new outputs you want to send the bitcoins to.

[bit9999]

Creating a transaction requires approximately 10 bytes to start with. Then, each unspent output that you use as an input to fund the transaction adds approximately 149 bytes.  Each new unspent output that you create (each recipient that you send to) adds 34 bytes.

So if we send to multiple addresses one by one, each additional address will add ~10 bytes? For example, if we pack 100 receiving addresses into one transaction, then we can save ~1000 bytes of space?

Also, is there a limit for how large one transaction size can be (in bytes)? Or a limit of total receiving addresses we can include in one transaction?

[jackg]

Creating a transaction requires approximately 10 bytes to start with. Then, each unspent output that you use as an input to fund the transaction adds approximately 149 bytes.  Each new unspent output that you create (each recipient that you send to) adds 34 bytes.

So if we send to multiple addresses one by one, each additional address will add ~10 bytes? For example, if we pack 100 receiving addresses into one transaction, then we can save ~1000 bytes of space?

Also, is there a limit for how large one transaction size can be (in bytes)? Or a limit of total receiving addresses we can include in one transaction?

Yes you would save about 1000 bytes of space.

And there is normally a mempool limit of 100KB and a maximum literal transaction size being 1MB.
You could contact a mining company who will probably be happy to mine your transaction if it's bigger than 100KB but it'll cost quite a bit in TX fees (viabtc allow you to broadcast transactions so they will pick up the transaction if they set rules that means it doesn't have to be on the mempool in order to be accepted). There was a block a while back which waas mined by F2pool I think that contained a transaction 900+KB in size.

[DannyHamilton]

So if we send to multiple addresses one by one, each additional address will add ~10 bytes? For example, if we pack 100 receiving addresses into one transaction, then we can save ~1000 bytes of space?

That depends on what you are comparing it to, and how you structure the tranaction.

Lets say I receive 3 payments of 1 BTC each. It doesn't matter whether I used 1, 2, or 3 addresses to receive the payments, the are three distinct payments so they are 3 distinct outputs).
Transaction_A
Transaction_B
Transaction_C

Now, lets say I want to send payments of 0.1 BTC to 4 different people...

I could do the following:
Create a single transaction that spends everything in my wallet and pays all 4 people in one payment...
This would have 3 inputs (since I'm spending all three payments that I received)
This would have 5 outputs (one for each person that I'm sending to, plus an additional one to send the 2.6 BTC of change back into my wallet)
The transaction size would be approximately:
10 + (3 X 149) + (5 X 34) = 627 bytes

Or I could do the following:
Create a single transaction that spends only the bitcoins that I received in one of the transactions listed above (for example, Transaction_A) and pays all 4 people in one payment...
This would have only 1 input (since I'm only spending one of the three payments that I received)
This would have 5 outputs (one for each person that I'm sending to, plus an additional one to send the 0.6 BTC of change back into my wallet)
The transaction size would be approximately:
10 + (1 X 149) + (5 X 34) = 329 bytes

Or I could do the following:
Create 3 separate transactions that each spend the bitcoins that I received in a different one of the transactions listed above and pays a different 1 of the 4 people, then create a 4th transaction that spends the change that I receive from one of those transactions to pay the 4th person...
Each of the 4 transactions created would have only 1 input (since I'm only spending one of the three payments that I received)
Each of the 4 transactions created would have 2 outputs (one for the person that I'm sending to, plus an additional one to send the change back into my wallet)
The total size of all 4 transactions added together would be approximately:
4 X [ 10 + (1 X 149) + (2 X 34) ] = 908 bytes

I'm sure you could come up with many other ways to combine inputs, outputs, and/or transactions to have other sizes. The smallest possible (assuming you don't want to pay a 0.6 BTC transaction fee) will be the 329 byte solution above.  If you were willing to pay a 0.6 BTC transaction fee, then you wouldn't need the additional output to send the change back into your wallet.  In that case you would reduce the size of the transaction by 34 bytes to only 295 bytes.

NOTE:  All of these descriptions of transaction sizes and costs are based on an assumption that you are NOT building SegWit transactions.  These estimates and calculations are all for traditional non-SegWit transaction structures. Building SegWit transactions would have slightly different sizes and different cost calcualtions, but it would probably be a good idea to make sure you understand this traditional way of structuring transactions first, and then you can learn about how SegWit is different.

[bit9999]

I'm sure you could come up with many other ways to combine inputs, outputs, and/or transactions to have other sizes. T

Is there any algorithm that will be able to find optimal solutions for least fees?

Any script we can use to auto create multiple address transaction with address and amt information, or we have to rely on wallet UI to manually do it? 

[DannyHamilton]

Is there any algorithm that will be able to find optimal solutions for least fees?

You will get your smallest size transaction per output by including all the outputs in a single transaction, and using the fewest number of inputs available to you such that the sum of those inputs is greater than or equal to the sum of the value of the new outputs plus the transaction fee you intend to pay.

Note, however, that in creating the optimal size transaction for a set of one or more transactions, you may be using inputs that might have been better used in a future set of transactions, thereby creating a situation where the total size of the two sets combined isn't as small as it could have been if you had created a slightly less optimal first set.

Note also, that if you try to ALWAYS create the most optimal size transactions, you will eventually be left with a growing number of small value outputs.  These small value outputs will add very little value to a transaction if they are used as inputs, but they will add 149 bytes.  Therefore the cost/value ratio for using them will be very low.  When you finally need to use them, they will result in a very expensive transaction.

The fee-per-byte costs that are necessary for fast confirmation are constantly changing, due to continuous variation in:

• The number of transactions being broadcast
• The number of blocks being solved
• The fees that others are wiling to pay

Given my notes above, and the fact that the fee rate is not constant, it can be beneficial to create a slightly less than optimal size transaction during times when you notice the fee rate is exceptionally low. That way you can use up some of the smallest value unspent outputs when it isn't very expensive to do so, and save the larger value unspent outputs for a time when the fee rate is higher.

Any script we can use to auto create multiple address transaction with address and amt information, or we have to rely on wallet UI to manually do it?  

I'm sure there are various implementations.  Both Electrum and Bitcoin Core have each implemented pretty good algorithms, but there is probably room for improvement on both of them.  If you think you can do better, then you can write your own program and create the transactions yourself.  If you don't feel it is worth it to write your own program, then you can just rely on the wallet.

[Thirdspace]

Is there any algorithm that will be able to find optimal solutions for least fees?

Any script we can use to auto create multiple address transaction with address and amt information, or we have to rely on wallet UI to manually do it? 

simplest algorithm, use the closest amount of single unspent output for making that certain single payment
or try to think equation of: unspentA + [unspentB] = paymentC + [change] + tx fee
the best efficient low cost transaction would be: unspentA = paymentC + tx fee

you should turn on "coin control" setting to see and understand easily what they've just explained
basically any of your addresses are used to make distinction for receiving different payments
but when you make/send out payment, you are more concern on the unspent outputs not your addresses anymore
the concept of wallet and address are NOT similar to bank and account number