Simple question - Sending BTC to someone from a local wallet

[califminer]

If I have 1 BTC and I I use "bitcoin-cli sendtoaddress " to send 0.1 to someone, is it true that the rest would be charged as fees and I will be left with nothing? I know this sounds crazy but I read that if one doesn't supply the changeaddress option (OR use the  rawtransaction feature  to set a fee), the remaining goes to the miners.

Questions:
1 ] Is the above true?
2 ] If it is then if when I send 0.1 out of 1 BTC, I will be left with nothing right?
3 ] Can I use  sentoaddress (and not rawtransaction) along with paytxfee or settxfee and reduce the fees?

Thanks.

[Rath_]

If I have 1 BTC and I I use "bitcoin-cli sendtoaddress " to send 0.1 to someone, is it true that the rest would be charged as fees and I will be left with nothing?

No. By default, the fee will not be deducted from the amount you specify; it will be deducted from the coins available in your wallet.

2 ] If it is then if when I send 0.1 out of 1 BTC, I will be left with nothing right?

Assuming that you had a 1 BTC UTXO, the remaining 0.9 BTC minus the transaction fee would be sent back to your (change) address.

[califminer]

What if I haven't specified a change address?

[Rath_]

What if I haven't specified a change address?

You don't need to. Bitcoin Core generates such an address and sends the remaining coins to it automatically. As I wrote above, in your case, the remaining 0.9 BTC minus the transaction fee would be sent to a new address belonging to you.

[califminer]

So will a new private key and a new address get added to my wallet.dat automatically?
If yes then this is not good, I like to label my addresses in a pattern.

[hosseinimr93]

As stated by Rath_, there is nothing to worry about.

I think I know where your concern is coming from. You are mixing up two different commands. createrawtransaction and sendtoaddress commands.
You will lose the remaining balance if you make a transaction using  createrawtransaction command and don't specify the change address. In this case, all the remaining balance will go to miners.
Since you are going to make the transaction using sendtoaddress, the remaining balance will go to you change address automatically.

So will a new private key and a new address get added to my wallet.dat automatically?
If yes then this is not good, I like to label my addresses in a pattern.

