Prize for importing private key [WON]

[0x6763]

Darn, I missed it!  And it even had another 30 BTC!

Oh well, at least it was interesting.  Congratulations, [mike]!

[1713855657]

1713855657

[1713855657]

1713855657

[1713855657]

1713855657

[1713855657]

1713855657

[1713855657]

1713855657

[Hal]

Congratulations Mike! That was fast, you got the bitcoins only two blocks later. Not only that, you had to create a transaction with 5 inputs, corresponding to the 5 payments into the address. Do you mind telling how you did it?

As far as use cases, you could email someone some bitcoins without knowing their address, or even if they hadn't tried Bitcoin yet. Some people want to print bitcoins on paper and put them in a safe for long term security. If you could pay bitcoins to a newly created key, and export the private key, it would be a backup that would be safe against wallet theft. Lots of people have asked for this.

[Mike Hearn]

I have an implementation of the BitCoin protocol written in Java that is fairly easy to use. The code I wrote to take these coins looked like:

Code:

        ECKey halsKey = new ECKey(Base58.decodeToBigInteger("2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy"));
        wallet.addKey(halsKey);

        NetworkConnection conn = new NetworkConnection(params);
        BlockChain chain = new BlockChain(params, wallet);
        Peer peer = new Peer(params, conn, chain);
        peer.start();
        peer.startBlockChainDownload().await();
        
        Address dest = new Address(params, "my address");
        Transaction tx = wallet.createSend(dest, wallet.getBalance(), dest);
        peer.broadcastTransaction(tx);
        wallet.confirmSend(tx);

....

    public ECKey(BigInteger privKey) {
        priv = privKey;
        pub = ecParams.getG().multiply(priv).getEncoded();
    }

I know I'm not the only one with an independent implementation of the system by this point. Like I said, I'm hoping to be able to open source it, but still need some approvals.

On use cases: I wonder if it would be easier to make the client support having multiple independent wallets. Import/export of private keys isn't enough for those use cases, you have to be able to delete the key from your own wallet too.

I'm still not 100% convinced, but OK, I will defer to the wisdom of the crowd on this one. It can't hurt. I wouldn't normally post bounties as you have to be pretty precise when specifying them, but here we go. If somebody can see a better design or more precise spec let me know.

Bounty for the 50 coins

The first person to get a patch merged by Gavin into the core software that allows import/export of wallet files, via the GUI on all 3 supported platforms, defined in the following manner wins the coins.

Export should write out the private keys and simultaneously delete those keys from the wallet. You are required to do the export, then the import, then only do the delete if the import passes. This is to guard against trivial failures like out of disk space. The bounty already requires import to be written so this is not much more work.

The format should be a text file with unix line endings and a default extension of .bitkeys that looks like this:

Code:

# Comment
v=1
base58 encoded privkey,block number  # comment
base58 encoded privkey,block number
base58 encoded privkey,block number
# Comment

where the block number is the earliest block in which that address received coins, to make scanning for transactions faster by avoiding the need to check the entire block chain. Characters after a hash symbol should be ignored, the first non-comment line should be v=1. If the first line is not v=1 then the file should be rejected and the user told to upgrade their software.

I'll also throw in 50 of my own coins for a web page that, in JavaScript, accepts such a file (copy/paste into a text area), formats a file like the above into binary and then generates a QRcode using the html5 canvas library available here:

   http://www.cipherbrain.be/qrcode/

In other words, I should be able to take a .bitkeys file, copy/paste it into a web page and without any network traffic be then able to print my keys out onto paper. Don't cheat and use your own server side code or Google chartserver - I want to be able to trust that the keys never left my computer. HTML5 app because that way it'll work on everyones systems.

[edits: complicate the text format a bit to allow for future upgrades, require key deletion]

[ribuck]

Is there a use case for exporting private keys I haven't grokked yet?

Suppose you want to export all your generated coins to another wallet, while keeping them pristine (i.e. without a transaction history).

[Gavin Andresen]

Bounty for the 50 coins. The first person to get a patch merged by Gavin into the core software that allows import/export of wallet files, via the GUI on all 3 supported platforms, defined in the following manner wins the coins. Obviously not very much but I guess it's symbolic

The format should be a CSV file (unix line endings) that looks like this:

Code:

base58 encoded privkey,block number,block number....
base58 encoded privkey,block number,block number....
base58 encoded privkey,block number,block number....

where the block numbers are the blocks in which there are unspent outputs sending to that key.

CSV file with the private key and block numbers is a good idea, although for it to be a valid CSV file then it needs to have a fixed number of columns.

I'd modify the design slightly to be just:
base58 encoded privkey,block number
... where block number is the block number of the earliest input (that'll save rescanning time-- you probably always want to rescan from the earliest block number, anyway, in case more payments were sent after you exported the key).

Also what do you mean by "export" -- write and then remove the keys from the wallet?  Write a newly generated key and generate a payment-to-that-key for a given amount of coins?

I think any code that removes keys from the wallet (or generates payments to keys that are never added to the wallet) needs to be structured as two distinct steps:
1. Write the keys to <destination>
2. Read <destination> to make sure it is valid, and, if it is, delete the corresponding keys from the wallet (or generate the send-to-self txn).

[Binford 6100]

i had no problems to read the message in the bigger QR code with a cheap smartphone.
i believe the message was bigger as the private key from Hal that started this quest.
this is how i imagine to print bitcoins : )))

