{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-03-12\n📝 Original message:On Thu, Mar 12, 2015 at 2:41 AM, devrandom \u003cc1.sf-bitcoin at niftybox.net\u003e wrote:\n\u003e I think there are some important advantages to not being forced to use\n\u003e the old wallet to send coins when switching wallets. The three I can\n\u003e think of right now are: maintaining transaction history,\n\nJust loading a key doesn't keep transaction history however, if the\nloading wallet can't understand or infer metadata about the\ntransactions. You get some mass of data but to tell actually what the\ntransactions are, or what they were for, forensic accounting is\nrequired and some data will be potentially unrecoverable.\n\nThe best way to preserve historical information is to use reporting\nfrom the wallet in question; which will accurately record the best\navailable output for this. (E.g. Bitcoin-qt has a CSV export or you\ncan take a json list-transactions out of it).\n\n\u003e emergency transition when a wallet has a serious (e.g. money losing) bug\n\nThis cuts both ways, we've seen significant losses for users in\nBitcoin Core where they've used the console to import keys that they\nalso used in other insecure clients.\n\nFor an emergency transition the user is probably better off with an\nexplicit unstructured mass private key export, and a sweep function;\nand guaranteeing compatibility with that is much easier; and because\nit moves funds in one direction there is much less chance of going\nfrom secure to insecure.\n\n\u003e and web\n\u003e wallet with server down.\n\nI suppose it would be too much to ask that these web wallets actually\nnot be totally centrally controlled and have the potential of just\nhaving someone else stand up a server. I guess not. :(\n\nEmergencies being what the are you do with what you can... indeed, I\nagree thats a reason that better compatibility is better. (But perhaps\nbest is that its insane to use software to handle your money that can\njust be taken away from you like that...)\n\n\u003e Another important reason to standardize is to reduce the \"roll your own\n\u003e crypto\" temptation on the wallet creator part, where the wallet-specific\n\u003e algorithm is more likely to contain weaknesses.\n\u003e I do agree that trying to come up with one uber standard will likely\n\u003e fail and is probably counter productive.\n\nCareful with this line of thinking: We have no mechanism in the BIP\nprocess to exclude weak cryptography.\n\nA BIP is not a measure of cryptographic integrity. There are existing\nBIPs which I consider flawed and would not use or recommend.\n\nIt result in some level of review, maybe, and so it can be productive\nto at least have more eyes on fewer things; which is a reason I\nwouldn't say don't bother trying.\n\nAnd indeed, I do think that what can be standardized should be, my\nwords weren't intended to dismiss anyone's efforts, only to encourage\nrealistic (I think) expectations around what will come of it.\n\nAnd while I hope for no gratuitous incompatibility, I also hope that\nno one working on a wallet hesitates for a minute to offer a new and\ninteresting functionality just because it doesn't fit into a prefab\nshape."}