Anyone has any idea what's happened to bitcoingadgets.com? I've been trying to open it for the last several days, but it appears to be down.

It's a great online password manager I've been using a lot - check it out at http://www.clipperz.com/
They got everything I need - locally encrypted database, one-time passes to login without risk of compromising your master password, offline backups (fully encrypted). Their "Zero-knowledge web applications" concept is of particular interest.

The service is free, they're running off donations, so I talked them into accepting bitcoin as well - here is the donations page, listing the address: http://www.clipperz.com/donations

I'm not affiliated with them, just a satisfied user.

Posted on bidding pond, http://www.biddingpond.com/item.php?id=512 and http://www.biddingpond.com/item.php?id=513.

Taking place 7-10 July in Novi Sad, Serbia, see http://eng.exitfest.org/

See the items description for more details.

BTW, I'm going there too.

The unqualified bind references in main.cpp and util.cpp are ambiguous for newer compilers that implement the upcoming ISO standard: there is a collision between boost::bind and std::(tr1::)::bind. This breaks the build under, e.g. VC++ 2010.

I've qualified the offending references and fixed the build here, but this is precisely the reason why using-directives in header files are widely considered a bad practice. Better to do away with the using-directives in headers.h and either qualify all references, or judiciously use typedefs and/or using-declarations throughout the sources. If Satoshi gives a green light for this, I'd make another patch along these lines.

headers.h defines _WIN32_WINNT as 0x400 (targeting Windows 98?). This hits various problems with recent boost and windows SDK versions, namely 'InitializeCriticalSectionAndSpinCount' definition errors and this problem with boost filesystem. Does anyone really need bitcoin on win98? (I doubt it'd even run there due to other dependencies). I have modified the definition to 0x500 in my repository (targeting Windows 2000 and later) and suggest the change be applied upstream. The changeset is here: https://bitbucket.org/dkaparis/bitcoin-cmake/changeset/0f2875f92c12

Regards,
Dimitri

There is this piece of code in headers.h:

#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif


In my testing it's not caught on FreeBSD 8.1

I propose it be changed to:

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif


And then checks for BSD should be
#ifdef BSD
This is the recommended way of detecting BSD in the FreeBSD Porter's Handbook.

This change is already done in my CMake tree.

Greetings,

I have set up a mirror hg repository over at bitbucket for integrating the CMake build system:
http://bitbucket.org/dkaparis/bitcoin-cmake/

It's based on latest SVN and I'm regularly updating. My modifications are addition of build files and the fix for MSVC non-debug runtime compiling of the secure_allocator class I posted some time ago.

See the included build_cmake.txt file for more details.

Currently it's tested and works for Visual C++ 2008, both IDE and command-line builds.
Still not tested: MSVC x64, MinGW and UNIX builds.

Use it as you deem fit. Contributions are welcomed.

Having being tinkering with the bundled makefiles for some time now, I'd suggest we convert the build system to CMake (http://www.cmake.org/).

It's a cross-platform build system that generates build files for the platform's native tools (makefiles, MSVC project files, etc.).
The benefits:

- no need to maintain makefiles for all platforms, just one set of CMake files that will support any platform that CMake is available on.

- simplified build procedure - instead of tinkering with the bundled makefiles, run CMake to generate makefiles ready to build on your platform. Additionally, CMake can automatically detect installations of required libraries with specially written modules. For popular libraries, such modules are available with CMake installation and others can be written.

I've already used CMake for a bunch of projects and it does deliver. I can make the conversion. Any interest?

I've managed to set up dependencies and build bitcoin with MS Visual C++ 2008 Express Edition. I'll give 2010 a try at some time.

There is a custom allocator class in serialize.h, secure_allocator, that fails to build with non-debug runtime selected. It is my understanding allocator classes require a template copy constructor, I've attached a small patch that solves the problem.

As Satoshi noted elsewhere, the MSVC build is indeed significantly slower khash/s-wise (more than twice) than the prebuilt one (MinGW?), even though I enabled the highest optimization level options and also global optimization with link-time code generation. I find that result strange, since MSVC is not known to have significantly worse optimizer than GCC's. Most probably the problem can be traced to the sha module that is extracted from Crypto++. I find in Crypto++ SVN there are revised versions of the module, including x86/x64 assembly for SHA-256. Using the newer versions would involve reintegrating their dependencies, though. On that note, why aren't we using OpenSSL's SHA-2 hashing functions instead? Since we already use OpenSSL, this would be a better solution than to manually support a SHA module from another library.

Greetings,

How is the amount of bitcoins generated per block determined? It was my understanding that is is currently fixed to 50, however a few days ago I happened to generate amount of 52.64:

Status: 729 blocks
Date: 05/15/10 08:38
Source: Generated
Credit: 52.64
Net amount: +52.64

How comes?

Regards,
Dimitri