Topic: Anonymity - page 5. (Read 68752 times)

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

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?

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?

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?

I was thinking of https://bitcointalksearch.org/topic/m.8905.

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.

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

I totally agree with this, FWIW.

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

+1

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.


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.

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?

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?

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).

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?

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.

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.

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.

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.

Right now, the best way to make your balance anonymous is to use MyBitcoin through Tor. MyBitcoin (presumably) pools all of its customers' balances, so it acts a bit like one of the external mixing services I described in the OP. However, unless they modified Bitcoin, they keep logs of every transaction, so they could identify you if they had to. It's like using a web proxy that keeps logs.

If I really wanted to make an anonymous transaction, this is what I would do:
- Send entire transaction amount to a new MyBitcoin account as a lump sum.
- Set up a brand new (empty) Bitcoin installation using Tor.
- Every day, withdraw 5% of the transaction amount to the new installation. Bonus points: add some randomization to the amount of Bitcoins you withdraw and the time between doing it.
- Finally, send the transaction from the new installation

I doubt you'll ever be traced after doing this unless you're doing something really illegal. If you want more anonymity, you can:
- Send fewer coins from MyBitcoin to your new installation over a longer period of time.
- Also add Vekja (another service like MyBitcoin). This is like chaining encrypted proxies: both will need to be compromised for you to be identified.

MyBitcoin and Vekja don't act like "true" external mixing services because they don't try to mix balances. If you're transferring a lot of money in this way, you're likely to get back most of your own coins, which would greatly reduce your anonymity.

I don't think that "peering dispute" would have bothered Bitcoin networking really. Only direct connections between the two "warring" factions were cut. Indirect connections through one or more nodes not in either of the disputed territories could still link to both sides. (Both sides kept their connections to Google and Microsoft and so on.)

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... 

Well, we need a poll. For me, anonymity is the only feature I need

It is easy to imagine some bug in implementation, that may be triggered by some invalid specially crafted network message,
let it cause bitcoin client to hang, but only after retransmission of the same message to peers and after damaging the blockchain
database on disk.

If there will be only one implementation with the same bugs shared among versions and platforms, then the entire network will lose blockchain and when the majority will eventually recover, every separate node will reconnect to some existing majority with it's own notion of history. If that event happens as a coordinated attack, then we may get very different history.
How can that affect previous transactions?
BTW, is there a blockchain backups?

PS: Let's not discuss how impossible it is to exploit software vulnerabilities so precisely. That is an art with it's own secrets and surprises. And no, I cannot do that right now to prove it is possible.

It's hard to imagine the Internet getting segmented airtight.  It would have to be a country deliberately and totally cutting itself off from the rest of the world.

Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone.  It would only take one node to do it.  Anyone who wants to keep doing business would be motivated.

If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks.  Their number of confirmations would start over.

If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.

It wouldn't be easy to take advantage of the segmentation to double-spend.  If it's impossible to communicate from one side to the other, how are you going to put a spend on each side?  If there is a way, then probably someone else is also using it to flow the block chain over.

You would usually know whether you're in the smaller segment.  For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment.  If you're in the smaller segment, you should assume nothing is confirmed.