{"type":"rich","version":"1.0","author_name":"npub18df3zgqr9zt5ah42zpd34rmq6fp7v57vvwmtk20krhrfdczp38ks5xccej","author_url":"https://nostr.ae/npub18df3zgqr9zt5ah42zpd34rmq6fp7v57vvwmtk20krhrfdczp38ks5xccej","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-27\n📝 Original message:A better solution is to just have the sending wallet check to see if the\naddress you are about to send to has been used before. If it's a fresh\naddress, it sends it through without any popup alert. If the address has\nhistory going back a certain amount of time, then a popup comes up and\nnotifies the sender that they are sending to a non-fresh address that may\nno longer be controlled by the receiver anymore.\n\nAlso, an even better idea is to set up an \"address expiration service\".\nWhen you delete a wallet, you first send off an \"expiration notice\" which\nis just a message (signed with the private key) saying \"I am about to\ndelete this address, here is my new address\". When someone tries to send to\nthat address, they first consult the address expiration service, and the\nservice will either tell them \"this address is not expired, proceed\", or\n\"this address has been expired, please send to this other address\ninstead...\". Basically like a 301 redirect, but for addresses. I don't\nthink address expiration should be part of the protocol.\n\nOn Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Re-use of old addresses is a major problem, not only for privacy, but also\n\u003e operationally: services like exchanges frequently have problems with users\n\u003e sending funds to addresses whose private keys have been lost or stolen;\n\u003e there\n\u003e are multiple examples of exchanges getting hacked, with users continuing to\n\u003e lose funds well after the actual hack has occured due to continuing\n\u003e deposits.\n\u003e This also makes it difficult operationally to rotate private keys. I\n\u003e personally\n\u003e have even lost funds in the past due to people sending me BTC to addresses\n\u003e that\n\u003e I gave them long ago for different reasons, rather than asking me for fresh\n\u003e one.\n\u003e\n\u003e To help combat this problem, I suggest that we add a UI-level expiration\n\u003e time\n\u003e to the new BIP173 address format. Wallets would be expected to consider\n\u003e addresses as invalid as a destination for funds after the expiration time\n\u003e is\n\u003e reached.\n\u003e\n\u003e Unfortunately, this proposal inevitably will raise a lot of UI and\n\u003e terminology\n\u003e questions. Notably, the entire notion of addresses is flawed from a user\n\u003e point\n\u003e of view: their experience with them should be more like \"payment codes\",\n\u003e with a\n\u003e code being valid for payment for a short period of time; wallets should\n\u003e not be\n\u003e displaying addresses as actually associated with specific funds. I suspect\n\u003e we'll see users thinking that an expired address risks the funds\n\u003e themselves;\n\u003e some thought needs to be put into terminology.\n\u003e\n\u003e Being just an expiration time, seconds-level resolution is unnecessary, and\n\u003e may give the wrong impression. I'd suggest either:\n\u003e\n\u003e 1) Hour resolution - 2^24 hours = 1914 years\n\u003e 2) Month resolution - 2^16 months = 5458 years\n\u003e\n\u003e Both options have the advantage of working well at the UI level regardless\n\u003e of\n\u003e timezone: the former is sufficiently short that UI's can simply display an\n\u003e \"exact\" time (though note different leap second interpretations), while the\n\u003e latter is long enough that rounding off to the nearest day in the local\n\u003e timezone is fine.\n\u003e\n\u003e Supporting hour-level (or just seconds) precision has the advantage of\n\u003e making\n\u003e it easy for services like exchanges to use addresses with relatively short\n\u003e validity periods, to reduce the risks of losses after a hack. Also, using\n\u003e at\n\u003e least hour-level ensures we don't have any year 2038 problems.\n\u003e\n\u003e Thoughts?\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\n\n-- \nChris Priest\n786-531-5938\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/e853137e/attachment.html\u003e"}