If you have the extended public key corresponding to m/44h/0h/0h/0 (note the syntax in BIP32 has changed) in a file, say test.xpub, you can simply:


This translates as "starting with an extended public key stored in file 'test.xpub', generate the address associated with child number 0, and write it to stdout". (Address shown is from an xpub from an arbitrary wallet seed).

So, is this proposal stable enough now to turn into a formal BIP?  Is this in progress already? I would like to add a second implementation of this, as part of my bip32utils package.

Finally, would it be too much of a stretch to be able to use this encoding as way to export an extended private key from inside the hierarchy, instead of at the root?  It would fit in the "64 byte root key" encoding.

No worries.  I wanted get something up for people to review, and perfect is the enemy of good enough.

Good.  Thanks for testing.

Yes, it would be cleaner to make those module constants; I was in a bit of a rush to get this part implemented.  That's good feedback for cleanup.

Please take into account the experimental nature of the software.

Thanks, looking forward to it.

This proposal is next up for development in my bip32utils library.  Do you have any indication yet what a BIP number might be for it, and do you have a proposed short name for it?  Otherwise, I'll call it the "riplin export format"

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.

Feature request:

bitcoinaverage.com has done a good job of aggregating exchange data and calculating weighted sums for individual currencies.  They export a simple JSON API to retrieve the values, which update once per minute.

I'd find it very useful to be able to look at, say, the USD global average price (bid/ask/last) with the same charting display you use with raw exchange data.

Thanks for your consideration.

Of course, said master image would need to withstand scrutiny that it doesn't contain malware, won't steal your bitcoins when you boot it, etc.  I'm developing it for my own personal use; everyone else will either need to do that themselves, or have some level of trust.

The remastering scripts themselves are simple and easy to check, so as long as you start with an original ISO that you trust, you can trust the output.

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.)

So, when are you going to update the bitcoinstarter page?  Since you didn't make the goal there, the pledged BTC should be returned.  However, you have it "pending extension", whatever that means, and the pledged BTC is tied up.

This is an extremely interesting idea.  Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?

Thanks, this is useful.

Feature request: calculate a weighted average of and/or history of trading prices for each fiat currency.

I know that most people price their trades based on some formula using bid/ask/last prices from the major exchanges.  However, given the divergence in prices between Mt. Gox and other exchanges, it would be very useful to have a bid/ask/last/depth based on what local bitcoin traders have actually decided to set their prices to.

As the volume of local exchanges increases, this consensus could displace using unreliable centralized exchanges as a pricing mechanism, and instead show the market price when taking into account things like the risk premium of in-person trades and the delay times involved.

Another interesting set of data would be to plot the market price in different geographical areas vs. the average for that currency.

I'd contribute some BTC to a bounty for implementing this.

This highlights an issue with "code as documentation".  It fails to distinguish between implementation decisions that were arbitrary and those implementation choices that are crucial for correctness.

Someone writing a new bitcoin implementation could focus their energy on what is important to get right vs. something that "just happened" to be done that way and could have been done otherwise to no ill effect.

I'm aware of the argument that reimplementations must match the Satoshi client bug for bug in order to prevent a divergence of consensus, and that such divergence can carry a high economic price.  However, unless the reasons for any given behavior are written down, as the original developers move on, this tribal knowledge gets lost.  It is replaced by the guesswork of future developers.

The consensus of the development team seems to be that even if a well-written protocol specification were completed, they would not feel bound to consider it authoritative.

So be it.  But as bitcoin implementations need to go beyond traditional "software on PC" (think POS terminals, embedded systems, smartcards, dedicated silicon nodes, etc.), without a specification to test against, it is very difficult to assure quality and correctness.

Gavin--First, thanks for your and the other devs' work.  The rest of the world and I get the product of your labor for free.  That's pretty cool.

Second--if you really want to have multiple, interoperable implementations, I think you have to get past the "source code is the protocol documentation" idea.

I understand the argument that additional implementations must mirror bitcoind behavior exactly, including bugs, or else risk block chain splits that could have a large financial impact.  However, source-code-as-documentation does not work well as a guide to other implementers.  It fails to distinguish between behavior that is essential and behavior that is contingent and arbitrary (just happened to be that way, could be otherwise.)

Developers writing additional implementations are unable to objectively verify that what they have done is proper, without some standard from which they can create unit and overall feature tests.

Yes, I'm familiar with what exists now on the wiki and elsewhere.  It is useful as a learning tool, and others have written bitcoin-related functionality based on it.  But documentation written by "reverse engineering" the thinking of developers based on source code suffers from the same problems.

Of course, it is possible to get into documentation paralysis, where so much time is spent nailing down details that actual development stalls.  However, this can be solved in an incremental and iterative way rather than an all-at-once, serial fashion.  I think merely having the sanction of the bitcoind dev team and a vision that someday the bitcoind code will follow the spec, not the other way around, would motivate a lot of people to participate.

This isn't a complaint, per se--you guys are doing the work and giving it away, and you are of course free to do whatever you wish.  Consider this a polite request to reconsider your team's attitude toward formalizing the protocol using something beside the source code itself.

Regards,

A very happy bitcoind user and fellow full-time open source developer.

Can you show an example of this?

I think we have a junior politician in the making.

+1 for being able to buy a beer with bitcoin 

How do you know they aren't already?