diff options
| author | Bitflash <btf01@proton.me> | 2026-07-30 12:06:08 -0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-07-30 12:06:08 -0300 |
| commit | b539d776bd86df9224d97048f26f33d2750d1c92 (patch) | |
| tree | 4a246ca7c8680e0b2d32613e388116a5d39247cf /src/db.h | |
| parent | daac46893448e49a21244d9646acf0ec47518537 (diff) | |
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.
Diffstat (limited to 'src/db.h')
| -rw-r--r-- | src/db.h | 7 |
1 files changed, 7 insertions, 0 deletions
| @@ -409,6 +409,13 @@ bool LoadWallet(); | |||
| 409 | // address created after this call are not spendable from the file it writes. | 409 | // address created after this call are not spendable from the file it writes. |
| 410 | bool BackupWallet(const string& strDest); | 410 | bool BackupWallet(const string& strDest); |
| 411 | 411 | ||
| 412 | // Plain-text key export/import: no Berkeley DB, no environment, no version | ||
| 413 | // coupling. What you fall back on when wallet.dat itself will not cooperate. | ||
| 414 | // DumpWallet refuses to overwrite an existing file and writes owner-only on | ||
| 415 | // POSIX -- the output holds private keys in the clear. | ||
| 416 | bool DumpWallet(const string& strDest); | ||
| 417 | bool ImportWallet(const string& strSrc, int& nAddedRet, int& nSkippedRet); | ||
| 418 | |||
| 412 | inline bool SetAddressBookName(const string& strAddress, const string& strName) | 419 | inline bool SetAddressBookName(const string& strAddress, const string& strName) |
| 413 | { | 420 | { |
| 414 | return CWalletDB().WriteName(strAddress, strName); | 421 | return CWalletDB().WriteName(strAddress, strName); |