rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2015-03-12 📝 Original message:On Thu, Mar 12, 2015 at 2:41 AM, devrandom <c1.sf-bitcoin at niftybox.net> wrote: > I think there are some important advantages to not being forced to use > the old wallet to send coins when switching wallets. The three I can > think of right now are: maintaining transaction history, Just loading a key doesn't keep transaction history however, if the loading wallet can't understand or infer metadata about the transactions. You get some mass of data but to tell actually what the transactions are, or what they were for, forensic accounting is required and some data will be potentially unrecoverable. The best way to preserve historical information is to use reporting from the wallet in question; which will accurately record the best available output for this. (E.g. Bitcoin-qt has a CSV export or you can take a json list-transactions out of it). > emergency transition when a wallet has a serious (e.g. money losing) bug This cuts both ways, we've seen significant losses for users in Bitcoin Core where they've used the console to import keys that they also used in other insecure clients. For an emergency transition the user is probably better off with an explicit unstructured mass private key export, and a sweep function; and guaranteeing compatibility with that is much easier; and because it moves funds in one direction there is much less chance of going from secure to insecure. > and web > wallet with server down. I suppose it would be too much to ask that these web wallets actually not be totally centrally controlled and have the potential of just having someone else stand up a server. I guess not. :( Emergencies being what the are you do with what you can... indeed, I agree thats a reason that better compatibility is better. (But perhaps best is that its insane to use software to handle your money that can just be taken away from you like that...) > Another important reason to standardize is to reduce the "roll your own > crypto" temptation on the wallet creator part, where the wallet-specific > algorithm is more likely to contain weaknesses. > I do agree that trying to come up with one uber standard will likely > fail and is probably counter productive. Careful with this line of thinking: We have no mechanism in the BIP process to exclude weak cryptography. A BIP is not a measure of cryptographic integrity. There are existing BIPs which I consider flawed and would not use or recommend. It result in some level of review, maybe, and so it can be productive to at least have more eyes on fewer things; which is a reason I wouldn't say don't bother trying. And indeed, I do think that what can be standardized should be, my words weren't intended to dismiss anyone's efforts, only to encourage realistic (I think) expectations around what will come of it. And while I hope for no gratuitous incompatibility, I also hope that no one working on a wallet hesitates for a minute to offer a new and interesting functionality just because it doesn't fit into a prefab shape.