Topic: $250 Bounty Offered (Was $2000-$2500) (Read 6656 times)

UPnP pulled into mainline (79706a8e48a043b9ca83216ba9cbb7413e81710d) resolving all of the bounties in this thread.  If you want to pay out, a payout in BTC to the address in my signature would be nice . 

From: https://bitcointalksearch.org/topic/new-bitcoin-features-4761


---------------------------

As per this and this post, me & dissipate have setup a new site:

http://bitcoin.cz.cc

You propose features for Bitcoin. The front page shows a mix of the most donated proposals (10) and newest ones (5). Once the feature is implemented in Bitcoin then the bounty goes to the author and the proposal is deleted.

Think of it as an experiment into future methods for bitcoin based free software dev. Right now I'm just putting it out there to see what happens. If it grows then we can think about turning it into a bug tracker type thing with tickets, comments, statuses, assignment of tickets and search.

##############
For this to work, people have to know about it. Add it to your signatures!
"Vote up your favourite ideas to go into Bitcoin"
##############

Source code.

I take that back, WxGUI stuff is done.  All thats left to do is get miniupnpc to compile on Windows and link properly with bitcoin without causing segfaults or implement MS' own UPnP library in bitcoin for windows.  Ill split the bounty 200/50 for anyone who can get that working.

Current version available at https://github.com/TheBlueMatt/bitcoin/tree/upnp

I'll split that if someone addes GUI toggle to my current branch and gets miniupnpc to compile properly on windows.  (My branch currently works on Linux/OSX via a command line toggle). 

Here is how you would do SSL without needing CA certificates, and without man in the middle attacks.

Bitcoin is already distributed with the IP addresses of some initial seed nodes.
It would be changed so that it would also include the SSL public keys of those seed nodes.
This establishes a chain of trust.

Bitcoin would make a connection to those seed nodes to learn of other peers as it does now.
When the seednode refers a peer to the client, it also includes the peers SSL public key.

A bitcoin server must not accept incoming connections, unless the peer already knows its public key.
This makes it difficult for an attacker to connect to a specific target node it wants to monitor, it would first have to get the certificate referral from another node.

Using this method establishes a chain of trust starting with the public keys in the bitcoin program, and all nodes the client will eventually connect to in its lifetime.
It prevents any man in the middle attacks on the client.

This is the method used by freenet (I may be missing some details, see freenet source code).

As for older clients not supporting SSL there could be a transition period.
Initially the new version would try to make a SSL connection and if that does not work it falls back to the non-ssl method.
Yes this is vulnerable to an MITM attack by pretending a node doesn't do encryption.
After the SSL version has been out for some time and most people have upgraded, future versions would no longer accept unencrypted connections.

One of my Goals is to get Bitcoin Working on Freenet https://www.bitcoin.org/smf/index.php?topic=2312.0

Then one could download, install, and use bitcoin from a darknet.

I think if the goal is to avoid detection+blocking then having the ability to run the protocol over HTTP by doing GETS and POSTS would work much better (no ssl).

I have a few issues with the idea of using SSL as obfuscation.

One is that some countries do in fact block or simply forbid encrypted connections. Spotting encrypted connections is easy because the data looks random whereas unencrypted protocols don't.

Examples: Tunisia "solved" SSL on the Google login page by simply hijacking the connection before the SSL connection was established. They solved it on Facebook by just blocking SSL entirely and forcing users to downgrade to the unencrypted version. Chinas GFW has been known to simply terminate connections that look like they're encrypted when they're leaving the country.

To really hide you need to look like regular web traffic as much as possible and you need the ability to rapidly change how the protocol looks. Then nothing but cutting off all web access will work.

How about this strawman proposal. Currently BitCoin travels over TCP port 8333. We can build an HTTP proxy for this such that a GET to

 http://www.some-site.com/bc/random-words?v=1

is equivalent to waiting for a message to arrive and a POST to that same URL is like sending a message. BitCoin is an entirely message based protocol and messages are small, so it will work OK. A cookie is used to keep the individual requests tied together to a logical connection. The proxy site then relays these messages into the p2p network as per usual. The random words could be anything and just pulled from a dictionary.

If you wanted to get really intense you could encode the messages steganographically into JPEGs or random HTML content.

To a DPI engine, this looks just like regular web browsing. There's some GETs, some POSTs, some cookies and the downloads/uploads are just binary. As long as there's no specific signature (like the current protocols beginning of message markers) this is probably quite hard to detect.

At the start, this can be implemented independent of the BitCoin client. Later on it could be integrated. Proxy lists could be distributed via a regular text file that has a signature on the end. A new command could be added that allows for new proxy lists to be downloaded from an existing proxy, to mimic the address discovery of the existing TCP based network.

Anyone who is serious about claiming this bounty should team up with a Snort expert to make sure that whatever solution they come up with is actually difficult to build detection scripts for.

The bitcoin protocol has space for an IPv6 address and port in it's address messages.  Using hostnames/.onion addresses would require a modification to the protocol or maybe an ugly hack.

