public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Priest <cp368202@ohiou.edu>
To: Peter Todd <pete@petertodd.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173
Date: Wed, 27 Sep 2017 13:35:33 -0600	[thread overview]
Message-ID: <CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com> (raw)
In-Reply-To: <20170927160654.GA12492@savin.petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 3759 bytes --]

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@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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Chris Priest
786-531-5938

[-- Attachment #2: Type: text/html, Size: 4837 bytes --]

  parent reply	other threads:[~2017-09-27 19:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 16:06 [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-27 18:15 ` CryptAxe
2017-09-27 19:03 ` Mark Friedenbach
2017-09-27 21:20   ` Peter Todd
2017-09-27 19:35 ` Chris Priest [this message]
2017-09-27 20:11   ` CryptAxe
2017-09-27 20:23   ` Nick Pudar
2017-09-27 20:19     ` CryptAxe
2017-09-27 21:09     ` Mark Friedenbach
2017-09-27 21:15   ` Peter Todd
2017-09-28  0:22   ` Gregory Maxwell
2017-09-27 21:33 ` Peter Todd
2017-09-28  0:58 ` Gregory Maxwell
2017-09-29  1:50   ` Peter Todd
2017-09-29  2:06     ` Gregory Maxwell
2017-09-28 10:09 ` Andreas Schildbach
2017-09-28 12:43   ` Sjors Provoost
2017-09-28 14:13     ` Andreas Schildbach
2017-09-28 14:41       ` Sjors Provoost
2017-09-28 15:06         ` Andreas Schildbach
2017-09-28 15:45           ` Sjors Provoost
2017-09-28 16:59       ` Luke Dashjr
2017-09-29  2:18     ` Peter Todd
2017-09-29  7:18       ` Sjors Provoost
2017-09-29  2:55     ` [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks Peter Todd
2017-09-29  4:21       ` Omar Shibli
2017-09-29 13:14       ` Tomas
2017-09-29 17:40         ` Aymeric Vitte
2017-09-30 15:33       ` Andreas Schildbach
2017-09-29  1:45   ` [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-29  8:44     ` Andreas Schildbach
2017-09-29  9:55       ` Peter Todd
2017-09-29 12:45         ` Andreas Schildbach
2017-09-29 13:52           ` Peter Todd
2017-09-29 17:25           ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com' \
    --to=cp368202@ohiou.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox