Live data from Hacker News

Bitcoin over Tor isn't a good idea

arxiv.org

21–30 of 40 posts

Re: Bitcoin over Tor isn't a good idea

#21
post #9

Earlier quoted context omitted.

You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."

That's the way a blockchain works though. If there is a bug in the client that 99% of people use then of course you'll have forking blockchains. And all of this matters less anyway, because clients can fallback to blockchain.info if there is a fork detected, and just warn the user that the client may have a bug.

The bitcoin client has a fallback to blockchain.info when it detects a fork? What? I'm not sure I understand what you're saying.

Re: Bitcoin over Tor isn't a good idea

#24
post #9

" Many of these details do not appear in any specifications and were obtained by a careful analysis of the corresponding source code. This is especially true for Bitcoin for which there exists no official documentation except for the original white paper [14] and Bitcoin Wiki[3]." Well that seems a bit odd.

You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."

In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable.

https://en.bitcoin.it/wiki/CVE-2010-5139

Another interesting case is when bitcoind 0.8 changed the underlying database from BerkeleyDB to LevelDB. Due to different database lock limits, bitcoind 0.7 couldn't process a block that bitcoind 0.8 could. For 6 hours, there was a fork where old clients were using a totally different blockchain than new clients, because of this single block they couldn't handle. This is what patio11 means, that you have to be bug-for-bug compatible with the reference implementation.

http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-bl...

Re: Bitcoin over Tor isn't a good idea

#26
post #5
post #3

Earlier quoted context omitted.

In fact Bitcoin design does not contain elements hinting that anonymity was ever a goal. People using Bitcoin over Tor might just want to circumvent censorship aka Tor as glorified proxy.

Right, but it doesn't work. That's the whole point of the article. Tor+random app usually equals massive vulnerability. I should add I learned that the hard way trying to integrate Tor with OpenBazaar. What might be fun is stenography over the Tor protocol. Anybody interested?

There is a project that uses stenography to hide the Tor protocol from inspection. I need to tie up a few loose ends to some of my branches for it (I am not the originator, just a contributor) but have gotten caught up in schoolwork these last few months. Any assistance is appreciated!

[0] https://github.com/TheTorProject/stegotorus [1] https://github.com/SRI-CSL/stegotorus

Re: Bitcoin over Tor isn't a good idea

#27
post #9

" Many of these details do not appear in any specifications and were obtained by a careful analysis of the corresponding source code. This is especially true for Bitcoin for which there exists no official documentation except for the original white paper [14] and Bitcoin Wiki[3]." Well that seems a bit odd.

You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."

The right mindset to understand the requirements of Bitcoin client design is, I think, that of someone trying to clone an online game client (e.g. Starcraft) in a way that doesn't experience network state desynchronization. You can do whatever you like in your client UI-wise, but the "rules engine" of your implementation absolutely must reduce an incoming event stream into the same world state as the reference implementation.

For this kind of problem, the easiest solution (when possible) is to extract the "rules engine" component of the reference implementation into a library, and then have every other client just use it (and maybe contribute to its development) instead of trying to write something bug-for-bug compatible with it.

When you think about it, web browser rendering has much the same implementation-consensus problems as Bitcoin. And what do we see there? Everyone sort of converging toward just using the "rules engine" known as WebKit.

Re: Bitcoin over Tor isn't a good idea

#28
post #24
post #9

Earlier quoted context omitted.

You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."

In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable. https://en.bitcoin.it/wiki/CVE-2010-5139 Another interesting case is when bitcoind 0.8 ch…

> In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable.

That was in 2010. Most of the users take certain level of risk, also different kinds of people have different risk appetite. If you really think this is still a relevant risk, then probably you shouldn't use cryptocurrencies at all. Stay with the safe and proven almighty dollar.

Re: Bitcoin over Tor isn't a good idea

#30
post #5

Earlier quoted context omitted.

Right, but it doesn't work. That's the whole point of the article. Tor+random app usually equals massive vulnerability. I should add I learned that the hard way trying to integrate Tor with OpenBazaar. What might be fun is stenography over the Tor protocol. Anybody interested?

There is a project that uses stenography to hide the Tor protocol from inspection. I need to tie up a few loose ends to some of my branches for it (I am not the originator, just a contributor) but have gotten caught up in schoolwork these last few months. Any assistance is appreciated! [0] https://github.com/TheTorProject/stegotorus [1] https://github.com/SRI-CSL/stegotorus

Cool, I'll check it out. I was thinking more along the lines of hiding messages in the Tor protocol itself, rather than hiding Tor traffic (which is desperately needed.)
Post reply on HN