rich1.0npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309https://nostr.ae/npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309njumphttps://nostr.ae📅 Original date posted:2017-09-27 📝 Original message:I do agree with you to a degree, but address reuse is actually not even supposed to work (it is a bug). Peter Todd is suggesting only to make expiration a part of a new address format, and we could have a GUI warning (but no protocol change) for the existing formats. What do you think about that? On 09/27/2017 01:23 PM, Nick Pudar via bitcoin-dev wrote: > > 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. > > > I 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. > > > > ------------------------------------------------------------------------ > *From:* bitcoin-dev-bounces at lists.linuxfoundation.org > <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Chris > Priest via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> > *Sent:* Wednesday, September 27, 2017 3:35 PM > *To:* Peter Todd; Bitcoin Protocol Discussion > *Subject:* Re: [bitcoin-dev] Address expiration times should be added > to BIP-173 > > A 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. > > Also, 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. > > On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev > <bitcoin-dev at lists.linuxfoundation.org > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote: > > Re-use of old addresses is a major problem, not only for privacy, > but also > operationally: services like exchanges frequently have problems > with users > sending funds to addresses whose private keys have been lost or > stolen; there > are multiple examples of exchanges getting hacked, with users > continuing to > lose funds well after the actual hack has occured due to > continuing deposits. > This also makes it difficult operationally to rotate private keys. > I personally > have even lost funds in the past due to people sending me BTC to > addresses that > I gave them long ago for different reasons, rather than asking me > for fresh > one. > > To help combat this problem, I suggest that we add a UI-level > expiration time > to the new BIP173 address format. Wallets would be expected to > consider > addresses as invalid as a destination for funds after the > expiration time is > reached. > > Unfortunately, this proposal inevitably will raise a lot of UI and > terminology > questions. Notably, the entire notion of addresses is flawed from > a user point > of view: their experience with them should be more like "payment > codes", with a > code being valid for payment for a short period of time; wallets > should not be > displaying addresses as actually associated with specific funds. I > suspect > we'll see users thinking that an expired address risks the funds > themselves; > some thought needs to be put into terminology. > > Being just an expiration time, seconds-level resolution is > unnecessary, and > may give the wrong impression. I'd suggest either: > > 1) Hour resolution - 2^24 hours = 1914 years > 2) Month resolution - 2^16 months = 5458 years > > Both options have the advantage of working well at the UI level > regardless of > timezone: the former is sufficiently short that UI's can simply > display an > "exact" time (though note different leap second interpretations), > while the > latter is long enough that rounding off to the nearest day in the > local > timezone is fine. > > Supporting hour-level (or just seconds) precision has the > advantage of making > it easy for services like exchanges to use addresses with > relatively short > validity periods, to reduce the risks of losses after a hack. > Also, using at > least hour-level ensures we don't have any year 2038 problems. > > Thoughts? > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > <http://petertodd.org> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > <mailto:bitcoin-dev at lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > > -- > Chris Priest > 786-531-5938 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/c2fbfa44/attachment-0001.html>