wallet: export and import keys as text (#49)

The last door out. Everything else assumes Berkeley DB will
cooperate. When it will not -- a build that cannot read the
file, a truncation, an environment past recovering -- the keys
are usually still perfectly intact and were unreachable
anyway. #40 is one person's account of exactly that, and #46
only rescues the cases where BDB still opens the file at all.

  bitflash -dumpwallet=keys.txt
  bitflash -importwallet=keys.txt

One key per line with its address and label. No database, no
environment, no version coupling: anything that can read a
line can recover from it.

The format is the DER private key in hex, which round-trips
exactly through SetPrivKey. Not interchangeable with other
wallets -- worth having eventually, but a WIF encoder I got
subtly wrong would be worse than no encoder at all, and this
file exists for the case where nothing else works.

Care taken, because the failure modes here cost money:

  - Refuses to overwrite an existing file. A mistyped path
    must not eat the only copy of something irreplaceable.
  - Written owner-only on POSIX, before any key reaches it.
    Windows inherits the folder's ACL; the README says so
    rather than pretending otherwise.
  - Newlines in labels are flattened, so a label cannot forge
    an extra entry on read-back.
  - Import skips keys already present, so running it twice
    does nothing, and one unreadable line is reported and
    stepped over instead of costing the reader every other key
    in the file.

Verified on Linux and Windows: a key exported from one wallet
imports into a different one and its address then appears
there; re-importing adds nothing; a corrupted line is skipped
while the rest still load; the dump is 0600 and refuses to
overwrite.

This does not solve #47. Keys still are not derived from a
seed, so a dump is as much a snapshot as any other backup.
What it does is make the keys reachable no matter what state
the database is in.

1 files changed, 24 insertions, 0 deletions

diff --git a/README.md b/README.md
index da8183a..16e979f 100644
--- a/README.md
+++ b/README.md
@@ -98,6 +98,30 @@ The second point is the pre-BIP32 problem that deterministic wallets were
 invented to solve; see [#47](https://github.com/Bitflash-sh/bitflash/issues/47).
 Until that lands, repetition is the only defence.
 
+### When wallet.dat itself will not open
+
+Everything above still runs through Berkeley DB. If the database is the thing
+that is broken — a build that will not read it, a file truncated by a bad copy,
+an environment beyond recovery — the keys are usually still fine, and you can
+take them out as text:
+
+```
+bitflash -dumpwallet=/path/to/keys.txt
+bitflash -importwallet=/path/to/keys.txt   # into any wallet, on any machine
+```
+
+One key per line with its address and label, no database and no environment.
+Importing skips keys the wallet already holds, so running it twice is safe, and
+an unreadable line is reported and stepped over rather than abandoning the rest.
+Restart the node afterwards so it scans the chain for transactions belonging to
+the new keys.
+
+**The dump is your private keys in the clear.** Anyone who reads that file can
+spend those coins. It is written owner-only on Linux and macOS; on Windows it
+inherits whatever the containing folder allows, so choose the folder carefully.
+Move it somewhere safe and delete the copy. `-dumpwallet` will not overwrite an
+existing file.
+
 ---
 
 ## Mining