[bip32utils]

I've published an experimental version of my bip32utils library and generator script:

https://github.com/jmcorgan/bip32utils

This is pure Python implementation of the BIP0032 draft standard, as recently amended by Peter Wiulle in a pull request on the BIP github account, and is dependent only on the Python ecdsa library available in pypi.

BIP0032 describes a mechanism for generating a hierarchical tree of ECDSA private and public key pairs in a deterministic way using an initial seed.  In addition, one can export an extended private key for a particular tree node that allows generating public and and private child keys underneath, or export an extended public key that only allows generating public keys for child nodes below it in the hierarchy.

There are number of use cases this enables, including single seed backup for an entire hierarchy, allowing auditors to have access to transactions but without the ability to spend them, the ability for a website to generate receive addresses without a compromise allowing spending from those addresses, and delegation of spending authority to keys lower in the hierarchy.

The bip32utils library provides a Python class encapsulating a node in this hierarchy, and a command-line Swiss army knife style script bip32gen that uses this class to create keys in a hierarchy from either entropy or an extended key import format.

The tests directory contains scripts that verify conformance to the BIP0032 test vectors as published.

This is an initial effort that hasn't received a great deal of testing and feedback, so I would recommend against relying on this for anything but token amounts of BTC until it is more mature.

Feedback is welcome.

I have developed a set of scripts that allow one to take an existing Ubuntu Live DVD ISO image file, customize it, and remaster a new image with all of the contents encrypted with LUKS:

https://github.com/jmcorgan/cryptubuntu

When booting from the DVD, a passphrase is requested to mount the encrypted root filesystem with on-the-fly decryption.

There are many uses for this; consider creating data backups along with the OS and all the software necessary to interact with it.  I use it in my professional work to deliver archived milestones of development projects (with the build environment intact).  The encryption allows the DVD to contain business proprietary and confidential information on it without worrying about 3rd party access.

In the context of Bitcoin, this also allows a new sort of cold storage: By putting a SPV client with a deterministic wallet on it, you can make cheap copies that can live in different places, any of which could provide you access to your bitcoin in an emergency.  Just boot the DVD, provide the decryption passphrase, and let the SPV client download the need blockchain data, which goes into a RAM overlay.  At present this is only ~250MB or so.  With the deterministic seed, access to any of the generated addresses in the future is assured.

The DVD contents, unlike USB drives, are read only.  One may argue the longevity of recordable-DVD storage media vs. USB flash drives, but since they are so cheap to make, you can make many copies.

Since the remastering scripts can take their own output ISO images as the starting point for futher customization and encryption, I'm working on this cold storage concept by developing a plaintext image that has everything needed (Tor, Electrum, what else?), except the user's wallet data.  The ISO image would be able to then be customized by the end user by adding his wallet data to the image, and remastering it, but with encryption turned on.

Of course, this doesn't making choosing a decryption passphrase any simpler; you are essentially daring anyone who has access to the DVD to crack your password to grab your bitcoin.  So all the usual passphrase selection rules apply.  Humans don't supply much entropy.

(Disclaimer: I am not bash script proficient and I'm sure there are many ways to improve things, particularly with corner cases and error checking.  It works for me right now.)

The Bitcoin Stats website at:

http://bitcoinstats.org

...has a view of transaction confirmation times, distinguishing between fee-paid and no-fee paid transactions.  I can't link to an image as the display is dynamically generated, but along the x-axis is the confirmation time in linear scale, and the y-axis is transaction amount in logscale.

Two things appear non-intuitive.  First, there doesn't seem to be any discernable difference in confirmation time if a transaction fee is included.  This may just be a result that transaction fees are such a small portion of the block generation award that miners aren't prioritizing them much.  Still, I would have expected there to be at least an observable gradient.

Secondly, the BTC amounts for the no-fee paid transactions are almost all bunched up above 10 BTC, while the fee-paid ones are pretty uniform across five orders of magnitude.  Is there some default bitcoin client behavior that would cause this?