Topic: [PULL] private key and wallet export/import - page 2. (Read 39596 times)

Firstbits are incredibly useful, but I think it should see more side adoption. There have already been a few minor tweaks to the algorithm (like collision handling within the same block).

As for the index, 4 bytes, 5, whatever, it should be possible to calculate the optimal radix-prefix periodically. I just can't imagine the index is a significant portion of the blockchain (before merkle tree pruning). But it's absence has philosophical consequences.

I think private key import is cool, but my consistent drum beating (from the side-lines) is for simplification, transparency, and modularization. I believe bitcoin could have been a lot further along if the core did not attempt to protect users, the wallet was plain text, the local blockchain and wallet were completely independent, and generally more hacker-friendly ... is the opaque nature of the bitcoin client a matter of different philosophies (monolithic GUI vs. Unix utilities), or the evolutionary consequence of man-decades of work and discussion over performance, scalability, and usability?

Should talk about a new pull request for a firstbits index be in a new thread?  It seems like there is enough support for it here.

I dunno, but I have heard developer resistance to this index, I have been promoting it for a while.  In the past, developers seemed to have the sentiment that it served no purpose other than private key imports, which at the time, they considered an obscure thing only advanced users would do (part of what motivated me to pump out physical bitcoins).

So, as you can imagine, I'm pleased to see a bandwagon chanting that we need the index.  It really isn't that complex, it just needs to be done.

Such an index need not contain all 33 bytes of a key - if it indexed only 4 bytes, it would use a fraction of the space, at the expense that collisions would require extra blocks to be needlessly checked on occasion, so for example we might read 8 blocks when we only really needed to read 2.  A negligible penalty, this would be more than acceptable, because it would still eliminate having to check well over 99% of the block chain that does not contain addresses with that prefix whenever someone imports or sweeps a private key or rescans their wallet.

In fact, I have believed that there should be a facility to reindex the block chain.  Building this second index could be part of that.  Right now, there is:

- blk0001.dat - the block chain itself (not a database file, but just a blob of binary data)
- blkindex.dat - the index we have now (keyed on transaction ID's) - which COULD be rebuilt entirely from blk0001.dat with a -reindex switch, except that there presently exists no implementation to do this.

Adding this index would just create a new .dat file that would point to blk0001.dat, which could be generated from scratch with a hypothetical -reindex switch.

160 000 blocks with 100 addresses of 33 byte each is half a gigabyte. Surely 'not indexing' would have been an optimization unnecessary for beta software?

... or was it believed that a malicious node could flood everyone's hard drive with minimal cost? ...or?

The local blockchain indexes transaction hashes.  Transaction inputs reference those transaction hashes and then the matching outputs are checked.

Eventually, if the idea of splitting the wallet part from the peer-to-peer portion that communicates with other nodes and keeps track of the blockchain becomes reality, addresses will need to be indexed for fast searching anyway.  Implementing that now would speed up key import, though.

But how does the local blockchain work if the addresses are not already indexed? I understand the client/wallet only keeps record of its own addresses and linked transactions, but... really? I should think that firstbits (or first ~48 bits) would make an excellent Primary key (with a highly unlikely collision list). How much extra data would such an address index require? Wouldn't that greatly simplifying and modularize the design?

Maybe it could be implemented into the Electrum client.  I know he was planning to implement firstbits lookups in the GUI, so maintaining an index shouldn't be too far from it.
https://bitcointalksearch.org/topic/announce-electrum-lightweight-bitcoin-client-50936

How is it that there is no index already? I'd like to see an index for native client firstbits support.

Maybe Bitcoin shouldn't automatically rescan after a key import, but the new "rescan" button starts blinking to insist you should do it, and a per-address flag is set in the wallet to indicate the block chain hasn't been analyzed yet for that address's true balance. Progress bar during online rescan, etc. I suppose a method for RPC also needs to be implemented, or maybe auto-rescan is limited to once every 15 minutes or such.

A full index could be significant in size. When it gets messed up do we then get to do a -reindex? How about when it is corrupted and points to nonexistent blocks and crashes bitcoin, etc.

Now all we need is a way to get rid of the block chain scan...

either an index built on first use, or perhaps an abbreviated one maintained in memory so it is only built once per invocation of bitcoind (e.g. a tree/hashtable that maps the first 32bits of hash160 to a list of pointers to block indexes, so memory usage isn't ridiculous)

great finally a solution

It does. You do need to unlock the wallet via RPC first though, via walletpassphrase().

Wheeee!

This, combined with the offline transaction creation, should finally make one of my projects viable!

i hope it will work with encrypted wallets too, pywallet cant do this atm so this would be the only alternative.

This seems to work great for me on an unencrypted wallet with vanity-gen generated keys. Thanks!

<3

Ok have wallet generate address, export it it, advise user to print a copy before hitting NEXT.  When user hits next it creates the transaction.

This is great news!  This is only import/export of keys, right (not sweeping and sending funds to a new key)?

Did you unlock your wallet? (walletpassphrase RPC command)

Key import/export has just been merged for 0.6.

Wallet import/export needs a bit of work still, so is delayed.

Key removal support has been dropped, because of too many dangerous side-effects on wallets (in particular in combination with accounts). I'm willing to maintain this as a separate branch, though.