Bitcoin Forum
June 19, 2021, 07:37:14 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 3 [All]
  Print  
Author Topic: $250 Bounty Offered (Was $2000-$2500)  (Read 6471 times)
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 03:00:11 AM
Last edit: February 01, 2011, 11:15:16 PM by The Madhatter
 #1

Hello all,

I am offering a personal bounty of $2K USD $250 USD for the following features to be added into Bitcoin. I'd code them myself, but time restraints won't permit me to. Let me hire you. Smiley

1. Bitcoin should run its P2P operations in straight SSL. It should look like FF talking to Apache to any DPI. See the Tor source code. Most of the work is done already. REPEALED - See discussion.

2. On first run Bitcoin should select a random high TCP port (>1024) and save it to the bitcoin.conf. (something like "listenerport=8972"). This port should contain the new SSL-only listener. Do we need to keep the old port 8333 listener running for compatibility for a while? REPEALED - The port number should be selectable by the user; not random. See discussion.

3. UPnP support. Bitcoin should port forward the chosen high TCP port automatically. (Possibly port 8333/tcp too, if the answer to the question above is "Yes"). The GUI/command line should have a UPnP off/on toggle. It should be "on" by default. $250 Bounty still offered. UPnP should be off by default on the Linux build.

It's just a matter of time before Bitcoin is blocked in all of "those" countries that have oppressive regimes. We need to resist stuff now before Bitcoin gains traction. I'm not looking to reinvent the wheel here (Tor). I just want to make it more resistant to DPI blocking-related attacks. Better off with a distribution of Bitcoin with Tor included. Hopefully those under repressive regimes already know about/use Tor. Having Tor installed offers other benefits besides Bitcoin.

If these 3 features are implemented in the next 30 days, I'll throw in an additional $500 USD. Payable in Bitcoin or in pre-loaded VISA cards from Bitcoin2CC - your choice.

The Madhatter
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1624131434
Hero Member
*
Offline Offline

Posts: 1624131434

View Profile Personal Message (Offline)

Ignore
1624131434
Reply with quote  #2

1624131434
Report to moderator
1624131434
Hero Member
*
Offline Offline

Posts: 1624131434

View Profile Personal Message (Offline)

Ignore
1624131434
Reply with quote  #2

1624131434
Report to moderator
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337
Merit: 263


View Profile
January 29, 2011, 05:39:27 AM
 #2

1) SSL would require all clients to upgrade.

2) Random TCP ports could be annoying for users running other services on their computers on certain ports when Bitcoin decides to use them.

3) UPnP would really be useful with all those NAT gateways.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 4144
Merit: 8490


View Profile
January 29, 2011, 07:23:25 AM
 #3

1. Bitcoin should run its P2P operations in straight SSL. It should look like FF talking to Apache to any DPI. See the Tor source code. Most of the work is done already.

Bitcoin is entirely different. Tor has a few centralized servers that can distribute certificates, but Bitcoin does not. You could use encryption without authentication, but this would not prevent men-in-the-middle from intercepting your traffic: it would just be obfuscation. Including secure encryption might be impossible without some sort of friend-to-friend system.

Quote
2. On first run Bitcoin should select a random high TCP port (>1024) and save it to the bitcoin.conf. (something like "listenerport=8972"). This port should contain the new SSL-only listener. Do we need to keep the old port 8333 listener running for compatibility for a while?

The official client won't make outgoing connections to non-standard ports, so this would not be good for the network.

Quote
I'm not looking to reinvent the wheel here (Tor).

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1015


View Profile
January 29, 2011, 07:28:17 AM
 #4

2. On first run Bitcoin should select a random high TCP port (>1024) and save it to the bitcoin.conf. (something like "listenerport=8972"). This port should contain the new SSL-only listener. Do we need to keep the old port 8333 listener running for compatibility for a while?
The official client won't make outgoing connections to non-standard ports, so this would not be good for the network.

This is a deficiency in the official client, and should be fixed.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
gene
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
January 29, 2011, 09:51:32 AM
 #5

2. On first run Bitcoin should select a random high TCP port (>1024) and save it to the bitcoin.conf. (something like "listenerport=8972"). This port should contain the new SSL-only listener. Do we need to keep the old port 8333 listener running for compatibility for a while?
The official client won't make outgoing connections to non-standard ports, so this would not be good for the network.

This is a deficiency in the official client, and should be fixed.


Agree. However, that random port stuff you are proposing with all the windows specific UPnP BS is probably not such a great idea. I, personally would prefer that client simply takes on command line IP address and port to listen. Simple, easy and portable solution.

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

OT: I am interested to know how you can claim "20+ years of experience with Linux and FreeBSD," since Torvalds didn't even begin to work on Linux until 1991 and FreeBSD wasn't released until late 1993.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1018


View Profile
January 29, 2011, 12:39:49 PM
 #6

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.

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.

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.

gene
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
January 29, 2011, 02:31:21 PM
 #7

OT: I am interested to know how you can claim "20+ years of experience with Linux and FreeBSD," since Torvalds didn't even begin to work on Linux until 1991 and FreeBSD wasn't released until late 1993.

