Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: Staring Owl on June 10, 2013, 12:58:51 PM



Title: Sending without generating a second receiving "change" address?
Post by: Staring Owl on June 10, 2013, 12:58:51 PM
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?


Title: Re: Sending without generating a second receiving "change" address?
Post by: Gabi on June 10, 2013, 01:09:20 PM
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  ;)


Title: Re: Sending without generating a second receiving "change" address?
Post by: Abdussamad on June 10, 2013, 02:38:11 PM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: grue on June 10, 2013, 06:47:18 PM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: DeathAndTaxes on June 10, 2013, 06:54:14 PM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: Staring Owl on June 12, 2013, 11:40:42 AM
Very useful info here, thank you all!


Title: Re: Sending without generating a second receiving "change" address?
Post by: justusranvier on June 13, 2013, 06:52:49 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: razorfishsl on June 13, 2013, 01:30:12 PM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: kodo on June 13, 2013, 02:12:49 PM
Is this problem still persisting? Have you tried to make a new address?


Title: Re: Sending without generating a second receiving "change" address?
Post by: Staring Owl on July 24, 2013, 05:24:13 PM
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?


Title: Re: Sending without generating a second receiving "change" address?
Post by: DannyHamilton on July 26, 2013, 04:35:26 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: 🏰 TradeFortress 🏰 on July 26, 2013, 09:38:24 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: stevenh512 on July 26, 2013, 09:50:32 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: BookLover on November 22, 2013, 01:38:29 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: DannyHamilton on November 22, 2013, 06:02:58 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: /dev/null on November 22, 2013, 06:15:23 AM
Use electrum. It allows you to use single address


Title: Re: Sending without generating a second receiving "change" address?
Post by: BookLover on November 22, 2013, 03:00:09 PM
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


Title: Re: Sending without generating a second receiving "change" address?
Post by: DannyHamilton on November 22, 2013, 05:53:46 PM
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).


Title: Re: Sending without generating a second receiving "change" address?
Post by: BookLover on November 23, 2013, 07:44:44 PM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: DannyHamilton on November 24, 2013, 01:15:56 AM
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.


Title: Re: Sending without generating a second receiving "change" address?
Post by: BookLover on November 24, 2013, 02:57:24 AM
I was searching through some old transactions and found that this has happened several times before.

here is my bitcoin.conf file: (with security adjustments)
Code:
rpcuser="my_username"
rpcpassword="my_password"

dbcache=5000
#default = 25

keypool=500
#default = 100

addnode=12.47.47.47
addnode=12.229.228.146
addnode=18.215.0.96
addnode=23.21.225.111
addnode=23.23.68.110

The only other settings I've changed are to connect through Tor.

Edit: Just sent a small transaction to try and reproduce the problem but the change went to a new address instead of the old one.  Is it possible that keeping the wallets were this is happening in cold storage and not backing them up after every transaction could have something to do with the odd behavior?