Bitcoin "From" address, can i change it?

[JollyGreen]

Hi All,

I was sending BTC to different friends, just playing around with the GUI and realized it doesn't seem I have control over which "from" address is used in a Send transaction.  Is this true?

Does anyone know how bitcoin determines which "from" address to assign to a send transaction?

JG

[1713542855]

1713542855

[1713542855]

1713542855

[1713542855]

1713542855

[theymos]

You can't choose your "from" addresses in the official client. Even if there was an option for this, it would still only be possible to send from an address that has an unspent transaction belonging to it.

Unspent transactions are called "coins". You can only redeem full coins, so if you don't have a batch of coins that can be evenly combined into the desired send value, you need to send yourself some change. Bitcoin tries to choose a set of coins that fits the desired send value closely, minimizing change.

[theymos]

For bookkeeping you can use accounts and RPC "sendfrom", and Bitcoin will keep track of individual account balances. If you sendfrom an account and its balance is too low, the transaction will fail and you'll have to "move" funds from some other account. This is all artificial, though -- "sendfrom" doesn't actually try to send from account-owned addresses.

Being able to choose coins would be useful, especially for anonymity reasons.

[theymos]

Are "accounts" and "sendfrom" features of the bitcoind daemon?

Yes.

[So_Cynical]

So if i had 3 people send me 50 BTC each at the same time...i cant tell which 50 came from which person.?

[N12]

So if i had 3 people send me 50 BTC each at the same time...i cant tell which 50 came from which person.?

You should create a new address for everything and name it. This way you’ll know and gain some anonymity.

[Gavin Andresen]

Seems like it would be useful if the GUI client had an option similar to the bitcoind "sendfrom" functionality.  Do you think this would be impossible to try and get into the client?  Am I just wasting my time?   I'm willing to do the work and write some code for review, but I don't want to go down that road if it's something everyone would basically vote down at review time.

I wouldn't have any objections to changes that let you decide which input transactions or receiving addresses to choose when sending coins, as long as it is well-tested, follows the coding guildelines (see coding.txt in the source directory)  and it doesn't make the "I just want to send some coins" case look more complicated (maybe hide it behind an Advanced... button in the Send dialog).

[N12]

Sounds good, vladimir. A key could be very well used as a form of authentification instead of an email. The advantage would be that you can create keys much more easily and faster than emails, plus you have a better overview.

[Hal]

Bitcoin's behind-the-scenes address handling makes things a little complicated. Say you received 2 payments of 50 to your empty wallet. Then you made 2 payments of 30. Now you will have 2 addresses worth 20, both addresses you've never seen before and which don't show up in the transaction list. These received the "change" from the 30 payments.

These addresses don't reveal which 50 payment they came from. To see that you'd have to provide some new mechanisms. Maybe show the transaction history behind each address. Maybe show change addresses in the main window. Maybe bring in the account features and tag transactions with accounts.

It's not as simple/useful as it seems.

[Mike Hearn]

The client defaults to assuming you want privacy. There's no technical reason you can't use one address over and over again like a bank account number. However that makes all your transactions easily correlatable.

[theymos]

For average users, using just one address per account would solve a lot of problems. Backups would be much easier.

[Mike Hearn]

For the hypothetical Android client I have yet to build I was going to create a Chrome-like Incognito mode. In this mode all privacy related changes (like maybe using tor automatically) would be bundled together. It could even send coins via a mixer service, if/when such a thing exists.

[Hal]

Here's how I would approach this idea. The concept would be to function in max-anonymity mode by default as now, but to also specify a certain address as being associated with an identity. Receiving coins to that address is trivial, just give out that address for payment. Add a feature to make identified payments from that address as you propose. Important, payments from that address should use that same address for change. Equally important, make sure that regular "anonymous" payments DO NOT use the identified address, otherwise your anonymity will be compromised. That way, anonymous and identified payments can coexist.

You could also have more than one identified address, keeping each separate. Probably you'd want to use the address label to choose which to pay with. But the same principles would apply: change back to the same address, and never use it for regular payments.

As far as getting started, I'd like to see a sticky walking through the steps to create a pull request. But yeah, you can check out from sourceforge using svn, get your changes working, and post the output of svn diff as a patch.

[Gavin Andresen]

As far as getting started, I'd like to see a sticky walking through the steps to create a pull request. But yeah, you can check out from sourceforge using svn, get your changes working, and post the output of svn diff as a patch.

Sticky for creating a pull request:  good idea.

JollyGreen: if you know, or are willing to learn, git then working from the git repo ( https://github.com/bitcoin/bitcoin )is smoother.  github has built-in support for turning a development branch into a pull request.