gavinandresen

KEPT FOR REFERENCE:  Optional encryption of private keys was implemented starting with Bitcoin version 0.4.


Design notes on what an ideal wallet encryption feature for Bitcoin would look like:

Encrypt only the important information-- the private keys needed to spend coins (sign transactions).

Decrypt only when a key is needed to sign a transaction (on a send).

I don't think encrypting the public keys, transactions/comments is worth it, but that might be

gavinandresen

Background: Satoshi mostly implemented a 'headers only for initial block download' mode. See the fClient flag in the source, and the headersonly github branch.

The goal is to make newbie bitcoin users startup experience better-- it is painful to wait a day for the block-chain to download and verify.

The observation is that if you have an empty wallet and you aren't solo mining, you don't care about past transactions, you just need the best block chain. So bitcoin can just fetch block headers until it catches up with the current block, and then download and verify full blocks after that (once it shows the user a bitcoin receiving address, they might get transactions to it, so bitcoin has to fetch full blocks after the first time it starts up).

As I finish the implementation, I'll keep this gist up-to-date with issues or re-thinks.

---

gavinandresen

TEST: No private keys left in any file on disk after wallet encryption/re-encryption is complete.

Preparation:

Start with an unencrypted wallet.dat; save a copy to wallet.unencrypted.dat

Extract all private keys into a 'privatekeys.txt' file:

Fetch or clone sipa's 'dumpallkeys' branch and build a bitcoind with it

https://github.com/sipa/bitcoin/tree/dumpallkeys

gavinandresen

#include "headers.h"
#include "net.h"

static const int64 DAYS = 24 * 60 * 60;

void ThreadSendAlert();

class CSendAlert
{
public:

gavinandresen

    alert.nRelayUntil   = GetTime() + 15 * 60;
    alert.nExpiration   = GetTime() + 365 * DAYS;
    alert.nID           = 1011;
    alert.nCancel       = 1010;   // cancels previous messages up to this ID number                                                                                  
    alert.nMinVer       = 50000;
    alert.nMaxVer       = 50300;
    alert.nPriority     = 5000;
    alert.strComment    = "";
    alert.strStatusBar  = "URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix";

gavinandresen

I'm writing this to organize my thoughts on creating much more secure bitcoin wallets and payments.

Threat model

I assume the user starts with 2 uncompromised devices, and installs and configures trusted and uncompromised Bitcoin software for managing their wallet and confirming payments on both of them. I don't mean to imply that existing mechanisms for determining whether or not devices and software are uncompromised are sufficient, just that the problem of creating a secure starting state is outside the scope of what I want to consider in this document.

I assume that at some point after initial setup one of the devices is compromised by malware that has full access to the machine, including replacing any applications (bitcoin.exe, the user's web browser, etc), reading memory and/or altering the information displayed to the user.

The goal is to design protocols such that the user's wallet and payments are as secure as possible.

gavinandresen

Blockchain Rule Update Process

We recently rolled out two changes to the Bitcoin block acceptance rules (BIP16 and BIP30); this document records the lessons learned and makes recommendations for handling future blockchain rule changes.

Note: there are "soft" rule changes and "hard" rule changes. "Soft" changes tighten up the rules-- old software will accept all the blocks and transactions created by new software, but the opposite may not be true. "Soft" changes do not require the entire network of miners and merchants and users to upgrade or be left behind.

"Hard" changes modify the rules in a way that old, un-upgraded software consider illegal. At this point it is much, much more difficult (some might say impossible) to roll out "hard" changes, because they require every miner and merchant and user to upgrade.

Lessons Learned

gavinandresen

#New RPC commands

Implementation: bitcoin/bitcoin#1456

listunspent [minconf=1] [maxconf=999999]

Returns an array of unspent transaction outputs in the wallet that have between minconf and maxconf (inclusive) confirmations. Each output is a 5-element object with keys: txid, output, scriptPubKey, amount, confirmations. txid is the hexadecimal transaction id, output is

gavinandresen

Reworking Bitcoin Transaction Fees

Transaction fees as they are currently implemented in the original Bitcoin code suffer from a few problems:

• The rules are complicated and ad-hoc
• Fees are hard-coded and do not reflect real costs
• Adding fees to a transaction doesn't necessarily make it more likely the transaction will be confirmed more quickly.

I'm proposing changing the rules miners use to decide what transactions to include in their blocks, and changing the way clients tell users whether or not any particular transaction "needs" a fee to be confirmed in a reasonable amount of time.

gavinandresen

#Goal:

Multi-person 'cold storage' wallet, using the existing 'raw transactions' JSON-RPC api (geek's multisig):

#Setup:

Alice generate a public/private keypair. She prints them out and stores them somplace physically secure offsite as a backup. She secures the private key in a way that she can easily access it.

Bob does the same, then Alice and Bob exchange public keys and both form a 2-of-2 multisig address using addmultisigaddress and verify that it's the same for both of them.