Nobody knows what Satoshi wanted, or what his ideas about things like a Bitcoin foundation would be.

The fact is that Gavin took Bitcoin where Satoshi couldn't, by giving it a face. I think a Bitcoin Foundation can do an even better job for that. If Satoshi would return, I'm sure his opinion would be held very highly, but Bitcoin is no longer just what Satoshi created; right now, we all help building it. If you wonder about Satoshi's intentions, don't forget that he was against alternative implementations...

EDIT: To clarify, I mean alternative fully validating nodes. Not alternative wallets in general.

This is not true, see http://bitcoin.stackexchange.com/questions/3546/who-made-gavin-project-leader.

This was long before Gavin announced he'd give a talk at the CIA. After that, Satoshi gradually faded from public view, only to keep contact via e-mail with a few people for a few months. Some time later, approximately around the time of the CIA announcement, he vanished entirely.

Sorry, but Satoshi did appoint Gavin as his successor. I'm not sure that is even relevant, though.

Right. SEC defines the compressed (0x02/0x03 + 32-byte X coordinate) and uncompressed (0x04 + 32-byte X coordinate + 32-byte Y coordinate) formats, but doesn't specify the hybrid format (0x06/0x07 + 32-byte X coordinate + 32-byte Y coordinate). From that link, it seems that the hybrid format may have been specified by that ANSI X9.62, but I won't spend $100 to buy the standard...

Anyway, it's that hybrid format that's bothersome. Making an implementation support it is trivial though - just change the 0x06 or 0x07 byte to a 0x04 and pass it that way to the crypto library.

I just learnt this from the OpenSSL source code, and the SEC document (see the secg site).

nLockTime works and has not been touched since october 2009.

Mempool transaction replacement - which is necessary for many of nLockTime's applications as well - is something that still has to be discussed.

Yes, a lot (close to 100000, IIRC).

We're not doing signature verification right now for things buried deep enough in the chain and protected by a checkpoint. Once a significant part of the chain has only standard signatures left (I haven't seen any non-standard pubkey, except on testnet where I tried it myself), code to support the non-standard signatures is only required for implementation that want to do full validation of the entire history (which, imho, there should be). It's more of a benefit for lighter types of clients, which don't verify history.

That's somewhat of an exaggeration. Let me explain.

Bitcoin uses DER encoding for signatures and EC private keys, and a serialization defined by the SEC2 standard for EC public keys. OpenSSL follows both these standards perfectly. It creates fully compliant ones, and parses them perfectly.

However, as DER-encoded signatures and SEC encoded public keys end up in the block chain, they are effectively part of Bitcoin's (implied) protocol specification as well.

Unfortunately, OpenSSL also supports signatures that do not follow the strict DER encoding (it supports anything encoded in BER, and even that is not required). For public keys, it accepts both encodings defined by SEC, plus a weird third own one. Because these non-standard signatures and public keys have always been accepted by every full node on the network (as those simply used OpenSSL), they became part of Bitcoin's implied protocol as well. For a long time nobody noticed this, but today there are alternative implementations that systematically create non-standard signatures for example.

There's an effort being done to outlaw these, as it will make the live of developers for alternative implementations easier. See pull request 1742 for more information.

Good for you, but it certainly doesn't convince me for the wallet use case. The data being stored in there consists of complex data structures (keys, transactions), for which a serialization framework already exists. The only thing being written would be byte sequences. The advantage of SQL-based systems is easier aggregation of data from the database, but if the database layer can't inspect the data, that doesn't make much sense.

You could write an SQL-based wallet implementation that splits out wallet information over several SQL tables (I believe genjix' libbitcoin does that), and take advantage of what SQL adds, but at that point I think you need to rewrite the wallet implementation pretty much from scratch.


I still prefer not needing to integrate anything at all.


Yes, this is what we're going to do for LevelDB, as it doesn't even come as a dynamic library. Dependencies certainly complicate development - especially for portable applications - but in some cases there is just no better solution.

In my opinion, even sqlite is overkill for the wallet. It's yet another dependency (something you don't like, right?), and all we need is a simple key-value store that is read at startup and loaded into memory. Probably we'll move to a very simple custom append-only format with checksums.

For the blockchain: performance. LevelDB is exactly what we need: not more than a key-value store with atomic writes, with very good performance and consistency.

Faster, less prone to corruption (in our setting), better compatibility between versions. At least, hopefully.

Also see this SE question.

You need a backup after every 100 transactions (since there are 100 future keys pregenerated, that are part of the backup), AND immediately after encryption as well (since encryption flushes those 100 keys, for security reasons).

I fully agree, and I think the other developers do as well.

It's just that all experiments with more automated build systems failed - either they didn't work for all currently supported platforms, or weren't maintained after being written.

Again, help is welcome.

No, as I said, the key pool is flushed when encrypting. This means that any new address you request after encrypting is guaranteed to never have touched disk in unencrypted form (since 0.5.0).

Well, it was not maintained, so it was removed from the repository.

Just checked, it was removed between 0.5.0 and 0.6.0. The latest makefile.vc file is here. You can use it as a starting point, but a lot changed since it was functional.

Yes:

In general, yes. But if you need to keep the old addresses alive anyway (because people may still send coins to them), the only alternative is keeping them in a separate wallet. That is not safer than keeping them around in the newly-encrypted wallet.

There's a link on bitcoin.org. The source code is at http://github.com/bitcoin/bitcoin.

If you have a backup of a wallet that was made before encrypting it, people who find the file will at most have access to funds sent to addresses that were obtained before encryption.

Once you encrypt, all private keys are encrypted (also those of old addresses), and the key pool is flushed (the corresponding keys are not deleted, but requests for addresses after encryption will always return addresses that were created after encryption). So to be safe from crashes, make sure you always make a (new) backup after encrypting.

I have no clue about Windows programming or build environments. But if you make it work with nmake, then it will...

The Qt GUI is built using qmake, which supports many environments. Presumably you want to adapt the qmake project file to work on your platform, rather than maintaining a separate one.

Are you talking about Bitcoin-Qt or bitcoind?

We used to maintain a project for Visual Studio, but as none of the current developers use Windows, it got outdated. If someone wants to revive and maintain it, that is very welcome.

Unsure how the OSX builds happen, Gavin does those.

No external dependencies... we currently depend on OpenSSL, BDB, boost, libminiupnpc (optional), Qt (optional). OpenSSL shouldn't be too hard to swap for something else. There are already alternative clients that don't use OpenSSL, afaik. BDB is going to be dropped and replaced by LevelDB (included in the source tree, not a dependency). Boost would be a lot of work to change. The others are optional.

from the top of my head: interprocess communication, threads, locking, filesystem interaction, some datatypes, unions, program options, asio.


The GUI is a Qt application - obviously it needs Qt to build.

If you just need the daemon, there is no dependency on Qt or the Qt toolchain.

Oh yes, RPC-SSL uses actual SSL, but it's certainly possible to avoid using that (and disabling RPC-SSL support).


Certainly - but OpenSSL is also an open-source library, and it does everything we need.