Date: Wed, 27 Sep 2017 12:06:54 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20170927160654.GA12492@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L"
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [bitcoin-dev] Address expiration times should be added to BIP-173
Precedence: list


--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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; the=
re
are multiple examples of exchanges getting hacked, with users continuing to
lose funds well after the actual hack has occured due to continuing deposit=
s.
This also makes it difficult operationally to rotate private keys. I person=
ally
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 ti=
me
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 terminol=
ogy
questions. Notably, the entire notion of addresses is flawed from a user po=
int
of view: their experience with them should be more like "payment codes", wi=
th 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 =3D 1914 years
2) Month resolution - 2^16 months =3D 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 maki=
ng
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?

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZy8ybAAoJECSBQD2l8JH7y9kIAIp4JjzOvx6rWSGgQ69GGPtD
mrPY53XnOICzhqNQ3t0i8v7vp2QN3sLCIUX2auomcoQhup0KxJWH+rPuQ6HIRNdr
mpgo9QC79RYqWmuucCseIdUVRXkfOeX4MwGcgODnNkvMl4fTYJMj8eiqONJrpOBz
NV6XBPnhrQSbs0E6Mkzk1phjyt0TckeH3XEdlvi6wPOOGKLRxFAdQG0T6QBLRlpg
7yRdqRoacybUMiyFnGJE5WJBiiiNO7W84WrB/DQFJfvYRGNHUsMIHR/E5F9fkrdn
NKh3d06lKnIMfDav6HxRvIT7rG/keb7ci2L0HfEMiytSheocFb+oVdT8v8QMRrQ=
=vqyK
-----END PGP SIGNATURE-----

--FCuugMFkClbJLl1L--