You can use sendmany command instead and send the fund to multiple addresses. Send the remaining balance to change address.
You can also use createrawtransaction and specify a change address. (Don't forget to specify the change address or you will lose the remaining balance)

[Rath_]

So will a new private key and a new address get added to my wallet.dat automatically?

Yes. Also, you won't have to backup your wallet.dat again since the private key for the freshly generated change address will be derived from your master private key which is stored in that file.

If yes then this is not good, I like to label my addresses in a pattern.

You can specify a change address using createrawtransaction. You should be able to specify the same address from which you are sending. If you don't specify any address then the change will be added to the fee.

[califminer]

Instead of using createrawtransaction, can I use paytxfee or settxfee with sendtoaddress or sentomany and achieve the same reduced fee result?

Rath_, Thank you for responding so quickly to all my queries.

hosseinimr93, Thanks for clearing the confusion. I was under the assumption that sendtoaddress is a dangerous command as well if not used correctly.

[BitMaxz]

Instead of using createrawtransaction, can I use paytxfee or settxfee with sendtoaddress or sentomany and achieve the same reduced fee result?

~snip~

I think both paytxfee and settxfee will not work along with sendtoadddress or sendmany.

If you want to set a fee manually for your transaction you need to use the "fundrawtransaction" command according to this https://bitcoincore.org/en/doc/0.20.0/rpc/rawtransactions/fundrawtransaction/

Before you use the "fundrawtransaction" command you must "createrawtransaction" first then the generated raw must be added like this as sample below along with "fundrawtransaction" and fee rate sample 10 sat/byte.

Code:

bitcoin-cli fundrawtransaction <raw tx> '{"feeRate":0.0001}'

I found this sample from the guide posted by Achow from here https://bitcoin.stackexchange.com/questions/79092/bitcoin-core-rpc-fee

[califminer]

So in short, no way to control the fee while using  sendtoadddress or sendmany.
I still need to learn how to generate txid. Any simple explanation as to how to generate that?

[AdolfinWolf]

So in short, no way to control the fee while using  sendtoadddress or sendmany.
I still need to learn how to generate txid. Any simple explanation as to how to generate that?

https://bitcoin-rpc.github.io/en/doc/0.17.99/rpc/wallet/sendtoaddress/

It seems you can set a conf_target flag.

Although you should probably first probe a conf_target to see if the amount of sats/b is somewhat near what you want to spend on fees. using for example (https://bitcoincore.org/en/doc/0.16.0/rpc/util/estimatesmartfee/)

I have never used the sendtoaddress command, but it should return a txid automatically on success.

Alternative to this workflow, you can also use createrawtransaction <your parameters> -> fundrawtransaction <use the result of prev> -> signrawtransactionwithwallet <use the result of prev> -> sendrawtransaction <use the result of prev> -> results in TXID.

[HCP]

So will a new private key and a new address get added to my wallet.dat automatically?
If yes then this is not good, I like to label my addresses in a pattern.

I believe that you can specify the label for any address in your wallet by using the setlabel command. So, you can just retroactively label the change address after it has been created.

Also, technically, the private key and address are probably already generated and stored in your wallet.dat before you even request a "new" receiving address or "create" a change address with a transaction. Bitcoin Core HD wallets have a keypool size of 1000 by default, so they already hold 1000 pre-generated keys in the wallet.dat. When you "create" a new address, the application just defaults to using the first one (in order) that it has in the keypool.

I still need to learn how to generate txid. Any simple explanation as to how to generate that?

You don't generate the TXID... it's returned to you automatically once a transaction is created and then signed. Only at this stage will the transaction be considered "finalised" and the TXID able to be generated (it's the hash of certain transaction data).

[califminer]

It's funny how a TXID echoed back by the console when one sends coins is the thing itself used to create a fresh new rawtransaction. I used to think a txid echoed back is just like a receipt but it seems it's what is further used to send the coins you once received. Correct me if I am wrong, but blockchain is actually a chain linked with txids.

A question: If I use a txid to create a raw transaction but I still have some balance coins as unspent, can I use the same txid to generate another rawtransaction OR will I need a diff txid ?

[HCP]

It's funny how a TXID echoed back by the console when one sends coins is the thing itself used to create a fresh new rawtransaction. I used to think a txid echoed back is just like a receipt but it seems it's what is further used to send the coins you once received. Correct me if I am wrong, but blockchain is actually a chain linked with txids.

Not quite. It's in the name "blockchain"... so, it's a chain of "blocks"... each block contains a number of transactions. A block includes the hash of the previous block in it's header, that's what links them together.

A question: If I use a txid to create a raw transaction but I still have some balance coins as unspent, can I use the same txid to generate another rawtransaction OR will I need a diff txid ?

It's not TXIDs that allow you to spend the coins... you reference a particular "vout" from a previous TXID, also known as an "Unspent Transaction Output" or UTXO.

One of the fundamentals of bitcoin is that when you spend a UTXO (ie. it is used as an input in a transaction), the entire UTXO is consumed... any "leftovers" (aka "change") is then generated as a completely new UTXO.

So... if you had the following situation where you had previously received 0.1 BTC... it would have been created as a UTXO from some transaction, we'll call this UTXO, "OutputA". If you subsequently used this UTXO to send 0.08 BTC to someone, you would end up with a transaction that generated 2 UTXOs:

OutputA 0.1 BTC --|--> OutputB 0.08 BTC (amount sent)
                           |--> OutputC 0.02 BTC ("change")

(ignoring transaction fees)


Now, if you wanted to spend your "leftover" 0.02 BTC, you can't use OutputA, as that has already been consumed (aka "spent")... instead you need to use the "new" UTXO (OutputC).

[califminer]

So a block has a hash of the previus block + TXIDs. Typically how many transactions can  one block hold.. any rule stating max or min numbers?

BTW amazing job painting a visual picture using words and just pipes and arrows.
But I am still confused about vout. Why are they always 0 or 1 or 2??

Correct me if I am wrong, so there are 2 types of TXIDs.. one's which are receipts of coins received by me and ones which are sent by me.

And the output of :
bitcoin-cli listreceivedbyaddress
shows both types of txids

Correct?

[Pmalek]

Typically how many transactions can  one block hold.. any rule stating max or min numbers?

A Bitcoin block can contain up to 1 MB of transactions. 3000-3500 is the maximum amount of transactions per block. But it depends on the size of the transactions + the blocks are rarely full.

If you take a look at this source for example (not sure how accurate it is) https://www.blockchain.com/charts/n-transactions-per-block, you will see that the recent blocks had between 1.400 - 2.600 transactions per block.

[nc50lc]

Typically how many transactions can  one block hold.. any rule stating max or min numbers?

A Bitcoin block can contain up to 1 MB of transactions. -snip-

It's safer if we say "1 virtual MB" or 1MvB max.
Because in 'MB', the size of a bitcoin block with witness data in disk can reach more than 1MB up to 4MB (can only fit up to 3+MB, in reality).

[HCP]

BTW amazing job painting a visual picture using words and just pipes and arrows.
But I am still confused about vout. Why are they always 0 or 1 or 2??

They are just a sequence of "outputs", numbered from 0... up to (number of outputs - 1) so if you have 1 output, it will be vout = 0... if you have 10 outputs created by the transaction, you will have 10 vouts numbered 0-9. If you have 100 outputs, they'll be number 0-99 etc.

Like this transaction.... it has 15 outputs, so the highest vout = 14.


The reason most transactions only have vout 0 or 1, is simply because that is the most common type of transaction, sending to one recipient, that either sends ALL the coins to that recipient, so only one output... so only vout = 0...

OR

They send to one recipient and create "change"... so 2 outputs created... so vout  = 0 and vout =1.

Correct me if I am wrong, so there are 2 types of TXIDs.. one's which are receipts of coins received by me and ones which are sent by me.

No, there is no "type" of TXID. The TXID (ie. Transaction ID) is simply a hash of the transaction data... With regards to transactions that might show in your wallet history, you can think of them as being two different types... "Receiving" transactions, where someone is sending coins from an address that is external to your wallet to an address controlled by your wallet... and "Sending" transactions, where coins are being sent from your wallet to somewhere else.

And the output of :
bitcoin-cli listreceivedbyaddress
shows both types of txids

Correct?

No... as per the help text, listreceivedbyaddress simply groups all the "receive" type transactions by address...

List balances by receiving address

it will not show "sending" transactions, nor will it show your "change" addresses that are receiving coins from sending transactions that you initiate.