$250 Bounty Offered (Was $2000-$2500)

[The Madhatter]

We should identify what core functionality bitcoin needs and use existing tools to extend how we use it, the way Unix tools do.

Less than 0.25% of the population uses *NIX. If we want mass adoption we need to focus more on the end user operating systems.

[1715158166]

1715158166

[1715158166]

1715158166

[1715158166]

1715158166

[1715158166]

1715158166

[1715158166]

1715158166

[The Madhatter]

Bear in mind that quite a few oppressive regimes actually own or can probably obtain SSL root certificates. I don't think of SSL as protecting me from governments and I'd suggest nobody else does either.

Yes. I understand what you are saying here. We should be at least obfuscating Bitcoin connections as FF+Apache connections. China, for example, can easily block Bitcoin at the moment - just filter one port: 8333. How sad.

China can't block every SSL connection. Commerce relies on SSL connections too heavily.

I understand and agree with what you're trying to do here. I also give you massive credit for being willing to put money where your mouth is. But beating an adversary with DPI isn't going to be easy - at the very least, somebody should put together a design doc or paper explaining their threat model and solution before you pay for it.

Check out the newer videos by Roger Dingledine. They explain the lessons they learned about keeping Tor from being blocked in China/Iran.

UPnP support on the other hand is a no brainer. I'd also be willing to contribute some coin (dollars/bits) towards implementation of that in the official client. The P2P network needs to be as dense as possible and using UPnP to reconfigure WiFi NATs is the best way to achieve a quick boost.

Totally. I think that UPnP should be on by default.

[0x6763]

So is the bounty for these features to be added to the official client, or would an alternate client that's 100% compatible with the official client while having these additional features count?

[The Madhatter]

Fair enough. I haven't heard of fidonet for a long, long time.

  I used to run FidoNet BBSes where I live.

[caveden]

Just use Tor with Bitcoin, then. They've already got this stuff solved.

99.99% of average people have no clue how to setup Bitcoin to use Tor.

Assuming that other people know as much as you/I/us know will kill this project. If we want mass adoption this software has to be robust, simple to use, and "just work". This includes when China/North Korea/"Insert bad government" blocks it.

We need to be proactive here. Not reactive. Telling people to install another program and educate them on how to chain them together is not a fix. It's a giant ugly "hack".

I agree with your concern about people not knowing how to protect themselves, but then, I think that better than adding unnecessary features to the main software, we should just offer preconfigured bundles, as I said on my last post.

An "anonymous bitcoin" bundle to be downloaded from the main project page, that would include the bitcoin software + an embedded tor proxy, everything preconfigured... this is better, imho, than adding SSL support to the bitcoin client.

[gene]

Just use Tor with Bitcoin, then. They've already got this stuff solved.

99.99% of average people have no clue how to setup Bitcoin to use Tor.

Assuming that other people know as much as you/I/us know will kill this project. If we want mass adoption this software has to be robust, simple to use, and "just work". This includes when China/North Korea/"Insert bad government" blocks it.

We need to be proactive here. Not reactive. Telling people to install another program and educate them on how to chain them together is not a fix. It's a giant ugly "hack".

I agree with your concern about people not knowing how to protect themselves, but then, I think that better than adding unnecessary features to the main software, we should just offer preconfigured bundles, as I said on my last post.

An "anonymous bitcoin" bundle to be downloaded from the main project page, that would include the bitcoin software + an embedded tor proxy, everything preconfigured... this is better, imho, than adding SSL support to the bitcoin client.

I agree, and this is more along the Unix "philosophy" that I mentioned earlier. The less code within bitcoin itself, the better. You can't exploit code that doesn't exist.

[jgarzik]

SSL is (a) a good additional to the bitcoin P2P protocol, even if anonymous, and (b) easy to integrate into the existing protocol.

As others have pointed out, SSL will not give you authentication, because you're still connecting to an untrusted party.  However, it will give you obfuscation, which has value.

Modern protocols implement SSL by including a "start SSL" message in their plaintext, unencrypted protocol.  That eliminates the need for multiple TCP ports as in the HTTP/HTTPS design.  bitcoin can implement SSL obfuscation by adding a start-ssl message immediately after the version message.  The version message will tell us whether or not the node supports SSL, making it easy to integrate SSL in a backwards-compatible manner.

Thus, bitcoin P2P nodes that wish SSL may request it, just like SMTP nodes that wish to use SSL for transiting email between untrusted nodes.

It is a step forward for the Internet, when most protocols use SSL by default, even if obfuscation is the only added value.

[The Madhatter]

I know that this thread is not a place for this, but one feature I would love to see is to have an option for bitcoind to work in foreground while printing logs to sdout. I hate to hack this thing up every time to have it running under djb's daemontools.

+1

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

[The Madhatter]

As long as businesses need to run VPNs and SSL websites, I think crypto will remain legal. Mimicking traffic patters in another matter, though.

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

[The Madhatter]

So is the bounty for these features to be added to the official client, or would an alternate client that's 100% compatible with the official client while having these additional features count?

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

[The Madhatter]

I agree with your concern about people not knowing how to protect themselves, but then, I think that better than adding unnecessary features to the main software, we should just offer preconfigured bundles, as I said on my last post.

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.

An "anonymous bitcoin" bundle to be downloaded from the main project page, that would include the bitcoin software + an embedded tor proxy, everything preconfigured... this is better, imho, than adding SSL support to the bitcoin client.

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?

[The Madhatter]

bitcoin can implement SSL obfuscation by adding a start-ssl message immediately after the version message.  The version message will tell us whether or not the node supports SSL, making it easy to integrate SSL in a backwards-compatible manner.

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

[0x6763]

I agree with your concern about people not knowing how to protect themselves, but then, I think that better than adding unnecessary features to the main software, we should just offer preconfigured bundles, as I said on my last post.

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.

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.

[The Madhatter]

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

You're preaching to the choir.

But using Bitcoin on Tor and non-Tor 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.

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.

[0x6763]

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. 

I guess the user would also get other benefits from Tor as well

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.

[jgarzik]

bitcoin can implement SSL obfuscation by adding a start-ssl message immediately after the version message.  The version message will tell us whether or not the node supports SSL, making it easy to integrate SSL in a backwards-compatible manner.

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

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.

[jgarzik]

Damn, now we are going to have to run everything via VPN's with some random noise going back and forth all the time in the background, to drive app fingerprinting engines mad.

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

[caveden]

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.

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.

[caveden]

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.

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.

I wonder if the Tor project could be convinced to just include Bitcoin with their bundle.

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

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

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

[0x6763]

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

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:

Code:

Network address:
 01 00 00 00 00 00 00 00                         - 1 (NODE_NETWORK? see services listed under version command)
 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
 20 8D                                           - Port 8333

Bitcoin Network Address message for Tor address:

Code:

Network address:
 02 00 00 00 00 00 00 00                         - 2 (a conceptual TOR_NETWORK value - implies .onion added to following 16 bytes)
 61 78 71 7a 7a 70 6b 66 77 65 7a 66 33 6b 6b 75 - "axqzzpkfwezf3kku" (.onion)
 20 8D                                           - Port 8333