{"type":"rich","version":"1.0","author_name":"npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7","author_url":"https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-28\n📝 Original message:This feels redundant to me; the payment protocol already has an\nexpiration time.\n\n\nOn 09/27/2017 06:06 PM, Peter Todd via bitcoin-dev wrote:\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; 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 deposits.\n\u003e This also makes it difficult operationally to rotate private keys. I personally\n\u003e have even lost funds in the past due to people sending me BTC to addresses 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 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 is\n\u003e reached.\n\u003e \n\u003e Unfortunately, this proposal inevitably will raise a lot of UI and terminology\n\u003e questions. Notably, the entire notion of addresses is flawed from a user point\n\u003e of view: their experience with them should be more like \"payment codes\", with a\n\u003e code being valid for payment for a short period of time; wallets should 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 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 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 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 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 \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"}