Anonymity

[RHorning]

I bet anonymity is a must for many users. We definitely need a poll.
What happens if i send all my money to one of my unused addresses? I guess that coins from all other addresses are gathered in one and no one is able to tell if I sent them to myself. Right? As the OP (I think) said, I will be still in the "suspect" list but nevetheless it offers some deniability.

BTW when you send money to yourself the transaction log doesn't even list which the receiving account is... 

Don't send coins from one address to a different one on the same computer. This actually reduces your anonymity because it combines several different coins (some of which, such as generations, might be pretty anonymous). It's also obvious what you're doing because Bitcoin makes a special transaction when you send coins to yourself: it includes the full public key for the destination instead of the hashed public key used in normal transactions.

It sounds like this is something which desperately needs to be fixed.  There is no legitimate reason for transactions sent to yourself should be treated any differently than transactions to somebody else.  If anything, all "transactions" like this simply could be sent to "the nearest node" even if merely for confirmation and the "information" sent back to the original node.

This is a protocol problem and not something that should have "work arounds" that are merely kludges to something that can be fixed in the client and protocol itself.

[theymos]

Transfers to yourself are the same as transfers by IP address, so it was probably thought that this type of transfer would "blend in". No one uses IP transfers, though. (And no one should because they're insecure.)

Not much anonymity would be gained if this was fixed. You can't do proper "internal mixing" unless you have the ability to choose which coins you want to send to yourself.

[RHorning]

Transfers to yourself are the same as transfers by IP address, so it was probably thought that this type of transfer would "blend in". No one uses IP transfers, though. (And no one should because they're insecure.)

Not much anonymity would be gained if this was fixed. You can't do proper "internal mixing" unless you have the ability to choose which coins you want to send to yourself.

Why?  If you sent a transaction to a bitcoin address, how is that any different than sending the transaction to somebody else?  I just don't "get it", or understand why this is anything different?  Why should sending to a bitcoin address be treated as an IP address transfer, when clearly it isn't?

I'm not disputing that it is the current behavior, I'm just asking why it must be this way.

[mizerydearia]

Would it be useful to use some of the information discussed in this thread in providing a type of documentation or information available on the wiki?  Something like http://www.bitcoin.org/wiki/doku.php?id=level_of_anonymity perhaps?

[theymos]

Why?  If you sent a transaction to a bitcoin address, how is that any different than sending the transaction to somebody else?

It's only different because you are capable of sending to a public key instead of a hash, since the full public key is in your wallet. Normally you don't have the full public key, so you must send it to a hash. There's no technical reason why you couldn't send self-transactions to a hash -- Bitcoin just doesn't. You don't need to extend the protocol at all to deal with this (the confirmation stuff you mentioned isn't necessary).

[ichi]

What would be the point of sending bitcoin to another of one's receiving accounts on the same computer?  Even if it weren't less secure, it seems pointless and dangerous (see "lost bitcoin" thread).  Am I missing something?

It's become my practice to create a new Ubuntu VM / Bitcoin client for each major transaction, and to trash it after subsequent transfers to longer-term clients.  The IPs are anonymized.  Does that actually increase anonymity?

[Tritonio]

I bet anonymity is a must for many users. We definitely need a poll.
What happens if i send all my money to one of my unused addresses? I guess that coins from all other addresses are gathered in one and no one is able to tell if I sent them to myself. Right? As the OP (I think) said, I will be still in the "suspect" list but nevetheless it offers some deniability.

BTW when you send money to yourself the transaction log doesn't even list which the receiving account is... 

Don't send coins from one address to a different one on the same computer. This actually reduces your anonymity because it combines several different coins (some of which, such as generations, might be pretty anonymous). It's also obvious what you're doing because Bitcoin makes a special transaction when you send coins to yourself: it includes the full public key for the destination instead of the hashed public key used in normal transactions.

It sounds like this is something which desperately needs to be fixed.  There is no legitimate reason for transactions sent to yourself should be treated any differently than transactions to somebody else.

Exactly. I thought that if I created, let's say, three addresses and pass the money through each one of them, it would look like the money traveling through three different users. But because of this "inexplicable" feature it looks like I am schizophrenic.

BTW what's going on with that bug? I upgraded, added some good IP's and now it seems OK. But in the front page the older version is still served. Why?

[RHorning]

What would be the point of sending bitcoin to another of one's receiving accounts on the same computer?  Even if it weren't less secure, it seems pointless and dangerous (see "lost bitcoin" thread).  Am I missing something?

It's become my practice to create a new Ubuntu VM / Bitcoin client for each major transaction, and to trash it after subsequent transfers to longer-term clients.  The IPs are anonymized.  Does that actually increase anonymity?

While I've railed against the software in some ways, this is the behavior that Freenet uses... as a means to preserve anonymity.  By acting as if you had "received" the transaction from another node (even though you are the one generating the data in the first place), it puts plausible deniability that you were the origin of that data.  Furthermore, I fail to see how "dangerous" it would become if you are asking for another node to "confirm" the transaction.... something quite important to the health and stability of the network in the first place.  Freenet even goes an extra step by having clients randomly "inject" data received from other nodes to 3rd party nodes to make it even fuzzier who got the data in case somebody does an audit.  There is no need for Bitcoin to be that paranoid but it is useful to see what extreme step you can take if you want to preserve anonymity.

There is no need to create a whole new VM/Bitcoin client, and in fact that sort of behavior actually puts a huge load on the network unless you are also copying over the whole block chain when you are creating this "new client" and keeping that block chain up to date.  Even then, that is a whole bunch of extra work that is a waste of your time.  Again, you are taking on a relatively simple problem that can be fixed within the protocol and hitting it with not just a big hammer but using a nuke instead.  You can waste your time if you want, but using that as a recommendation to others to waste their time when it isn't needed is bad form.

In terms of the danger of losing transactions, this last little issue of the bad block which forced the upgrade to v. 0.3.10 has actually increased my "faith" that the network will do just fine if you send the transaction and just depend on the network getting it right.  How you might lose coins is if you send them to an address that doesn't exist through mistyping the recipient's address (in this case your own) in some fashion or some other technical fault that has nothing to do with transmitting the transaction to another node.

Why?  If you sent a transaction to a bitcoin address, how is that any different than sending the transaction to somebody else?

It's only different because you are capable of sending to a public key instead of a hash, since the full public key is in your wallet. Normally you don't have the full public key, so you must send it to a hash. There's no technical reason why you couldn't send self-transactions to a hash -- Bitcoin just doesn't. You don't need to extend the protocol at all to deal with this (the confirmation stuff you mentioned isn't necessary).

I'm not talking about extending the protocol here at all.... as a matter of fact it is a simplification of the protocol and perhaps even the client software too.  There is no reason to have a special case if the transaction happens to go to a key that exists on that same computer, and certainly no reason for any extra data to be recorded that would indicate a self-referential transaction that appears externally as anything other than a coin transfer from one user to another.  Explicit special coding must happen for that situation to occur... in other words software development effort has been spent to make the current situation that removes anonymity.  It is a case where keeping it simple helps improve the overall algorithm.

[Insti]

Don't send coins from one address to a different one on the same computer. This actually reduces your anonymity because it combines several different coins (some of which, such as generations, might be pretty anonymous). It's also obvious what you're doing because Bitcoin makes a special transaction when you send coins to yourself: it includes the full public key for the destination instead of the hashed public key used in normal transactions.

It sounds like this is something which desperately needs to be fixed.  There is no legitimate reason for transactions sent to yourself should be treated any differently than transactions to somebody else. 

+1

[mizerydearia]

software development effort has been spent to make the current situation that removes anonymity.

Maybe this should be the next news headline posted at top of forum pages after the current warning becomes less important.

[ichi]

While I've railed against the software in some ways, this is the behavior that Freenet uses... as a means to preserve anonymity.  By acting as if you had "received" the transaction from another node (even though you are the one generating the data in the first place), it puts plausible deniability that you were the origin of that data.  Furthermore, I fail to see how "dangerous" it would become if you are asking for another node to "confirm" the transaction.... something quite important to the health and stability of the network in the first place.

I was thinking of http://bitcointalk.org/index.php?topic=782.msg8905#new.

There is no need to create a whole new VM/Bitcoin client, and in fact that sort of behavior actually puts a huge load on the network unless you are also copying over the whole block chain when you are creating this "new client" and keeping that block chain up to date.  Even then, that is a whole bunch of extra work that is a waste of your time.  Again, you are taking on a relatively simple problem that can be fixed within the protocol and hitting it with not just a big hammer but using a nuke instead.  You can waste your time if you want, but using that as a recommendation to others to waste their time when it isn't needed is bad form.

Right.  So far, I've done that only for large purchases of bitcoin.  I'm not an exchange, so it's relatively infrequent.  Also, given that I'm mailing cash, receiving clients typically live for a week or two, and the additional load is small relative to my total contribution to the network.

Is that a waste of time?  Well, creating a new Ubuntu VM / Bitcoin client only takes a few minutes.  If that increases my anonymity, even marginally, it's well worth the effort.  For those who aren't as concerned about anonymity, it's certainly overkill.

Edit:  To be explicit, my threat model is this: Can I remain anonymous when all with whom I exchange bitcoin are conspiring to identify me?  For me, here and now, that's probably overkill, in that I'm just a guy buying anonymous connectivity and server resources.  In China, OTOH?  Anywhere in ten years?  Hard to say.

How you might lose coins is if you send them to an address that doesn't exist through mistyping the recipient's address (in this case your own) in some fashion or some other technical fault that has nothing to do with transmitting the transaction to another node.

In my experience, sending doesn't work with incorrect addresses.

I'm not talking about extending the protocol here at all.... as a matter of fact it is a simplification of the protocol and perhaps even the client software too.  There is no reason to have a special case if the transaction happens to go to a key that exists on that same computer, and certainly no reason for any extra data to be recorded that would indicate a self-referential transaction that appears externally as anything other than a coin transfer from one user to another.  Explicit special coding must happen for that situation to occur... in other words software development effort has been spent to make the current situation that removes anonymity.  It is a case where keeping it simple helps improve the overall algorithm.

I totally agree with this, FWIW.

[mizerydearia]

In my experience, sending doesn't work with incorrect addresses.

Incorrect addresses as in malformed addresses that are illegal or as in addresses that are currently considered nonexistent due to not being generated yet?

If the latter, how is it possible that all clients can verify whether an address exists or not?  Perhaps a call asking if it exists and if no response in ~2secs or so, then it doesn't exist?

[Insti]

You can send to an address that does not exist.

A bitcoin address has a checksum in it, so it will stop you sending to a 'made up - invalid' address like 1abadadfakjflsdfjadslfjalfj
But it's possible to construct valid non existing addresses if you know what you are doing. But you won't do this accidentally.

Being able to verify if an address existed would be bad.
Does the address with the lost private key that has 8999 BTC in it exist or not?

[ichi]

You can send to an address that does not exist.

A bitcoin address has a checksum in it, so it will stop you sending to a 'made up - invalid' address like 1abadadfakjflsdfjadslfjalfj

Yes, I've struggled sometimes copying addresses among isolated machines.  Including checksums is a great feature.

But it's possible to construct valid non existing addresses if you know what you are doing. But you won't do this accidentally.

Why would one do that?

Related question.  Suppose one created an address, and then took the host client down.  And suppose someone then sent bitcoin to that address.  Would that bitcoin exist indefinitely in limbo, waiting for the address to appear?  Or would the transfer just fail, and reverse itself?

[Insti]

But it's possible to construct valid non existing addresses if you know what you are doing. But you won't do this accidentally.

Why would one do that?

I can't think of a reason why you'd want to. I was just trying to illustrate that you didn't actually need to generate a private key to create an apparently valid Bitcoin address.

Related question.  Suppose one created an address, and then took the host client down.  And suppose someone then sent bitcoin to that address.  Would that bitcoin exist indefinitely in limbo, waiting for the address to appear?  Or would the transfer just fail, and reverse itself?

You don't need to have a client running to receive bitcoins.
Once you create an address, any coins sent to it will just sit there waiting for you to spend them.
Any transfer to a 'valid' address should be successful. It is VERY rare for a transaction to be reversed.
There are other threads that explain this in more detail.This is not really an Anonymity issue.

[nelisky]

You don't need to have a client running to receive bitcoins.
Once you create an address, any coins sent to it will just sit there waiting for you to spend them.

So, in theory, I could parse all the blocks, extract all the addresses and then make a tree of txins and txouts. With a little (a lot of?) effort, I could then try and split the txins from a txout into payment / change, effectively knowing which addresses belong to a single user. For those users that have a public address, this would be an unexpected disclosure.

I know the 'splitting the payment / change' is somewhat of a flawed argument, there is no way of being 100% sure all the time, but some rules might apply more often than not:
- Is there a txin for change = 0? This one is obviously from the sender
- On transactions of high value, chances are the highest part is the change (the 8999 lost coins thread being one such example)
- Future transactions from the change address will always carry the exact change amount + new txins, whereas the transfer receipient may very well already have a balance on the provided address.

I'm sure that all the statistical inclined fellow bitcoiners, being presented with a large enough annotated sample of the transactions to date could come up with a hihg accuracy model.

[ByteCoin]

Related question.  Suppose one created an address, and then took the host client down.  And suppose someone then sent bitcoin to that address.  Would that bitcoin exist indefinitely in limbo, waiting for the address to appear?  Or would the transfer just fail, and reverse itself?

You don't need to have a client running to receive bitcoins.
Once you create an address, any coins sent to it will just sit there waiting for you to spend them.
Any transfer to a 'valid' address should be successful. It is VERY rare for a transaction to be reversed.
There are other threads that explain this in more detail.This is not really an Anonymity issue.

Actually, when you send coins to an address you can view the coins as sitting there waiting for the address "holder" to spend them even if the address doesn't exist. If that address is created in future then they can spend the coins.
If you send coins to an address for which the private key has been lost then the coins can be imagined to be in limbo waiting for either the private key to be recovered or for a new key with the same address to be generated.
(Not sure about the "new key with same address" bit. May depend on the details of the transaction).

ByteCoin

[NewLibertyStandard]

Sending payments to fake addresses provides a way to broadcast short encoded and optionally encrypted unalterable messages to the world anonymously. Have security codes for the organization committing genocide, but scared you'll be killed if the publisher accidentally reveals your identity? Publish them with Bitcoin.

[theymos]

It's become my practice to create a new Ubuntu VM / Bitcoin client for each major transaction, and to trash it after subsequent transfers to longer-term clients.  The IPs are anonymized.  Does that actually increase anonymity?

From the "Anonymity" article on the wiki:

Sending coins to a different computer under your control will give you some plausible deniability. However, an investigator is still likely to find you and demand to know who you sent the coins to. If they search your stuff, they'll probably find your other computer. If the attacker is not law enforcement (or maybe even if they are), they might kill you “just in case”. If you use this method, send bitcoins in small increments (no more than 50 BTC, but as small as you're willing to use) to avoid combining coins, which reduces anonymity.

Also:

Tor prevents network analysis and should be used, but it won't help make your Bitcoin balance “clean” The attacker isn't talking to you over the Internet; they're looking at your changes to the block  chain. This is similar to posting a threat and your street address on a message board using Tor – Tor doesn't stop the police from finding you.

To be explicit, my threat model is this: Can I remain anonymous when all with whom I exchange bitcoin are conspiring to identify me?  For me, here and now, that's probably overkill, in that I'm just a guy buying anonymous connectivity and server resources.  In China, OTOH?  Anywhere in ten years?  Hard to say.

As long as it's not illegal to use Bitcoin, Bitcoin can satisfy that threat model. The current implementation does not, however.

I'm not talking about extending the protocol here at all.... as a matter of fact it is a simplification of the protocol and perhaps even the client software too.  There is no reason to have a special case if the transaction happens to go to a key that exists on that same computer, and certainly no reason for any extra data to be recorded that would indicate a self-referential transaction that appears externally as anything other than a coin transfer from one user to another.  Explicit special coding must happen for that situation to occur... in other words software development effort has been spent to make the current situation that removes anonymity.  It is a case where keeping it simple helps improve the overall algorithm.

I agree that the behavior should be changed. The change is not really a simplification, though: it's the use of hashes (addresses) that is a bit of a "hack". The thought was probably, "We know the public key, so let's avoid all of that hashing garbage."

[FreeMoney]

Sending payments to fake addresses provides a way to broadcast short encoded and optionally encrypted unalterable messages to the world anonymously. Have security codes for the organization committing genocide, but scared you'll be killed if the publisher accidentally reveals your identity? Publish them with Bitcoin.

It would be just terrible if people realized there was a way to post messages to the internet.