Long-term, safe, store-of-value #2

issue gavinandresen openend this issue on December 19, 2010
  1. gavinandresen commented at 4:22 pm on December 19, 2010: contributor

    Should we add features to bitcoin to enable the use of bitcoins as a long-term, secure, store-of-value for wealth?

    Possible features to enable this type of use:

    • Easy yet ultra-safe way to export part of you wallet’s balance to a file.
    • Easy way to verify the balance stored in one of those exported files.
  2. davout commented at 7:01 pm on December 20, 2010: none
    File should be human-readable
  3. mgiuca commented at 6:23 am on February 17, 2011: contributor

    Seconded. I have been using Bitcoin for a couple of days, and while many users will not care about the details, I want to know (at least during my initial testing of the system) exactly how it works. This will help me, and other tech-savvy users understand the security implications.

    To me, the biggest “black box” of the whole system is the wallet. It’s a binary blob which I am told to keep backed up or else. It’s unclear to me how I would restore it without erasing recent transactions. I’m not sure which data is stored in it and which is not – from the look of some other bugs here, it seems to store more data than just the public/private keys (such as config data). Does it store the names I have associated with the addresses? (I wouldn’t want to lose my PC, restore my wallet.dat, and discover I can’t tell who sent me what, so I’d hope it does store those names.) Does it store sending addresses? (I don’t think it should, as that’s more of an address book than a crucial wallet.) And it isn’t encrypted with a password.

    I’m not asking for answers to these questions – I can find them out if I really want to. I’m saying that these answers should be immediately obvious from inspecting the wallet file. There should be nothing “magical” about this file, for an advanced user.

    I would like to see a transition to a “Wallet 2.0” file format, which is simply a PGP-encrypted text file (so, binary, but a simple gpg -d will get the text out). I should be able to encrypt it with either a symmetric or public key.

    Inside the file, there would be a simple ASCII format, such as: <address> (active|inactive) [name] <pub-key> <priv-key>

    with one address per line (or split into “sections” if the pub-key and priv-key are too long to put on a single line). The active|inactive determines whether the address shows up as a receive address in the GUI (so when it pre-generates 100 addresses, they all show up here, and are all marked inactive until the user presses “New Address” in the UI).

    This would only contain receiving addresses. Sending addresses would be in a separate address book file, which would hopefully also be a text file, and I could back up too if I wanted to but isn’t critical.

    Now, at a glance, I (as a technical user) can tell exactly what data is stored in the wallet. And it should be significantly easier to write tools for listing all the money associated with each account in the wallet, splitting up a wallet into separate files, and so on.

  4. Kiv commented at 1:28 am on March 6, 2011: none
    Agree about human readable, I would love to actually understand the contents of my wallet.
  5. gavinandresen commented at 9:21 pm on March 6, 2011: contributor
    See my bitcointools tree for a (python) tool that dumps out the information in the wallet in a human-readable form.
  6. sipa commented at 10:31 pm on March 12, 2011: member

    I’m currently working on a patch that will allow export and import of wallets in a human readable form.

    The format i’ve been using currently has lines of this form: [privatekey] [block nr of earlest unredeemed output to this key] # [address] [available BTC]

    The part after the # is optional, since only the private key suffices, the rest can be derived, The block number was suggested by Gavin on the forum somewhere, as an optimization.

    Maybe adding address labels is useful as well.

  7. mgiuca commented at 1:41 am on March 13, 2011: contributor

    There has been some discussion relating to a so-called “.bitkeys” format, which would be a standardised human-readable text file format for storing Bitcoin private key data. It seems to have been suggested here by [mike]: http://www.bitcoin.org/smf/index.php?topic=3638.40

    I don’t know if the format discussion has moved elsewhere, but you should try to be compatible with this format.

    Basically, this means your file should start with v=1 (version, I assume). Exporter should write v=1, importer should check for v=1.

    Otherwise, what you suggest is almost right, but the private key and block number should be comma-separated: base58 encoded privkey,block number # comment

    Everything after the hash is a comment. You said it was “optional” but that sort of implies that your software will possibly be looking for an address and available BTC. It should not, since the format should allow arbitrary machine-ignored text after the #. So your exporter should write # [address] [available BTC] or whatever you want, but your importer should completely ignore everything after the comment and just use the privatekey to derive the public key and address.

    Also note, if you haven’t written the code for this already, that I already implemented, in C using OpenSSL, the code to take a 32-byte private key and generate the full 279-byte DER key (which Bitcoin internally calls the “private key”) and 65-byte public key. My intention was for my code to eventually be used inside Bitcoin itself, so please use it if you can:

    It is currently a command-line program which takes the private key as input and produces the DER key (of which the public key is a substring), but it is very well documented and could easily be adapted into a bitkeys file reader.

  8. sipa commented at 2:27 am on March 13, 2011: member

    Sure, that thread is where i got the idea, i couldn’t remember where it was. The code for importing and exporting private keys also already exists, see http://www.bitcoin.org/smf/index.php?topic=3906. The hard part is keeping the data structures in bitcoind intact and up to date when importing things.

    The precise formatting is only a detail that can easily be changed. Clearly, the importer will ignore everything after a #, as the address and available BTC to an address can be derived from the private key and the block chain, but still useful for human readers, so the exporter will put them in comments.

    Maybe we should start the format discussion again, since there are additional useful things to put in such a file, it seems. Whether or not the key is only a reserve key, a possible label for a key, …

  9. TheBlueMatt referenced this in commit 44baaa6dbd on May 24, 2011
  10. khalahan referenced this in commit e464650033 on Nov 1, 2011
  11. khalahan referenced this in commit 3e3a016a4a on Nov 1, 2011
  12. luke-jr referenced this in commit fce3a3f3c2 on Jul 24, 2012
  13. nelisky referenced this in commit 1f90abd156 on Apr 4, 2013
  14. enterprisey commented at 9:02 pm on April 25, 2013: contributor
    +1 on human-readable.
  15. laanwj commented at 5:56 am on April 26, 2013: member
    No +1ing here please. If you comment, add something substantial. Otherwise, code or gtfo :)
  16. jgarzik commented at 5:58 am on April 26, 2013: contributor
    I think this issue is too vague and outside the scope of what we normally consider issues/pull reqs, these days. Recommend closing.
  17. Diapolo commented at 9:28 am on April 26, 2013: none
    @jgarzik ACK
  18. gavinandresen closed this on Apr 26, 2013

  19. nelisky referenced this in commit e6b2f1b3d3 on May 30, 2013
  20. sipa referenced this in commit bf12fcc060 on Jun 2, 2013
  21. maxpwr referenced this in commit 1868efe8dd on Jun 24, 2013
  22. rebroad referenced this in commit c6f09fe7d3 on Jun 22, 2014
  23. rdponticelli referenced this in commit 8b3263b638 on Nov 26, 2014
  24. dexX7 referenced this in commit efbf553e05 on Mar 25, 2015
  25. jtimon referenced this in commit 0ca9cc5195 on May 13, 2015
  26. brishtiteveja referenced this in commit 91864eeaa9 on Jan 25, 2016
  27. destenson referenced this in commit b6a77be035 on Jun 26, 2016
  28. MarcoFalke referenced this in commit 3650668cdb on Sep 25, 2016
  29. laanwj referenced this in commit 3665483be7 on Nov 3, 2016
  30. ptschip referenced this in commit 0ee552238c on Dec 25, 2016
  31. practicalswift referenced this in commit 9c184a7b41 on Feb 28, 2017
  32. deadalnix referenced this in commit a7b21f4ff0 on Mar 3, 2017
  33. dooglus referenced this in commit 209ecd8cd9 on Mar 27, 2017
  34. sanch0panza referenced this in commit b0e16fb981 on May 5, 2017
  35. sanch0panza referenced this in commit 653ca663d3 on May 5, 2017
  36. deadalnix referenced this in commit 2176d4e125 on May 11, 2017
  37. rawodb referenced this in commit 7f92d07958 on Jun 3, 2017
  38. kleetus referenced this in commit 641c12c35b on Jun 13, 2017
  39. AkioNak referenced this in commit d649c1cb27 on Jul 24, 2017
  40. laanwj referenced this in commit b13a68e129 on Aug 2, 2017
  41. jimhashhq referenced this in commit 281b1b25cc on Aug 2, 2017
  42. fametrano referenced this in commit ecbd242045 on Aug 4, 2017
  43. JeremyRubin referenced this in commit 7f378349b2 on Aug 9, 2017
  44. Sjors referenced this in commit 981b0ce5a6 on Aug 31, 2017
  45. MarcoFalke referenced this in commit 95f7165000 on Sep 29, 2017
  46. MarcoFalke referenced this in commit daf1285af6 on Sep 29, 2017
  47. MarcoFalke referenced this in commit 619bb05037 on Sep 29, 2017
  48. laanwj referenced this in commit 16fff80257 on Nov 30, 2017
  49. MarcoFalke referenced this in commit 351fadd68a on Dec 19, 2017
  50. MarcoFalke referenced this in commit 88411e98e5 on Dec 19, 2017
  51. classesjack referenced this in commit 99fea73224 on Jan 2, 2018
  52. nining referenced this in commit 6b4e56d7b1 on Jan 3, 2018
  53. nining referenced this in commit 2fd2acd27a on Jan 3, 2018
  54. nining referenced this in commit 2b5ff3c9fa on Jan 3, 2018
  55. DaElf referenced this in commit 35f0a4e2e9 on Jan 10, 2018
  56. hkjn referenced this in commit 3aab98f8dc on Jan 13, 2018
  57. hkjn referenced this in commit 7e80175d2b on Feb 23, 2018
  58. HashUnlimited referenced this in commit fb8585691c on Mar 9, 2018
  59. HashUnlimited referenced this in commit b84bc05530 on Mar 12, 2018
  60. KrzysiekJ referenced this in commit bd5f50ef74 on Mar 28, 2018
  61. dagurval referenced this in commit f6ec952874 on Mar 28, 2018
  62. MarcoFalke referenced this in commit 4d550ffab6 on Jul 30, 2018
  63. Empact referenced this in commit d664ff7740 on Aug 1, 2018
  64. hashtobewild referenced this in commit dc5aa1e51e on Aug 26, 2018
  65. laanwj referenced this in commit 2d4749b366 on Sep 17, 2018
  66. dooglus referenced this in commit 0383470a96 on Oct 19, 2018
  67. cryptapus referenced this in commit 20a39bbed7 on Dec 14, 2018
  68. MarcoFalke referenced this in commit 80112b17e7 on Mar 2, 2019
  69. MarcoFalke referenced this in commit 6899ef3f0e on Jun 11, 2019
  70. gertjaap referenced this in commit 42596c8f87 on Jun 13, 2019
  71. gertjaap referenced this in commit 327046742d on Jun 13, 2019
  72. MarcoFalke referenced this in commit 98958c81f5 on Jun 17, 2019
  73. MarcoFalke referenced this in commit 4aaeb04497 on Oct 22, 2019
  74. laanwj referenced this in commit 89e93135ae on Nov 10, 2019
  75. MarcoFalke referenced this in commit cf43f3f0a8 on Dec 5, 2019
  76. MarcoFalke referenced this in commit bb03765e2d on Dec 8, 2019
  77. fanquake referenced this in commit c8e65ade09 on Dec 9, 2019
  78. Warchant referenced this in commit 7958da26e8 on Dec 31, 2019
  79. velesnetwork referenced this in commit a9ec425424 on Jan 12, 2020
  80. velesnetwork referenced this in commit 06986f230b on Jan 12, 2020
  81. laanwj referenced this in commit 66480821b3 on Feb 10, 2020
  82. hebasto referenced this in commit c932897b13 on Jun 3, 2020
  83. MarcoFalke referenced this in commit 505b4eda55 on Jul 10, 2020
  84. laanwj referenced this in commit 31bdd86631 on Jul 15, 2020
  85. laanwj referenced this in commit 924a4ff7eb on Oct 29, 2020
  86. MarcoFalke referenced this in commit 027e51f715 on Nov 12, 2020
  87. jonasschnelli referenced this in commit c33662a0ea on Dec 2, 2020
  88. KolbyML referenced this in commit 3d9f0283ff on Dec 5, 2020
  89. laanwj referenced this in commit e520e091db on Jan 6, 2021
  90. rajarshimaitra referenced this in commit 46d92fc46e on Mar 23, 2021
  91. rajarshimaitra referenced this in commit 1a26a65313 on Mar 23, 2021
  92. MarcoFalke referenced this in commit 590e49ccf2 on Apr 4, 2021
  93. MarcoFalke referenced this in commit bce09da122 on Apr 28, 2021
  94. fanquake referenced this in commit fa00bb2c5c on Apr 29, 2021
  95. MarcoFalke referenced this in commit eb9a1fe037 on May 7, 2021
  96. laanwj referenced this in commit ee9befe8b4 on May 12, 2021
  97. MarcoFalke referenced this in commit c857148636 on May 15, 2021
  98. satindergrewal referenced this in commit 79f824d169 on Jun 22, 2021
  99. MarcoFalke referenced this in commit eb1f5706df on Sep 9, 2021
  100. rrybarczyk referenced this in commit afc21f7e9e on Sep 21, 2021
  101. rrybarczyk referenced this in commit 3d568fb7c9 on Sep 21, 2021
  102. MarcoFalke locked this on Dec 16, 2021
  103. russeree referenced this in commit 2e689066de on Mar 15, 2023
  104. DrahtBot added the label CI failed on Apr 11, 2023
  105. MarcoFalke removed the label CI failed on Apr 11, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-04 13:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me