Sending without generating a second receiving "change" address?

[Staring Owl]

The way bitcoin works is that if you you want to send $7 but have only $10 bills (addresses) you send the whole bill and that's gets split to 2 receiving addresses. The receiver gets $7 and the second address that's yours gets the change of $3.
Is that right?

Now is that second "change" address freshly generated in your wallet? Are there any drawbacks to it?
For example if you use some web based wallet, is there an option that you won't get your change credited to your acc?

Are there any techniques to make it send exact amounts without the need of generating "change" address?


How we can see how much each of the addresses in our wallet has?

[1715252943]

1715252943

[1715252943]

1715252943

[1715252943]

1715252943

[1715252943]

1715252943

[Gabi]

A new address is not required, the bitcoin-qt client generate a new address for anonimity and security purpose, but it is happily possible to send the change back to the original address 

[Abdussamad]

1. Now is that second "change" address freshly generated in your wallet? Are there any drawbacks to it?

2 .For example if you use some web based wallet, is there an option that you won't get your change credited to your acc?

3 .Are there any techniques to make it send exact amounts without the need of generating "change" address?

4. How we can see how much each of the addresses in our wallet has?

1. Depends on your bitcoin client. The reference client (bitcoin-qt) generates 100 addresses when you first start it and then picks one from that pool of addresses each time it needs a change address. It also generates a new address to add to the pool. That is why you are advised to backup your wallet.dat file every 100 transactions.

2. That would be a nasty bug. Do you want to send change to some specific address?


3. The wallet concept abstracts this whole business away. The drawback is that you don't have fine grained control like that unless you use the CLI - https://en.bitcoin.it/wiki/Raw_Transactions

Electrum offers the option to freeze and prioritize addresses. So you freeze all addresses except the one which contains the exact amount of bitcoins you want to spend.

Another way is to use the blockchain.info API - http://blockchain.info/api/blockchain_wallet_api


4. Enter the address in the search bar on the top right corner of http://blockchain.info


Change addresses are not a problem. They are part of how using bitcoin works. You shouldn't worry about them.

[grue]

You can use coincontrol branch (search for it) to control what address you use for the "change" address. There's no advantage to using your own address as a "change" address though. Change sent to an existing address still counts as an extra input for purposes of fee calculation.

[DeathAndTaxes]

You can never send part of an output so the only to have no change is either
a) you just happen to have unspent outputs which exactly match the amount you want to send.
b) you send any excess as a fee to a miner

The change address doesn't "have" to the a new address that is just the way the reference client does it.  If you really wanted to you could send the change back to the funding address or to an existing address, or even a dedicated address where change always goes.  The protocol doesn't care.

All the protocol cares is: value of tx inputs = value of tx outputs + miner fee

If you are spending a 10 BTC unspent output the input of the new tx is 10 BTC.
The outputs (including any change address) and any fee to miners must be exactly 10 BTC.

[Staring Owl]

Very useful info here, thank you all!

[justusranvier]

Now is that second "change" address freshly generated in your wallet? Are there any drawbacks to it?

The way Bitcoin-Qt does it has a drawback in that it generates random change addresses periodically which invalidate your wallet.dat backups after every 100 transactions.

Clients which support deterministic wallets such as Armory do not have this drawback.

[razorfishsl]

Multibit also has an issue.

If you generate multiple addresses, then unspent output is sent back to one of those....., it is an issue because it allows tracing of addresses you might want to keep private.


I.E you might have been using a 'secret' address that was untraceable back to your main address.
Then one day you wake up and find that you made a payment from your main address, only to have the 'unspent' portion loop back on your  'secret' address and expose the link between your main address and the 'secret' address.

and in an instant the whole history of the 'secret' address is linked to the main address.

[kodo]

Is this problem still persisting? Have you tried to make a new address?

[Staring Owl]

When I send money to a service it seems to see my change address as a sender address instead of the actual sender address.
And if they want to send only to the address they got the money from, they send to the change address.
Is that behavior normal?

[DannyHamilton]

When I send money to a service it seems to see my change address as a sender address instead of the actual sender address.
And if they want to send only to the address they got the money from, they send to the change address.
Is that behavior normal?

Only with VERY poorly designed services.  As such, I make a significant effort to avoid any services designed this way.

[🏰 TradeFortress 🏰]

When I send money to a service it seems to see my change address as a sender address instead of the actual sender address.
And if they want to send only to the address they got the money from, they send to the change address.
Is that behavior normal?

