Good suggestion.  I made the B slightly lighter and the background slightly darker.  Very slightly.  The foreground is now exactly the same colour as the BC in the old one.

It's kind of OK if you can't easily read the B in the 16x16.  At that size, you just need to see that it's a coin.  It doesn't matter so much what's embossed on it, just that there be some detail there because it wouldn't look like a coin if it was a blank smooth circle.

It's slightly wider than tall because the dark perspective under it goes more to the right than down.

I finished and posted the 32x31 and 48x47 versions in the first message.  I like the 48 a lot.

How does everyone feel about the B symbol with the two lines through the outside?  Can we live with that as our logo?

wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI.

Updated headers.h on SVN.

Sorry, I linked to wxbase but I had full wxWidgets on my computer.

The db.h:140 class Db no member named "exisits" is stranger.  pdb->get, pdb->put, pdb->del compiled before that.  Do you have version 4.7.25 of Berkeley DB?

Db::exists()
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html

I suppose they might have added exists recently, using get before that.

The formula is based on the time it takes to generate 2016 blocks.  The difficulty is multiplied by 14/(actual days taken).  For instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49.  Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.

I don't know what you're talking about accepting easier difficulties.

OK, I made a build target bitcoind that only links wxBase and does not link GTK.  Version 0.2.7 on SVN.

I split out the init and shutdown stuff from ui.cpp into init.cpp, so now ui.cpp is pure UI.  ui.h provides inline stubs if wxUSE_GUI=0.  We only have four functions that interface from the node to the UI.  In the bitcoind build, we don't link ui.o or uibase.o.

Sure feels like it could be something in wxWidgets retrying endlessly because some UI thing failed or something wasn't inited correctly.  Our hack to ignore the initialize failure and run anyway means we're in uncharted territory.  We're relying on the fact that we hardly use wx in this mode.  We do still use a few things like wxGetTranslation and wxMutex.

Another way to debug would be to run in gdb, wait until everything is quiet and all threads should be idle, and break it and see which thread is busily doing something and what it's doing.

I suspect bitcoind will probably work fine, but I hope you can still debug the problem.

Yes, the original is 546x531 pixels.

It looks good at larger size too, but since the small icons are what you mostly always see, I wanted to judge it on those first.  I'll post larger sizes and full size a little later.

The automatic adjustment happened earlier today.

24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000

24/02/2010  3.78  +49%

I updated the first post.

When and how fast did memory usage increase?  Right away, slowly over a long time, or starting at some later event?

I have -daemon running on ubuntu 9.10 64-bit and memory usage is steady.

It has to be something about the difference on the server besides 64-bit.  Maybe some malfunction from the lack of GUI.  A memory leak debug tool could give a clue.

If you GPL stuff, I have to avoid using it.  Nothing against GPL per-se, but Bitcoin is an MIT license project.  Anything GPL please clearly mark it as such.

New icons, what do you think?  Better than the old one?

     

Full size 530x529 image for scaling down to custom sizes:
http://www.bitcoin.org/download/bitcoin530.png

The perspective shadow was too thick on the larger sizes.  I updated 32, 48 and the full size.

I release these images into the public domain (copyright-free).  I request that derivative works be made public domain.

How much "dealing with" does GTK actually require?  Is it just a matter of "sudo apt-get install libgtk2.0-0" and having some extra libraries sitting around?  GTK doesn't have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no GUI present, then it's done. 

It saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK.

That would be nice at point-of-sale.  The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.

No, each generated transaction uses a new, single-use address.

Nothing uses the address in the main window, it's just there for convenience for you to copy.  0.2.5 has a "New..." button next to it to make it easy to change each time you use it.

Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC.

On Linux it needs libgtk2.0-0 installed, but does not need a GUI running.  Hopefully gtk can be installed without having a windowing system installed.

The command to start as a daemon is:
bitcoin -daemon [switches...]

Or, to run the UI normally and also be able to control it from command line or JSON-RPC, use the "-server" switch.
bitcoin -server [switches...]

With either switch, it runs an HTTP JSON-RPC server that accepts local socket connections on 127.0.0.1:8332.  The port is bound to loopback and can only be accessed from the local machine, but from any account, not just the user it's running under.

To control it from the command line, the interface is a command name without any switches, followed by parameters if any.
bitcoin <command> [params...]

For example:
bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop

It's a simple JSON-RPC client and prints the JSON result.  Look at rpc.cpp for the list of commands.

Web apps or anything automated will normally use JSON-RPC directly, not command line.  There are JSON-RPC libraries for all the major languages.  In script languages like PHP and Python the syntax is as natural as calling a local function.

Ah yes, there we go, back to normal again.

The ctrl+alt+F[1-8] thing never worked on this computer.  The screen just goes haywire.

There's a separate public/private keypair for every bitcoin address.  You don't have a single private key that unlocks everything.  Bitcoin addresses are a 160-bit hash of the public key, everything else in the system is 256-bit.

If there was a collision, the collider could spend any money sent to that address.  Just money sent to that address, not the whole wallet.

If you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding bitcoin address than to generate a block.  You could have got a lot more money by generating blocks.

The random seed is very thorough.  On Windows, it uses all the performance monitor data that measures every bit of disk performance, network card metrics, cpu time, paging etc. since your computer started.  Linux has a built-in entropy collector.  Adding to that, every time you move your mouse inside the Bitcoin window you're generating entropy, and entropy is captured from the timing of disk ops.

There are now "Sending" and "Receiving" tabs in the Address Book.  Your addresses are referred to as "receiving addresses".

madhatter was working on building it on Mac.  He had errors probably caused by UTF-16 wxWidgets 2.8.  Should have better luck now with 2.9.0.  wxWidgets 2.9.0 is UTF-8 and wouldn't have that problem.

I think he had it working on FreeBSD, but he wanted a non-UI version.

I have the command line and JSON-RPC daemon version working now.  Will SVN it in a day or two.

I disabled gdm on my Ubuntu system so it boots into command line.  I hope I will be able to get it enabled again with rcconf.

Just a random streak of bad luck.  It looks steady to me.

Competition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet.

The adjustments are every 2016 blocks.  To calculate our progress towards the next one, divide the block total by 2016.  The fractional part is how far we are to the next one. 

My back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85% of the way.  About 1.5 days to go until the next one.  That'll only be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around 40% difficulty increase.

Uploaded some UI changes to SVN as version 0.2.5.

Instead of View->Show Generated, we now have tabs:
- All Transactions
- Sent/Received
- Sent
- Received

Makes it a lot easier to flip to received and check for payments.

Moved the "Your Addresses" book inside the main address book.  It was confusing having two address books.

I found the "To:" in "From: unknown, To: (one of your bitcoin addresses)" still confusing, so I changed it to "From: unknown, Received with:".  The bitcoin address is abbreviated so you can see the label that you set in the Receiving tab of the address book.

Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0.

I haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing.

Excellent analysis, xc.

A rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases.  In your head, you do a probability estimate balancing the odds that it keeps increasing.

In the absence of a market to establish the price, NewLibertyStandard's estimate based on production cost is a good guess and a helpful service (thanks).  The price of any commodity tends to gravitate toward the production cost.  If the price is below cost, then production slows down.  If the price is above cost, profit can be made by generating and selling more.  At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.

In later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around.

At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.

It would be nice to have a list of static IPs for new users to send test donations to so they can see how the software works.  If you can accept incoming connections and you have a static IP address, post it here!

Anything sent to these IPs should be considered a donation.  

If you do request a round-trip, be sure to include your return bitcoin address or IP in the comment, but please assume it'll be one-way.  They won't necessarily be watching for incoming transactions to send back.