Bitcoin Forum
December 11, 2016, 04:27:07 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: $250 Bounty Offered (Was $2000-$2500)  (Read 5797 times)
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile
January 29, 2011, 03:00:11 AM
 #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
1481430427
Hero Member
*
Offline Offline

Posts: 1481430427

View Profile Personal Message (Offline)

Ignore
1481430427
Reply with quote  #2

1481430427
Report to moderator
1481430427
Hero Member
*
Offline Offline

Posts: 1481430427

View Profile Personal Message (Offline)

Ignore
1481430427
Reply with quote  #2

1481430427
Report to moderator
1481430427
Hero Member
*
Offline Offline

Posts: 1481430427

View Profile Personal Message (Offline)

Ignore
1481430427
Reply with quote  #2

1481430427
Report to moderator
If you want to be a moderator, report many posts with accuracy. You will be noticed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481430427
Hero Member
*
Offline Offline

Posts: 1481430427

View Profile Personal Message (Offline)

Ignore
1481430427
Reply with quote  #2

1481430427
Report to moderator
1481430427
Hero Member
*
Offline Offline

Posts: 1481430427

View Profile Personal Message (Offline)

Ignore
1481430427
Reply with quote  #2

1481430427
Report to moderator
1481430427
Hero Member
*
Offline Offline

Posts: 1481430427

View Profile Personal Message (Offline)

Ignore
1481430427
Reply with quote  #2

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

Activity: 337


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

Activity: 2506


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: 1470


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, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
gene
Sr. Member
****
Offline Offline

Activity: 252


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


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


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: 2100



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


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


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: 2100



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



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

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
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


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



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.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490


My avatar pic says it all


View Profile
January 29, 2011, 07:30:48 PM
 #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


My avatar pic says it all


View Profile
January 29, 2011, 07:38:33 PM
 #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


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


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.
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!