Only with VERY poorly designed services.  As such, I make a significant effort to avoid any services designed this way.

Hey, of course they'd do that if they charge you 0.5% for additional privacy.

[stevenh512]

Multibit also has an issue.

(snip)

Then one day you wake up and find that you made a payment from your main address, only to have the 'unspent' portion loop back on your  'secret' address and expose the link between your main address and the 'secret' address.

and in an instant the whole history of the 'secret' address is linked to the main address.

Multibit supports multiple wallets. If you really want to have a "secret" address that's untraceable back to your main adress, why would you ever have both addresses in the same wallet?

Create a second wallet for your "secret" address and never transfer money between your "secret" address and your main address without using a mixer. Problem solved, there's no way to accidentally combine inputs from the two addresses or accidentally send change from the "secret" address to the main address since they're in separate wallets and there should be no way to link the two addresses by observing the blockchain.

Same thing can be done with Electrum or any other client that supports multiple wallets, but it's easier (no command line needed) to do it with Multibit. This isn't an issue with Muitibit, it's an issue with someone not using Multibit to its full potential.

[BookLover]

I've had transactions were bitcoin-qt will send the "change" coins back to the sending address rather than the a new address from the key pool.  If someone could explain this behavior I would really appreciate it.

[DannyHamilton]

I've had transactions were bitcoin-qt will send the "change" coins back to the sending address rather than the a new address from the key pool.  If someone could explain this behavior I would really appreciate it.

This sounds unlikely.

Please provide a transaction ID to a transaction where this has happened.

[/dev/null]

Use electrum. It allows you to use single address

[BookLover]

I've had transactions were bitcoin-qt will send the "change" coins back to the sending address rather than the a new address from the key pool.  If someone could explain this behavior I would really appreciate it.

This sounds unlikely.

Please provide a transaction ID to a transaction where this has happened.

I thought so to, I almost couldn't believe it when i saw it because I thought the "change" was always sent to a new address from the keypool.

http://blockchain.info/address/19ocAbKEQ5pmTSiSwh2vtLsMt7LGqL5usM

[DannyHamilton]

I've had transactions were bitcoin-qt will send the "change" coins back to the sending address rather than the a new address from the key pool.  If someone could explain this behavior I would really appreciate it.

This sounds unlikely.

Please provide a transaction ID to a transaction where this has happened.

I thought so to, I almost couldn't believe it when i saw it because I thought the "change" was always sent to a new address from the keypool.

http://blockchain.info/address/19ocAbKEQ5pmTSiSwh2vtLsMt7LGqL5usM

What version of Bitcoin-Qt are you using?

What operating system is it running on?

I can't decide if I believe that you had this happen to you, or you're playing a prank by creating the transaction that way intentionally (sending 0.05 BTC to the address and then using a multiSend to split the received payment to two specified addresses with no change).

[BookLover]

Bitcoin-QT version number as labeled under "help, About Bitoin": v0.8.3.0-g40809ae-beta

OS is Linux Mint 14, code name Nadia.

I hate to say this because it will sound like I'm trolling  , but that is not my transaction.  You did say

A transaction where this has happened.

I didn't give you the transaction where this happened to me because I'm paranoid and would rather not connect those coins to my forum account.

I am however NOT trolling and would be willing to cooperate in any way which does not reveal personal information to solve this problem.  I have been on this forum for years and have helped many other people with their technical problems. (check my forum posts if you don't believe me)  This issue is just as unbelievable to me as it is to you.  I would love to get a developer here who knows enough about this to determine if the is anywhere in the code where this can happen, or if I have something crazy going on in my system.

[DannyHamilton]

I hate to say this because it will sound like I'm trolling  , but that is not my transaction.  You did say

A transaction where this has happened.

Yes, I said "A transaction where this happened".

I did not say "A transaction where you are guessing that this has happened."

There is no evidence that some random transaction that you've chosen from the blockchain was created with Bitcoin-Qt.  It could be a rawtransaction. It could be created with a wallet that has coin-control. It could have been created with a blockchain.info wallet.  There are many possibilities.  You can not just look at a random transaction where the change is sent to an address that has previously received bitcoins and assume that that transaction is:

A transaction where this has happened.

I didn't give you the transaction where this happened to me because I'm paranoid and would rather not connect those coins to my forum account.

I am however NOT trolling and would be willing to cooperate in any way which does not reveal personal information to solve this problem.

I can understand your concern, but unless someone can reproduce the results you are claiming, I'm having a very difficult time accepting it as described.