Nodes stop trying to initiate connections once they have 15.  If you can accept incoming connections, then you can get well above that from nodes connecting to you, otherwise you max out at 15.

I don't know if there's any reason to have 15 connections.  Maybe it should be 10.

Since nodes that can only connect out are probably at or near 15 most of the time now, you should level off to an equilibrium.  45 suggests a ratio of 3 out-only nodes to every 1 in-accepting node.

The number of connections won't be a good gauge of the size of the network any more.  Someone should periodically IRC to the bitcoin channel on chat.freenode.net and count the number of users.  That gives you the total count of network nodes (except TOR nodes).

Block generation is again running ahead of pace.  We're in for another big step up in difficulty at the next adjustment in about 5 days.

I updated the SVN with changes to support translation.  Translatable strings are all enclosed in _(""), and we're using UTF-8 on all platforms.

When the program runs, it looks in the directory of the EXE for the file: locale\<langcode>\LC_MESSAGES\bitcoin.mo

<langcode> is the two letter code of the language your OS is set to, like "de" or "nl".

On Linux, it also looks for:
/usr/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
/usr/local/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
(are there other standard places it should look on linux?)

Here's a quick walkthrough using poedit to make a .po and .mo file:

- Download the bitcoin sourcecode from SVN
- In the trunk directory, mkdir locale\<lang>\LC_MESSAGES
- In poedit, File->New catalog->Paths tab
- Click the "New item" dotted rectangle button
- Put "../../.." and MAKE SURE TO PRESS ENTER to add the path
- Click OK
- Save the file as "bitcoin.po" in the LC_MESSAGES directory you made
- It should then scan the sourcecode and find about 170 strings
- If it didn't find anything, check Catalog->Settings->Path tab, make sure the "../../.." was added

When you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program).

2 seconds of latency in both directions should reduce your generation success by less than 1%.

Probably OK, but I'm not sure.  The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you're connected to until received.  If you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap.  Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck.

I thought about that but there wasn't a practical way to do smaller increments.  The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.

The algorithm aims for an average of 6 blocks per hour.  If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long.  It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.

Right now there isn't a port number setting to do that.  It's a feature yet to be implemented.  You can only set up your NAT to port-forward to one of the computers.  (I said something earlier about NAT port translation, but that wouldn't work, other nodes wouldn't know to connect to that port)

If you want, as a small optimization, you could run the rest of your computers as:
bitcoin -connect=<the IP of the first computer>

so they get all their network communication from the first computer and don't all connect over the net individually for the same information.  This saves bandwidth, although it doesn't use much bandwidth to begin with, so it wouldn't really matter unless you had tons of computers.

For redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them.  The first two are run normally, the rest are run like:
bitcoin -connect=<IP1> -connect=<IP2>

14/02/2010 0000000065465700000000000000000000000000000000000000000000000000

2009        1.00
30/12/2009  1.18   +18%
11/01/2010  1.31   +11%
25/01/2010  1.34    +2%
04/02/2010  1.82   +36%
14/02/2010  2.53   +39%

Another big jump in difficulty yesterday from 1.82 times to 2.53 times, a 39% increase since 10 days ago.  It was 10 days apart not 14 because more nodes joined and generated the 2016 blocks in less time.

Right.  Otherwise we couldn't have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating.  In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.  I'm sure that in 20 years there will either be very large transaction volume or no volume.

Yes.

Almost all transactions are free.  A transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you've received to make up the amount.  A transaction over the size limit can still be sent if a small fee is added.

The average transaction, and anything up to 500 times bigger than average, is free.

It's only when you're sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount.  It's not money sucked out of the system, it just goes to other nodes.  If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.

I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either.

I have been compiling the latest SVN on Karmic 64-bit with wxWidgets 2.9.0, which compiles fine on 64-bit.  Read build-unix.txt and use the given ../configure parameters on wxWidgets so you can use the makefile.unix.wx2.9 as supplied.  (--enable-debug --disable-shared --enable-monolithic)

There's one cosmetic bug with 2.9.0 I still need to fix where the status number display is bunched up for some reason.  -- fixed