EDIT: Maybe it wouldn't require a change, as Tor addresses (without the .onion pseudo-TLD) are 16 characters long, which fits in the IPv6 address space.  I don't know what the intentions of the 'services' field in the Network Address structure is for, but it's 8 bytes long and typically/always has the value of 1. Maybe setting another bit in that value to 1 could be used to denote that it's a .onion address, and now you have Tor compatible address messages. (Obviously these would be junk addresses to Bitcoin nodes that don't understand them the Tor 'services' value.)

EDIT 2:
Example for http://axqzzpkfwezf3kku.onion:

Here's a normal Bitcoin Network Address message:

Bitcoin Network Address message for Tor address:

Well, I was thinking of an embedded proxy that would be used only for bitcoin. If the user wants to protect his/her other traffics, he should look on how to.
Automatically redirecting user normal traffic to a tor proxy just because s/he installed bitcoin would reasonably piss off some users.


Why would they? It's not like Tor depends on bitcoin to work better, it's more the other way around.


This would be nice, integrating the bitcoin protocol with hidden services... I don't know how the protocol currently works, but I suppose there are messages to ask for other nodes, right? These messages could send not only IPs, but Tor hidden services addresses too.
I don't know why leave it up to the user to publish or not a hidden address though... I suppose one maybe have numerous hidden service addresses, right? Why not making it automatic? You connect and publish your hidden service address to your peers so they publish to theirs and so on...

If it's government censors, they don't need DPI nor fingerprinting, it's actually much simpler than that, all they have to do is to connect themselves to the P2P network in question and log the IPs that connect to them. SSL connections (or random obfuscation data) are useless.
This is what Hadopi is supposedly doing in France right now.

Yes.  I am very surprised that Tor and other VPN solutions do not already employ such obfuscation techniques?

To truly obscure traffic, one must (a) send the same length of data at regular intervals or (b) saturate all available bandwidth with data at all times.  Anything else is vulnerable to statistical analysis.  The "random data at random times" method is not very practical for most modern TCP-like messaging applications; also, "random data" + your app traffic may not equate to random data...

Quite true.

I suppose the P2P network could advertise a 'I require SSL' flag, during the normal course of globally propagating the bitcoin P2P node addresses.

And the bitcoin client could be changed to add an option that prefers SSL P2P nodes on TCP port 443.

Still, ultimately you do not need DPI to simply observe bursts of incoming and outgoing traffic behave (a) like bitcoin P2P and (b) unlike HTTP.  Application fingerprinting by packet sniffers is quite advanced.  A lot of information may be deduced even without access to the unencrypted plaintext.

Yes, using Tor for obfuscation would work (for as long as Tor is not blocked), and certainly that's better than not having that obfuscation. 


But the average user won't gain any benefits of using it for privacy, and may even lose privacy (and online accounts, and non-Bitcoin money, etc) without a good understanding of how Tor should be used.

By doing SSL on port 443, it would practically be indistinguishable from "acceptable" (to governments) bank sites, etc., assuming the government doesn't start requiring SSL certs be signed by the government instead of private companies.  The ISP can always check the certs of the nodes your node is connecting to and filter you that way...if it's not government signed, they block it.

Of course, once the number of Bitcoin users is great enough, it won't be in anyone's political interest to try blocking it, but then by that point there's little need for these obfuscation techniques anyway.  I guess the goal is to find a way to get it to that point.  Perhaps Tor can/will play a large role in that, I don't know.  I much prefer configurable ports and encryption for average users before Tor.

You're preaching to the choir.


Oh sure. Having some protection/obfuscation (to beat DPI stuff) is better than nothing. Wouldn't you agree? There are always other attack vectors that have to be considered. What about physical spying, for example?

Right now, a default installation of Bitcoin is so easily detected/blocked from the network layer. Shouldn't we be concerned? I certainly am.

I want Bitcoin to be unstoppable. A crazy spray of garbled packets that hide alongside regular HTTPS connections to banks. I want to make it so that blocking Bitcoin also means blocking "their" existing bank infrastructure as well.

Tor is very dangerous for those that do not know how to protect themselves already.  Using personally identifiable information over Tor defeats the purpose of using it in the first place.  Most things can be MITMed on the Tor exit nodes (even some SSL connections...google Moxie Marlinspike).  But using Bitcoin on Tor while using normal connections to communicate with those you wish to transact with also defeats the purpose of using Tor.  The average person that "does not know how to protect themselves already" is not ready for Tor.

That wouldn't work. DPI gear would just pick out the version string and send out some RST packets. The cops would then be dispatched to break some knee caps. :/

I suppose that could be done. I guess the user would also get other benefits from Tor as well, such as pseudo-anonymous browsing, etc.

I wonder if the Tor project could be convinced to just include Bitcoin with their bundle. We might be too far away from that. They don't seem to want to even touch Bitcoin. I was instructed to send my donations to the EFF instead of them.


It should automatically setup a Tor hidden service with a port forward back to Bitcoin too then. We can leave it up to the user to publish their .onion address/port number. It should also contain a list of "seed" nodes in the torrc. (Public hidden services to bootstrap from.)

Also, Bitcoin should at least let the user select a port other than 8333. It should also have UPnP support. Enabled by default on Windows/Mac, disabled by default on Linux/*NIX. Would that make the *NIX geeks happier about UPnP support?

Official client. What good would a fork be? So I can run it between me, myself, and I?

Exactly. I highly doubt the governments of the world will block banks, for example.

+1

I'm also an avid user of djb's daemontools. A foreground command line switch would be very nice.