i tried the paperback tool but with the size of wallet and the fact that paperback is more a joke than a usefull tool it was a dead end research. with the existing key dump tool

handling multiple wallets would require massive gui changes.
i'd rather
- tap/untap keys in wallet (not to delete them right away, just mark them as do not use/spend balances with those keys)
- import/export key from clipboard/dialog/file
- import keys from CSV file

[Mike Hearn]

Also what do you mean by "export" -- write and then remove the keys from the wallet?  Write a newly generated key and generate a payment-to-that-key for a given amount of coins?

Good point. For now I think just get the data out (50 coins isn't that much after all). Being able to simultaneously export and delete the keys seems like a nice improvement. No need to have the new key functionality as you can always just make a payment to yourself in the GUI and then export that, it can be done with existing tools.

I will update the spec to reflect your suggested changes. BTW valid CSV also requires DOS line endings, technically, but ... ew

[Mike Hearn]

Actually I changed my mind, deletion of the keys will have to be a requirement, otherwise exporting them will render your wallet useless as bitcoin will try and spend those coins and you can't stop it ....

[LZ]

If anyone's interested I can easily add import method using just private key.

Yeah, it will be good.

[Binford 6100]

Actually I changed my mind, deletion of the keys will have to be a requirement, otherwise exporting them will render your wallet useless as bitcoin will try and spend those coins and you can't stop it ....

that is a valid point
but "delete" only when export returns OK (the key is written somewhere)

i can imagine to click esc on the export dialog (lack of coffee?) and the key could be lost

[pla]

The format should be a CSV file (unix line endings) that looks like this:

Out of curiosity, why does the wallet use an external dependency (Berkeley DB, now "owned" by known-open-source-killer Oracle) in the first place, rather than something ubiquitous like XML (or if purely flat, even CSV as you mention)?

[LZ]

Only Satoshi knows.

[Hal]

I'm kind of surprised that Mike's transactions didn't show up in my wallet. Instead it still counts that address as having a positive balance. Granted it is non-standard for payments from my wallet keys to originate elsewhere, but there are other ways it could happen, involving restoring from backup.

Well I just looked at the code, and it does only watch for transactions that pay me. However it looks like the new release will rescan the block chain on startup; that will probably fix it. I wonder how costly it would be to watch for outgoing transactions all the time.

[jgarzik]

Out of curiosity, why does the wallet use an external dependency (Berkeley DB, now "owned" by known-open-source-killer Oracle) in the first place, rather than something ubiquitous like XML (or if purely flat, even CSV as you mention)?

Because it's a database, and thus easy to use, compared to building your own file format.

[pla]

Because it's a database, and thus easy to use, compared to building your own file format.

That explains why we don't use a roll-your-own binary format.  It doesn't explain why we don't use something a bit more common, such as XML.

_{You could also turn that argument around - By using a relatively uncommon DB, we've still "rolled our own" with the negative of having an external build dependency.  Even if we want insist on FOSS, why not connect to a "real" DB like MySQL?}

[theymos]

That explains why we don't use a roll-your-own binary format.  It doesn't explain why we don't use something a bit more common, such as XML.

_{You could also turn that argument around - By using a relatively uncommon DB, we've still "rolled our own" with the negative of having an external build dependency.  Even if we want insist on FOSS, why not connect to a "real" DB like MySQL?}

XML offers no reliability guarantees.

Berkeley DB is quite common on Linux -- certainly more common than xSQL. It's also easy to compile, and it has no dependencies of its own.

[jgarzik]

Berkeley DB is quite common on Linux -- certainly more common than xSQL. It's also easy to compile, and it has no dependencies of its own.

BDB is common on Windows, too, but nobody sees it because it's embedded in your applications.

And because BDB is embedded (linked) into your application, no external server is required (unlike MySQL).

[[Tycho]]

Though fun I don't really understand the point of this. For backing your wallet you can just shut down the software and make a copy of wallet.dat. For moving coins between different wallets you can just send them as regular transactions.

Is there a use case for exporting private keys I haven't grokked yet?

It would be funny to have the possibility of taking bitcoins to base reality.
Like printing on a paper and giving to someone or making a QR-code.
Also they can be embedded in files like pictures and so on - mostly for fun, but not only.

P.S.: After Wolrd War III, when there will be no internet, we will have to consider other ways of bitcoin exchange.

[Mike Hearn]

XML isn't a good format to use for storing large, binary data structures which is what BitCoin is based on.

As to the idea of passing BitCoins around on bits of paper, well, I still think that without the internet Bitcoin is pointless so that doesn't hold a lot of appeal to me. You'd be much better off using existing currencies which have a lot of time invested in making the paper hard to forge ...

[myrkul]

After WWIII, Whenever or IF it should come, any survivors are NOT going to be using bitcoins. They'll be using the next best thing: precious metals, or failing that, straight barter. Or perhaps something that the world lacks the production capability to make any more, such as bottlecaps, to make a game reference.

A QR-code would be good, but you wouldn't want to QR-code your wallet. You WOULD want to QR-code your address, though.