{"type":"rich","version":"1.0","author_name":"npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309","author_url":"https://nostr.ae/npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-27\n📝 Original message:I do agree with you to a degree, but address reuse is actually not even\nsupposed to work (it is a bug). Peter Todd is suggesting only to make\nexpiration a part of a new address format, and we could have a GUI\nwarning (but no protocol change) for the existing formats. What do you\nthink about that?\n\n\nOn 09/27/2017 01:23 PM, Nick Pudar via bitcoin-dev wrote:\n\u003e\n\u003e As a long term silent reader of this list, I felt compelled to comment\n\u003e on this address expiration topic.  I don't believe that address\n\u003e expiration should be part of the protocol.  I think instead that the\n\u003e \"sending\" feature should by default offer guidance to request a fresh\n\u003e address from the recipient.  Also allow the receiver of funds to be\n\u003e able to generate an \"invoice\" that the sender acts on.\n\u003e\n\u003e\n\u003e I also think that re-directs are fraught with privacy issues.  At the\n\u003e end of the day, the ultimate burden is on the sender (with much self\n\u003e interest from the receiver) that the correct address is being used.\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------\n\u003e *From:* bitcoin-dev-bounces at lists.linuxfoundation.org\n\u003e \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Chris\n\u003e Priest via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e *Sent:* Wednesday, September 27, 2017 3:35 PM\n\u003e *To:* Peter Todd; Bitcoin Protocol Discussion\n\u003e *Subject:* Re: [bitcoin-dev] Address expiration times should be added\n\u003e to BIP-173\n\u003e  \n\u003e A better solution is to just have the sending wallet check to see if\n\u003e the address you are about to send to has been used before. If it's a\n\u003e fresh address, it sends it through without any popup alert. If the\n\u003e address has history going back a certain amount of time, then a popup\n\u003e comes up and notifies the sender that they are sending to a non-fresh\n\u003e address that may no longer be controlled by the receiver anymore.\n\u003e\n\u003e Also, an even better idea is to set up an \"address expiration\n\u003e service\". When you delete a wallet, you first send off an \"expiration\n\u003e notice\" which is just a message (signed with the private key) saying\n\u003e \"I am about to delete this address, here is my new address\". When\n\u003e someone tries to send to that address, they first consult the address\n\u003e expiration service, and the service will either tell them \"this\n\u003e address is not expired, proceed\", or \"this address has been expired,\n\u003e please send to this other address instead...\". Basically like a 301\n\u003e redirect, but for addresses. I don't think address expiration should\n\u003e be part of the protocol.\n\u003e\n\u003e On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e     Re-use of old addresses is a major problem, not only for privacy,\n\u003e     but also\n\u003e     operationally: services like exchanges frequently have problems\n\u003e     with users\n\u003e     sending funds to addresses whose private keys have been lost or\n\u003e     stolen; there\n\u003e     are multiple examples of exchanges getting hacked, with users\n\u003e     continuing to\n\u003e     lose funds well after the actual hack has occured due to\n\u003e     continuing deposits.\n\u003e     This also makes it difficult operationally to rotate private keys.\n\u003e     I personally\n\u003e     have even lost funds in the past due to people sending me BTC to\n\u003e     addresses that\n\u003e     I gave them long ago for different reasons, rather than asking me\n\u003e     for fresh\n\u003e     one.\n\u003e\n\u003e     To help combat this problem, I suggest that we add a UI-level\n\u003e     expiration time\n\u003e     to the new BIP173 address format. Wallets would be expected to\n\u003e     consider\n\u003e     addresses as invalid as a destination for funds after the\n\u003e     expiration time 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\n\u003e     a user point\n\u003e     of view: their experience with them should be more like \"payment\n\u003e     codes\", with a\n\u003e     code being valid for payment for a short period of time; wallets\n\u003e     should not be\n\u003e     displaying addresses as actually associated with specific funds. I\n\u003e     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\n\u003e     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\n\u003e     regardless of\n\u003e     timezone: the former is sufficiently short that UI's can simply\n\u003e     display an\n\u003e     \"exact\" time (though note different leap second interpretations),\n\u003e     while the\n\u003e     latter is long enough that rounding off to the nearest day in the\n\u003e     local\n\u003e     timezone is fine.\n\u003e\n\u003e     Supporting hour-level (or just seconds) precision has the\n\u003e     advantage of making\n\u003e     it easy for services like exchanges to use addresses with\n\u003e     relatively short\n\u003e     validity periods, to reduce the risks of losses after a hack.\n\u003e     Also, using 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     \u003chttp://petertodd.org\u003e\n\u003e\n\u003e     _______________________________________________\n\u003e     bitcoin-dev mailing list\n\u003e     bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e     \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e -- \n\u003e Chris Priest\n\u003e 786-531-5938\n\u003e\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/c2fbfa44/attachment-0001.html\u003e"}