At the moment, it always assumes the incoming port is 8333, so it would tell other bitcoin nodes to connect to router:8333 even if you're redirecting from another port number.

I'm not in a big hurry to fix this because I can't think of any benefit to having more than one incoming connection port.  If you're providing one incoming port, then you've done your bit to help the network.  Having two incoming ports to the same person doesn't help redundancy.

If you have many computers, then using the -connect switch on most of them to connect locally makes more sense.

SheriffWoody:
Bitcoin addresses you generate are kept forever.  A bitcoin address must be kept to show ownership of anything sent to it.  If you were able to delete a bitcoin address and someone sent to it, the money would be lost.  They're only about 500 bytes.

sirius-m:
Thousands of own addresses should not be any problem at all.  If you've generated 50000 BTC, then you already have 1000 own addresses, one for each 50 generated.  Those are hidden, they're not shown in the UI.

It would be a good idea to add a little code that keeps giving the same address to the same IP.  Here's what I did in C++ to keep giving the same key (aka bitcoin address) until they use it:

    // Keep giving the same key to the same ip until they use it
    if (!mapReuseKey.count(pfrom->addr.ip))
        mapReuseKey[pfrom->addr.ip] = GenerateNewKey();
    
    ...sends the key mapReuseKey[pfrom->addr.ip]

...later...

    // Received something with this key
    mapReuseKey.erase(pfrom->addr.ip);

If it's not convenient to know when you've received, just clear the cached keys every 20 minutes.

I want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address.

Does it happen every time you run it, or just happened once at some random time?

I've never seen that fail before.  It's a call to OpenSSL that I assumed would never fail, but I put an error check there just in case.  I can't imagine how it would fail.  Out of memory maybe.

The code is:

key.h:
    EC_KEY* pkey;

        pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
        if (pkey == NULL)
            throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");

NID_secp256k1 is a constant.

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer.



I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page.  Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in.  It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog.  You'd still have to press Send.  We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.

That's a good idea.  At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel.

When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes).  It's like generating a new PGP private key, but less CPU intensive because it's ECC.  The address space is effectively unlimited.  It doesn't hurt anyone, so generate all you want.

Mihalism Multi Host is a popular open source PHP file hosting server.

It's geared toward image hosting, but I think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting.  They need the limits to keep it reasonable as a free service, but if we bolt on a Bitcoin payment mechanism, the limits could be relaxed.

It doesn't have a bunch of client side scripting or anti-embedding junk to rip out.  It generates standard links that work normally.

There's a turnover churn in these free hosting sites.  Small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth.  Any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs.  It's a perfect example of a service where the needed price point is in the no-man's-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment.  It's in the gap between 0 and 19.95.  The best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders.  It can't really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site.

An example of a site running the software:
http://www.imagez.ws/

Forum:
http://www.mihalism.net/

Download:
http://code.google.com/p/mihalismmh/

What do you think?  If I made a Bitcoin payment integration for this, would anyone be interested in running it?  It might be the first fully automated service available to buy with Bitcoins.  The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops.  It would give a normal link directly to the file.

Title changed.

It helps that we have someone with actual experience running a proxy service.  Do you think Psiphon is the best one currently?  (sometimes the one you run was the best when you started but you found better ones later)

LR and Pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that.  The possibility to cash out through them would help support the value of bitcoins.

Bitcoin has unique properties that would be complementary.  LR/Pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts.  Bitcoin, on the other hand, is easy to get in small amounts anonymously.  It would be convenient to buy LR/Pecunix with bitcoins rather than through conventional payment methods.

Most customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it.

It's unrelated.  There wasn't anything there when I started.

The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator.  Fortunately, it's standard for open source projects to be .org.

That's a great idea.  There's a thriving business in those services, but I've always thought the standard payment methods are at odds with privacy minded customers.

Would you consider making your software freely available so anyone could easily set one up?  I know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server.

I wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system?

Thanks soultcer for talking with the Freenode staffer.  Good to know it's OK at the current size, and now they know who we are.  They're supportive of projects like TOR so I hope they would probably be friendly to us.  We don't want to overstay our welcome.  If we get too big, then by the same token, we're big enough that we don't need IRC anymore and we'll get off.

