{"type":"rich","version":"1.0","author_name":"npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p","author_url":"https://nostr.ae/npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-28\n📝 Original message:Peter Todd wrote:\n\n\u003e \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\n[...]\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\n[...]\n\nPerhaps outside the scope of BIP173, but what about baking it into the protocol? That way a transaction that's sent too late, simply won't get confirmed. This removes the need for refund logic or asking a customer to pay just a few extra cents. You could also disallow a second payment.\n\nTwo downsides I can think of:\n* privacy, as differences in expiration policy would be visible on chain\n* miners might be able to game it in their interaction with brokers\n\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\nSo that's 4.8 characters for hours, or 3.2 for years, plus checksum space? The shorter the better. Perhaps one or two bits can be used to specify an exponent; a large range seems more useful than high precision. For instance a merchant doesn't care if the customer pays within 10:00:00 minutes or 10:00:01 minutes and you wouldn't care if your address is valid 50 years or 50 years and 3 minutes. This point may be mute if minute level resolution is not practical.\n\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\nGreg Maxwell wrote:\n\n\u003e One thing to keep in mind is that address format linked fields are\n\u003e most efficient if they're multiples of 5 bits.  Perhaps use 1 bit to\n\u003e indicate an embedded amount and 19 bits of 1 day precision, resulting\n\u003e in a 1435 year span.\n\nIs this because 5 bits are one bech32 character (2^5=32) or there is another reason? And does that include the space needed for the checksum?\n\n\nHopefully one day addresses can be abstracted away, because they really aren't what people intuitively think they are, but I don't see that happen on short notice. Until then they shouldn't exhibit \"surprising\" behavior.\n\nEmbedding amounts in an address could confuse people when they reuse it. Wallets would e.g. have to ignore the amount value if they previously sent money, but without changing the address string displayed in the UI.\n\n\n\u003e Keep in mind that high precision of the expiration times is asking the\n\u003e sender to have a higher precision of idea of the time, date only is\n\u003e kinda nice.  I think shorter expiration times are unlikely to be\n\u003e useful due to clock skew-- you can't assume a signer has any access to\n\u003e the Bitcoin network at all.\n\nMany merchant services and exchanges use 10-15 minute expiration though. At the wallet level, all sender and recipient need to agree on is their relative time. Fallback behavior for a signer with no access to time could be to ignore the deadline.\n\nAndreas Schildbach wrote:\n\u003e \n\u003e This feels redundant to me; the payment protocol already has an\n\u003e expiration time.\n\nThe BIP-70 payment protocol has significant overhead and most importantly requires back and forth. Emailing a bitcoin address or printing it on an invoice is much easier, so I would expect people to keep doing that.\n\nSjors\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/48685946/attachment-0001.sig\u003e"}