LOL, I've been wondering when someone would spot this one.

There was minix and xenix around in 1990-1991 as well as bunch of other unixes, I kind of counted them in. Some FreeBSD testing code was floating around well before the original release. If you search some old email archives and FIDO 'echos' around 1991 you might be able to spot a few posts of mine here and there, particularly if you can read Russian. Keyword 5010/47 might fetch some hits too.



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

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2506
Merit: 1026



View Profile
January 29, 2011, 03:23:29 PM
 #8

However, that random port stuff you are proposing with all the windows specific UPnP BS is probably not such a great idea.
Random ports might be a problem if they conflict with other services, but UPnP never hurt anyone. What do you mean Windows-specific? UPnP is implemented by all the major Linux router platforms, and is a very nice way to avoid manual setup of port forwarding.

gene
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
January 29, 2011, 03:44:02 PM
 #9


I am maybe behind the curve on this one, but I would not let any of this UPnP anywhere near my servers. If "all the major Linux router platforms", whatever that means, implemented UPnP it's their problem.

My point is that, the first things first, start with IP and port in command line, than maybe optional and turned off by default UPnP or whatever.

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.

I feel that we are hijacking this thread. Better to get back on topic.


It seems fair to discuss the merits of UPnP inclusion here. I tend to agree with you, just because of potential security issues.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1018


View Profile
January 29, 2011, 04:01:06 PM
 #10

The point of UPnP is to help users who are running the software at home. It's got nothing to do with server deployments of bitcoind. I guess the command line UI would have it switched off by default the and Win/Mac GUIs would have it switched on.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2506
Merit: 1026



View Profile
January 29, 2011, 04:35:00 PM
 #11

UPnP is only a "security" issue if you're treating hacks like NAT as some kind of a firewall (which it's not intended to be). NAT is a hack to allow multiple computers/devices to access the WAN from a single WAN address. It isn't supposed to block anything. Blocking incoming connections has merely been a bug in the NAT implementations. UPnP fixes this bug by giving endpoints the ability to tell the router what ports it expects a connection on, so the router can correctly pass that traffic through.

If you want a firewall, go ahead and get one (or install it as software). But that is unrelated to the bug that UPnP fixes.

0x6763
Guest

January 29, 2011, 04:41:53 PM
Last edit: January 29, 2011, 05:12:46 PM by 0x6763
 #12

On my networks, one of the first things I do when setting up a router is disable UPnP due to security concerns (malware often likes to open ports on UPnP enabled routers to further expose the network and help keep their botnet alive).  However, I think UPnP support would be great for non-techie home users that don't know enough to disable UPnP on their router's in the first place...If they're going to have UPnP enabled, we might as well take advantage of it.

I think some sort of built-in encryption would be really good to have, but obviously a central authority is obviously out of the question...hmmm...unless that central authority happens to be Bitcoin (or a similar system).  IDEA: User/node generates a key pair for encryption between nodes, the node creates a special transaction to "register" the public key, user pays a transaction fee or 0 or more, and then if/when it gets added to a block, the entire network has your public key for encrypted communications.  Obviously there's a lot more details to work out on this, and barriers for non-technical users, etc, but it's something to start brainstorming around.  (This is very similar to what's been on my list of things to think about for a Bitcoin-based DNS to have SSL certs associated with domains as well so people don't need to buy them from a "trusted" third-party like Verisign, etc.)  (EDIT: For communication between nodes, just generating key pairs for encryption and sharing the public keys upon first contact with the network and then spreading them via the 'addr' message (assuming a sufficiently bootstrapped Bitcoin network) would probably be enough for encrypting the traffic, and a central public key registry is probably unnecessary for this purpose.)

I would like ports other than 8333 to be supported, as well.  Also IPv6.
caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1002



View Profile
January 29, 2011, 04:51:15 PM
 #13

May I ask why do you want public data to be exchanged through encrypted connections? I don't see the gain in that. If it's anonymity you want, encryption won't help you...
0x6763
Guest

January 29, 2011, 05:13:09 PM
 #14

May I ask why do you want public data to be exchanged through encrypted connections? I don't see the gain in that. If it's anonymity you want, encryption won't help you...

So ISP's can't target and block Bitcoin as easily?
gene
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
January 29, 2011, 05:33:13 PM
 #15

Yep, it is basically deep packet inspection evasion technique. I wonder how long it would take them to ban all encrypted packets  Angry

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

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1002



View Profile
January 29, 2011, 06:16:49 PM
 #16

May I ask why do you want public data to be exchanged through encrypted connections? I don't see the gain in that. If it's anonymity you want, encryption won't help you...

So ISP's can't target and block Bitcoin as easily?

What's the incentive for ISPs to do that, despite government pressure?
Because if it's the government who's after you, they can do just like hadopi in France. Encryption alone won't help you, you need something like Tor.

Maybe a better thing would be to offer a bundle Bitcoin client + tor proxy with everything already configured, for those who aren't geek enough to configure it by themselves. Just like the firefox bundle that torproject offers.

I don't see a need to add encryption to the core bitcoin software.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:30:48 PM
Last edit: January 29, 2011, 09:37:59 PM by The Madhatter
 #17

