Topic: Prize for importing private key [WON] - page 3. (Read 18052 times)

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

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

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
2. Read to make sure it is valid, and, if it is, delete the corresponding keys from the wallet (or generate the send-to-self txn).

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

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:


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:


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]

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.

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

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

By the way, I did this with a private Java implementation of BitCoin. I'm working on getting it open sourced, but because my employer owns the code I have to get various approvals from them first.  So right now I can't release the code, sorry.

Sorry m0mchil, I have to admit I was surprised when I reloaded the page and saw Hal had replied. I just got lucky.

(edit to rephrase question)

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?

I really can't hide my disappointment   waited hours for Hal to provide the correct key - and to see that someone got it 3 blocks earlier. Should master my 'F5' key.

There is a rather old patch (SVN 195) at https://github.com/m0mchil/bitcoin-impex-keys which supports RPC initiated exporting and importing of keys in PEM format. It also exports corresponding block numbers to speed up import.

The reason I didn't announce it back then is that it doesn't solve the double spend problem. The patch could be easily modified to not remove exported key from wallet (it does so at the moment) allowing copying of keys.

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

yes, this way is much more convenient than dealing with all the wallet data

a private key could fit into a QR code while the smallest amount of space needed by a wallet is always around 30 kB


could you, please, publish your code? : )

Donate them to someone making a patch for importing private keys into the wallet.

Why thankyou Hal, you are a scholar and a gentleman. That was an unexpectedly profitable Sunday evening! If we ever meet I will be glad to buy you drinks for the evening.

Now I'm wondering what I should do with this ⓑ50 ? I quite like this challenge concept ... I'm thinking I should make the coins available to somebody who can craft a particular type of transaction, but it'd need a miner willing to incorporate it.

Anyone else got ideas for the next step for these coins?

Sorry! I did screw up the encoding. Here is the 256-bit private key in big-endian hex:

C85AFBACCF3E1EE40BDCD721A9AD1341344775D51840EFC0511E0182AE92F78E

My new attempt to base58 encode this is:

EV71KQfoePBeWT79sV1VE7fWRgv1KNUxTNapH6ZbaRfB

That's custom code, maybe somebody could check it.

To apologize, I've added 30 BTC to the address. We're now at block 109352.

The reason I did it this way is that it would be a good format for passing around or backing up bitcoins.

BTW the new version of Bitcoin has a -rescan switch to find all txns that are for wallet keys. Only takes a couple minutes.

Yeah, I got to the same point :-( Looks like either we're all missing something fundamental, or Hal gave out an incorrect private key.

Seems we're all doing it with private code, interesting.

That alphabet is "all over Google" because it's the one that Flickr uses. But if you search for "base 58" bitcoin then the correct variation will be "all over Google".

Better still, ask the source code for the authoritative answer:
https://github.com/bitcoin/bitcoin/blob/master/base58.h

Yes, that was my one cent.

Someone sent another 0.01 BTC to that address, lol.

I've written almost a complete bitcoin client in Clojure.  And since Clojure has a REPL, I can build any Bitcoin data structure I want as fast as I can type the function name and the pieces of information that needs to go in it, and can send it out on the wire just as easily.  I don't have to bother with the write, compile, run cycle.  I just write, and it evaluates when I press "Enter", like Python's REPL.  And for this little challenge I quickly wrote up a function that already has all of the needed information, except for the public key, to build a transaction to spend these 21.05+ BTC.  All I have to do is give the function the correct private key, and it will calculate the public key, put it in the script in the transaction input, and spend those bitcoins.

I suppose I didn't update my function for the two new payments that address received, yet, though, so unless I do that, that money will still be available for others.

One thing to note is that if I don't put it in my wallet, it means that any future money going to that address won't automatically become part of my balance.  Another thing to note is that if I someone to put it in their wallet, their balance could go up or down as other people pay that address money, and others that have the private key spend the money available to that address.

Just use Satoshi's alphabet:

$ grep abcde bitcoin/src/base58.h
static const char* pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";