The download link on the homepage is to the sourceforge tar.gz archive which contains the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at the time.

The SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010.

Hopefully they'll have a wxWidgets 2.9.0 debian package someday.

True, sending by IP through Tor trades one problem for another.  The Tor exit node can see the text of your message and potentially MITM you.

Best to only send to bitcoin addresses then.  Payments by bitcoin address are broadcast over the network as part of the normal network traffic.  All communications with the network are broadcasts of public information.

Am I missing something?  Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?

The bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies.

Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it.

There's a small transaction fee for very large transactions.  The node that generates the block that contains the transaction gets the fee.

If the same money gets sent again, it won't incur the fee again.  If all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together.  After that it's just one line to send the combined unit.

Are you just trying to run the program or do you really need to compile it?  There's a 32-bit linux binary that can be run on 64-bit ubuntu if you "sudo apt-get ia32-libs".
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

I recently updated the SVN for building on 64-bit Karmic with wxWidgets 2.9.0.  This was after the 0.2.0 release.  The 0.2.0 release did not build on 64-bit yet.

Unfortunately there currently isn't a -dev deb package of either of the versions of wxWidgets that we can use.  On Karmic they only have the UTF-16 version.  We need either the ANSI (libwxgtk2.8-ansi-dev) version or the UTF-8 (wxWidgets 2.9.0) version.  We're moving towards 2.9.0.

I know you said you didn't want VM, but as a last resort, last I checked the Windows version runs fine in Wine.

There are command line options:

bitcoin -addnode=1.2.3.4    to tell bitcoin about a node to connect to
bitcoin -connect=1.2.3.4    connect only to the specified node(s)

You can use more than one of these, for instance
bitcoin -connect=(first to try) -connect=(next to try) ...

You can specify non-routable IPs with -connect like 192.168.x.x, so if you had a server farm and you wanted one server to connect to the world and the rest to connect to the one server, you could do that.

In particular, -addnode is needed if you're always going to connect through TOR, since the IRC server blocks all the TOR exit nodes.  To connect through TOR, you could use:

bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216

It's much easier to have a single binary and multiple .mo files.  It's too much maintenance work to have lots of build variations.  Once the software support is implemented, anyone could contribute translations.

wxWidgets uses the gettext standard.  You use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file.  The program loads the .mo file at runtime and reskins all the strings.  Additional languages can be added to an existing program by adding .mo files without recompiling the program.

On Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located.

Right now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next.

Thank you for the offer to help translate.  That is probably the best way you could help.

I will need to prepare the code for translation first.  wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard.  We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support.  I've done test builds with 2.9.0 and there is one bug left to fix.

What operating system are you using?  Windows, Linux 32-bit or 64 bit?

Split from another thread.
sirius-m

No, sorry.  I've been meaning to redo it.  The largest icon that still looks good is the 20x20 one which is used for the tray icon in GNOME.  Any larger than that looks bad.  The 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right.  If you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in "BC" don't land square on a pixel.

The best 16x16 with full alpha channel is in src/rc/bitcoin.ico.  I don't like the 32x32 version.

I'm attaching bitcoin20x20.png, the 20x20 version with full transparency.

Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.

But don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally.  It shows 1.00 but internally it's 1.00000000.  If there's massive deflation in the future, the software could show more decimal places.

If it gets tiresome working with small numbers, we could change where the display shows the decimal point.  Same amount of money, just different convention for where the ","'s and "."'s go.  e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.

When you send to a bitcoin address, you don't connect to the recipient.  You send the transaction to the network the same way you relay transactions.  There's no distinction between a transaction you originated and one you received from another node that you're relaying in a broadcast.  With a very small network though, someone might still figure it out by process of elimination.  It'll be better when the network is larger.

If you send by IP, the recipient sees you because you connect to their IP.  You could use TOR to mask that.

You could use TOR if you don't want anyone to know you're even using Bitcoin.

Bitcoin is still very new and has not been independently analysed.  If you're serious about privacy, TOR is an advisable precaution.

That's not possible.  You've handed control of the money over to the recipient's keypair.  Only that key can control it.

It's similar to if you encrypt a file with AES and a strong password, and you lose the password.  The data is lost.