Topic: Anonymity (Read 1107 times)

You will never have 100% anonymity.

Great.. I did'nt know there was a separate Armory section.

Thanks alot for those pointers. The "listen=1" parameter to bitcoin.conf did the trick.

It seems that

• bitcoin turns off listening when proxy is set, unless listen=1 is also specified
  
• armory needs bitcoind to be listening
  

I noticed that there was a connection outside of tor, so I changed my nat router configuration to not forward port 8333. Alternatively I could have changed my listening port with port= in bitcoin.conf. There will be no incoming connections anyway, as long as I do not want to reveal my address. The incoming call could have been some node that had my ip address noted from an earlier session. Please arrest me if I got this wrong.

Why does armory need bitcoin to be listening? Perhaps there is a race between threads listening for tcp connections and threads listening for rpc.

Bitcoin is not completely anonymous

bitcoin-qt runs fine through tor.

That should be Ubuntu 12.04, i7 processor, 64 bit kernel. I also have a 25 Mbps symmetric link with ping time 10.5 ms to a big site in my country, 29 ms to bitcointalk.org

From a running, synchronized armory, I quit armory and start again. This is without proxy. After 24 seconds I have "Synchronizing with network" 100 % and 0 blocks. Then after a total of 10 min 37 secs I have "Scanning Transaction History" on 100 % and armory is ready.

When I do the same with this in bitcoind.conf: proxy=127.0.0.1:9150. Quit armory running directly, then starting it through the Tor proxy, I get this after about 51 seconds: "Synchronizing with network" 99 % and 0 blocks. "Scanning Transaction History" hasn't started, seemingly.

I check "bitcoind getlastblock" and it seems to keep up with the block numbers on blockchain.info, but a number of seconds later. I have 8 connections according to "bitcoind getinfo".

So now I have 32 minutes, and there is no more progress.

In the .bitcoin/debug.log I have mostly these:

ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock

Below is a part of the debug log, and it looks a lot like the log in the normal situation.

ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
CTxMemPool::accept() : accepted ce19781d8273723d7e6655375852169181878c8943334a583679c8c95886b699 (poolsz 166)
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
CTxMemPool::accept() : accepted e3d5d05916e4eb9435c79dd1df8d1c423c9406c62f7f1730bf8b75beaebdba46 (poolsz 167)
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
CTxMemPool::accept() : accepted 31910afe6870a355ba775adc7faaf1341034e74e97314d1839406f7f594e5171 (poolsz 168)
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
CTxMemPool::accept() : accepted b7096332ebf4b80972764a2a9aefef2fd9d23109c6d8be6e2b534d4a45dd25cb (poolsz 169)
CTxMemPool::accept() : accepted fb398b423b90632cb922a6db6b7aae75b54143e31f30e8517f42a718d37bc9ca (poolsz 170)
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2
ThreadRPCServer method=getblockhash
ThreadRPCServer method=getblock
ThreadRPCServer method=getinfo
keypool reserve 2
keypool return 2

Is there any progress indicator? It takes a lot of time to sync. with tor.

Can you give any more details? What do the logs report, anything of note?

Is ultrasurf compatible with btc?

I have a problem with bitcoin armory - if I configure bitcoin to use the tor proxy, armory never synchronizes.

Ubuntu 12.04, 17, 64bit

Ideas?

interesting. never thought about it like that.

If bandwidth is a factor and tor isn't providing enough you could simply tunnel (via ssh or vpn) your traffic elsewhere (i.e. not to the computer next to you) and remain protected in your specific scenario. But it's far more likely if your being watched you need to start using live systems to keep them clean, boot off dvd and load to ram only store docs. It's a pain but so is not having privacy.

Cheers.

Indeed good to know! 

@Foxpup: What about the idea of running a node to obfuscate transactions?

I suspected this. Thanks.

Yes. Use Tor to avoid this.

No. Bitcoin does not use encryption.

In order to see all thats going on on your internet connection that traffic would have to be in cleartext or the attacker would need root certificate (which seems not entirely impossible).
From what i've understood the scenario/attack you mention would be rendered useless in case you run a node as such should mix your transactions with other transactions being forwarded to your node.
What about changing addresses in some random pattern and transferring to them from other inet-connections to provide a higher level of obfuscation? Would that possibly help?

Assuming there is no link between me and my addresses.

An attacker seeing all that is going on on my internet connection, could take a note of all transactions that is first sent from my location, then conclude that I made those transactions and therefore link me to the addresses in the transaction.

Is this attack feasible in practice? Are the powers that be, capable of doing this on a large scale?