We only needed IRC because nobody had a static IP.  In the early days there were some steady supporters, but they all had pool-allocated IPs that change every few days.  IRC was only intended as a temporary solution.  Bitcoin's built-in addr system is the main solution.

Bitcoin can get the list of IPs from any bitcoin node.  In that sense, every node serves as a directory server.

When there are enough static IP nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list.

How do you think we should compile the seed list?  Would it be OK to create it from the currently connected IPs that have been static for a while?

BTW, if we want to supplement by deploying separate directory server software, may I suggest IRC?  IRC is a good directory server (I've heard it has other uses too), and there are mature IRC server implementations available that anyone can run.   Bitcoin's IRC client implementation is already thoroughly tested.

When you want to upload an image to embed in a forum post, there are services like imageshack, but because they're free, they limit the number of views.  It's a minuscule amount of bandwidth cost, but they can't just give it away for free, there has to be something in it for them.  It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing.

It's worse if you want to upload a file for others to download.  There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads.

It would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins.  Anyone with some extra bandwidth quota could throw it on their webserver and run it.  Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles.  Ideally, it should be MIT license or public domain.

Services like this would be great for anonymous users, who have trouble paying for things.

It sets different priorities for each thread.  The generate threads run at PRIO_MIN.  The other threads rarely take any CPU and run at normal.

#define THREAD_PRIORITY_LOWEST          PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL    2
#define THREAD_PRIORITY_NORMAL          0

The priorities converted from Windows priorities were probably from a table like this:

   "The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.

nice value    Win32 Priority
-20 to -16    THREAD_PRIORITY_HIGHEST
-15 to -6    THREAD_PRIORITY_ABOVE_NORMAL
-5 to +4    THREAD_PRIORITY_NORMAL
+5 to +14    THREAD_PRIORITY_BELOW_NORMAL
+15 to +19    THREAD_PRIORITY_LOWEST"

If you have better values, suggestions welcome.

Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes.  If that's not true, maybe it accounts for unexpectedly setting the priority of the whole app.

    // threads are processes on linux, so PRIO_PROCESS affects just the one thread
    setpriority(PRIO_PROCESS, getpid(), nPriority);

sirius-m debugged this, it was 64-bit related. 

The fix is now available on SVN, file util.cpp.

When there's enough scale, maybe there can be an exchange site that doesn't do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works.

To make it safer, the exchange site could act as an escrow for the bitcoin side of the payment.  The seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller.  The exchange service doesn't handle any real world money.

This would be a step better than e-bay.  E-bay manages to work fine even though shipped goods can't be recovered if payment falls through.

We have the standard icon sizes, and the full size scales nicely to anything else.

I added the full size to the first post.

In the Windows world, "unicode" means UTF-16 (wchar).

2.8 has two build variations, ANSI and UTF-16 (unicode).  The UTF-16 version is the "unicode" version provided in the Debian package.  I believe 2.8 and its UTF-16 build labelled simply "unicode" has been the source of build problems described in the forum.  We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell.  We cannot compile with UTF-16.

2.9 has only one version, UTF-8.  On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8.  On Linux I assume the codepage is already UTF-8.  By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization.

Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given.

Curious, why is it incredibly hard to provide wxWidgets 2.9.0?  If you mean for users, that's why we static link it.

It's unfortunate that we require so many big dependencies, but we need them all.  At least on Debian/Ubuntu, all but wxWidgets are available as packages.  Eventually they'll provide a 2.9 package.

I don't know how to do SVG, but I did the original very large, over 500 pixels across, so it can be scaled down.  I'll give the original when I'm finished.

I had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they're ugly blurry and inconsistent.  Such is the challenge of making icons.  The original will be good for scaling to custom sizes between 48 and 500 but not smaller.

Are you using wxWidgets 2.9.0?  I don't recommend using anything other than 2.9.0.

It looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxBase.

Removing -D__WXDEBUG__ from bitcoin's makefile would probably solve it.

If that doesn't work and you just want to get it working, you could edit wxWidgets include/wx/arrstr.h, line 167 and comment out the wxASSERT_MSG.