1) SSL would require all clients to upgrade.

How so? The current build links against openssl already. Preserving the existing port 8333 listener thread would maintain backward compatibility for some time.

2) Random TCP ports could be annoying for users running other services on their computers on certain ports when Bitcoin decides to use them.

It's random selection upon install. The user can, of course, change the port. Look at how I2P works upon first install.

3) UPnP would really be useful with all those NAT gateways.

Uh huh. Smiley
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:38:33 PM
Last edit: January 29, 2011, 09:38:21 PM by The Madhatter
 #18

Bitcoin is entirely different. Tor has a few centralized servers that can distribute certificates, but Bitcoin does not. You could use encryption without authentication, but this would not prevent men-in-the-middle from intercepting your traffic: it would just be obfuscation. Including secure encryption might be impossible without some sort of friend-to-friend system.

Ahem.. Key exchange. Generate a cert upon install.

The official client won't make outgoing connections to non-standard ports, so this would not be good for the network.

I want this bundled with the official client. I'm not looking for a fork.

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

Edit: A key cache similar to how SSH handles keys could be added to Bitcoin to prevent MITM attacks.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:39:49 PM
 #19

This is a deficiency in the official client, and should be fixed.

+1

I'd like to run bitcoind on port 443. I want it to look like Apache/SSL.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:42:42 PM
 #20

Agree. However, that random port stuff you are proposing with all the windows specific UPnP BS is probably not such a great idea. I, personally would prefer that client simply takes on command line IP address and port to listen. Simple, easy and portable solution.

It should choose a random port upon install. If you have a port specified in the bitcoin.conf, it will use that explicitly. Us smarter folks would likely specify a port. (I'd use 443). Smiley

Think about the average Joe. They never toy with the defaults. If we want the network to be resistant to DPI filtering we need this.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:45:20 PM
 #21

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.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:51:10 PM
 #22

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
Guest

January 29, 2011, 07:52:43 PM
 #23

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
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 07:53:35 PM
 #24

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

 Cheesy I used to run FidoNet BBSes where I live.
caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1002



View Profile
January 29, 2011, 08:10:13 PM
 #25

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
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
January 29, 2011, 08:34:07 PM
 #26

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.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1015


View Profile
January 29, 2011, 08:42:33 PM
 #27

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.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 09:29:28 PM
 #28

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
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 09:33:28 PM
 #29

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. Tongue
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 09:36:28 PM
 #30

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? Tongue
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 09:47:20 PM
 #31

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

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? Tongue
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 09:54:14 PM
 #32

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
Guest

January 29, 2011, 10:02:04 PM
 #33

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

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
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


My avatar pic says it all


View Profile
January 29, 2011, 10:11:21 PM
 #34

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

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

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. Wink
0x6763
Guest

January 29, 2011, 10:36:54 PM
 #35

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
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1015


View Profile
January 30, 2011, 01:12:06 AM
 #36

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.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1015


View Profile
January 30, 2011, 03:30:03 AM
 #37

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

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1002



View Profile
January 30, 2011, 11:50:03 AM
 #38

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
Legendary
*
Offline Offline

Activity: 1106
Merit: 1002



View Profile
January 30, 2011, 11:59:02 AM
 #39

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

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
Guest

January 30, 2011, 03:24:58 PM
Last edit: January 30, 2011, 03:37:46 PM by 0x6763
 #40

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
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1018


View Profile
January 30, 2011, 04:55:35 PM
 #41

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.
da2ce7
Legendary
*
Offline Offline

Activity: 1220
Merit: 1002


Live and Let Live


View Profile
February 05, 2011, 06:16:50 AM
 #42

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

One off NP-Hard.
CaptainPicard
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
March 21, 2011, 10:53:53 PM
 #43

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.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 501


View Profile
March 21, 2011, 11:01:15 PM
 #44

3. UPnP support. Bitcoin should port forward the chosen high TCP port automatically. (Possibly port 8333/tcp too, if the answer to the question above is "Yes"). The GUI/command line should have a UPnP off/on toggle. It should be "on" by default. $250 Bounty still offered. UPnP should be off by default on the Linux build.
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). 

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 501


View Profile
March 22, 2011, 06:23:27 PM
Last edit: March 22, 2011, 06:57:39 PM by BlueMatt
 #45

3. UPnP support. Bitcoin should port forward the chosen high TCP port automatically. (Possibly port 8333/tcp too, if the answer to the question above is "Yes"). The GUI/command line should have a UPnP off/on toggle. It should be "on" by default. $250 Bounty still offered. UPnP should be off by default on the Linux build.
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).  
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

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
genjix
Legendary
*
expert
Offline Offline

Activity: 1232
Merit: 1039


View Profile
March 24, 2011, 03:30:30 AM
 #46

From: http://bitcointalk.org/index.php?topic=4761.0

<spam>
---------------------------

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.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 755
Merit: 501


View Profile
April 12, 2011, 09:37:19 PM
 #47

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 Smiley

Bitcoin Core, rust-lightning, http://bitcoinfibre.org etc.
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Pages: 1 2 3 [All]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!