{"type":"rich","version":"1.0","author_name":"npub16y7znrcze3zypn28qn3eg3mamjea4q8xl95yp2mmmdyhxys7g9csf3ck7r","author_url":"https://nostr.ae/npub16y7znrcze3zypn28qn3eg3mamjea4q8xl95yp2mmmdyhxys7g9csf3ck7r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-27\n📝 Original message:As a long term silent reader of this list, I felt compelled to comment on this address expiration topic.  I don't believe that address expiration should be part of the protocol.  I think instead that the \"sending\" feature should by default offer guidance to request a fresh address from the recipient.  Also allow the receiver of funds to be able to generate an \"invoice\" that the sender acts on.\n\n\nI also think that re-directs are fraught with privacy issues.  At the end of the day, the ultimate burden is on the sender (with much self interest from the receiver) that the correct address is being used.\n\n\n________________________________\nFrom: bitcoin-dev-bounces at lists.linuxfoundation.org \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Chris Priest via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSent: Wednesday, September 27, 2017 3:35 PM\nTo: Peter Todd; Bitcoin Protocol Discussion\nSubject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173\n\nA better solution is to just have the sending wallet check to see if the address you are about to send to has been used before. If it's a fresh address, it sends it through without any popup alert. If the address has history going back a certain amount of time, then a popup comes up and notifies the sender that they are sending to a non-fresh address that may no longer be controlled by the receiver anymore.\n\nAlso, an even better idea is to set up an \"address expiration service\". When you delete a wallet, you first send off an \"expiration notice\" which is just a message (signed with the private key) saying \"I am about to delete this address, here is my new address\". When someone tries to send to that address, they first consult the address expiration service, and the service will either tell them \"this address is not expired, proceed\", or \"this address has been expired, please send to this other address instead...\". Basically like a 301 redirect, but for addresses. I don't think address expiration should be part of the protocol.\n\nOn Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\nRe-use of old addresses is a major problem, not only for privacy, but also\noperationally: services like exchanges frequently have problems with users\nsending funds to addresses whose private keys have been lost or stolen; there\nare multiple examples of exchanges getting hacked, with users continuing to\nlose funds well after the actual hack has occured due to continuing deposits.\nThis also makes it difficult operationally to rotate private keys. I personally\nhave even lost funds in the past due to people sending me BTC to addresses that\nI gave them long ago for different reasons, rather than asking me for fresh\none.\n\nTo help combat this problem, I suggest that we add a UI-level expiration time\nto the new BIP173 address format. Wallets would be expected to consider\naddresses as invalid as a destination for funds after the expiration time is\nreached.\n\nUnfortunately, this proposal inevitably will raise a lot of UI and terminology\nquestions. Notably, the entire notion of addresses is flawed from a user point\nof view: their experience with them should be more like \"payment codes\", with a\ncode being valid for payment for a short period of time; wallets should not be\ndisplaying addresses as actually associated with specific funds. I suspect\nwe'll see users thinking that an expired address risks the funds themselves;\nsome thought needs to be put into terminology.\n\nBeing just an expiration time, seconds-level resolution is unnecessary, and\nmay give the wrong impression. I'd suggest either:\n\n1) Hour resolution - 2^24 hours = 1914 years\n2) Month resolution - 2^16 months = 5458 years\n\nBoth options have the advantage of working well at the UI level regardless of\ntimezone: the former is sufficiently short that UI's can simply display an\n\"exact\" time (though note different leap second interpretations), while the\nlatter is long enough that rounding off to the nearest day in the local\ntimezone is fine.\n\nSupporting hour-level (or just seconds) precision has the advantage of making\nit easy for services like exchanges to use addresses with relatively short\nvalidity periods, to reduce the risks of losses after a hack. Also, using at\nleast hour-level ensures we don't have any year 2038 problems.\n\nThoughts?\n\n--\nhttps://petertodd.org 'peter'[:-1]@petertodd.org\u003chttp://petertodd.org\u003e\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\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/317dbefa/attachment.html\u003e"}