Project status

0.4 RELEASE

Bitcoin version 0.4 release candidate 2 looks stable; I've been running a slightly-modified version of it on the Faucet website with no issues for a couple of days now, and am not aware of any show-stopper issues.

I built and uploaded OSX binaries to github:
  https://github.com/bitcoin/bitcoin/downloads

Windows and Linux binaries will appear as soon as our "gitian-capable" builders get a minute to create them (Jeff and Matt have been busy with real life or their day jobs).

I'd like to switch from distributing binaries on SourceForge to distributing them on GitHub, since GitHub supports https downloads.

NEXT RELEASE

If you have patches waiting to be pulled, now would be a good time to rebase them; I expect minimal-to-no changes between release candidate 2 and the final 0.4 release.

And, if you haven't already, write up a little test plan and/or add some unit tests.

The big planned feature for next release is switching from wxWidgets to qt for the GUI client.

ON THE RADAR

I'm going to start separate discussions about a few need-deep-thinking issues:

1) There is a bug/design flaw in bitcoin's difficulty adjustment algorithm. More generally, there have been nagging issues surrounding how bitcoin handles time that I think need to be addressed.

2) I'm going to submit pull requests for an implementation of the "don't talk to misbehaving peers" idea. That should proactively prevent a whole swath of potential denial-of-service attacks, but if I got it wrong it could be very bad for the network.

3) I'd really like to come to consensus on one or more 'multi-signature' standard transactions to enable much better wallet backup and security.

Lets talk about those three issues in separate threads.

On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:

> 3) I'd really like to come to consensus on one or more
> 'multi-signature' standard transactions to enable much better wallet
> backup and security.

More important in this area, IMO, is support for deterministic keychains in wallets. Type 2, according to gmaxwell's original spec, seems pretty ideal, and significantly improves security for many use cases. Since it allows a wallet to contain a public keychain without the matching private keychain, webservers, POS, and other services can be provisioned only with the keychain required to generate/access infinite public keys, and without the private keyroot needed to spend them.

The ideal scenario in this regard, as I see it, is this: - Webserver wallets are provisioned with multiple public keychains (one per webserver), and configured to use a specific one for getnewaddress/etc. By provisioning them with *all* the public keychains, their listtransactions/etc can see the transactions sent to other webservers, necessary to show confirmations to the end user and such. - Business keeps a locked-down *offline* wallet with the private keychains for all the forementioned public keychains. Only this wallet has the information required to spend the income. The wallet is encrypted, and can only be accessed by staff with the proper position/authority to authorize expenses. - A third wallet is used by staff to prepare expense transactions. It keeps track of locking coins it knows are in the process of being spent, and any staff member can create new ones. Once created, they must submit the transaction to a staff member with the proper authority to bring it to the offline transaction-signing wallet (on a USB key), where it is signed, and returned to this third wallet.

Another feature that needs some attention is signmessage. It can be used to send a transaction id/summary to a specified email address signed by the sending key of the same transaction (these can be added to the send-money GUI). This would allow merchants to publish a single payment address and still be able to verify which customers sent payment.

On Sep 13, 2011 11:40 AM, "Luke-Jr" <luke@dashjr•org> wrote:

> Once created, they must submit the
> transaction to a staff member with the proper authority to bring it to the
> offline transaction-signing wallet (on a USB key), where it is signed, and
> returned to this third wallet.

I agreed up to this point. Private keys should not be stored on nand. Please look in to the data recovery clusterfuck nand creates when concerning sensitive data.

It is close to impossible to reliably delete such data, moreso on usb keys than ssd, short of absolute physical destruction and noone should be recommending this. Ever.

On Tuesday, September 13, 2011 12:48:58 PM Douglas Huff wrote:

> On Sep 13, 2011 11:40 AM, "Luke-Jr" <luke@dashjr•org> wrote:
> > Once created, they must submit the
> > transaction to a staff member with the proper authority to bring it to
> > the offline transaction-signing wallet (on a USB key), where it is
> > signed, and returned to this third wallet.
>
> I agreed up to this point. Private keys should not be stored on nand.
> Please look in to the data recovery clusterfuck nand creates when
> concerning sensitive data.

I didn't recommend storing private keys on NAND. The USB stick would contain only the transaction that it being approved, and the offline-signing-wallet would sign it. The USB stick then contains only the signed transaction to be returned to an online node. At no time does it contain keys.