From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 27 Sep 2017 12:03:44 -0700
Message-Id: <31968FFC-11BC-4331-B602-70B1F74AEEFC@friedenbach.org>
References: <20170927160654.GA12492@savin.petertodd.org>
In-Reply-To: <20170927160654.GA12492@savin.petertodd.org>
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
Precedence: list

While there is a lot that I would like to comment on, for the moment I will j=
ust mention that you should consider using the 17 bit relative time format u=
sed in CSV as an offset from the birthdate of the address, a field all addre=
sses should also have.

This would also mean that addresses cannot last more than a year without use=
r override, which might actually be a plus, but you could also extend the fi=
eld by a few bits too if that was deemed not acceptable. An address should n=
ot be considered valid longer than anticipated lifetime of the underlying cr=
yptosystem in any case, so every address should have an expiry.

> On Sep 27, 2017, at 9:06 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
> 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; th=
ere
> are multiple examples of exchanges getting hacked, with users continuing t=
o
> lose funds well after the actual hack has occured due to continuing deposi=
ts.
> This also makes it difficult operationally to rotate private keys. I perso=
nally
> 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 fres=
h
> one.
>=20
> To help combat this problem, I suggest that we add a UI-level expiration t=
ime
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time i=
s
> reached.
>=20
> Unfortunately, this proposal inevitably will raise a lot of UI and termino=
logy
> questions. Notably, the entire notion of addresses is flawed from a user p=
oint
> of view: their experience with them should be more like "payment codes", w=
ith a
> code being valid for payment for a short period of time; wallets should no=
t be
> displaying addresses as actually associated with specific funds. I suspect=

> we'll see users thinking that an expired address risks the funds themselve=
s;
> some thought needs to be put into terminology.
>=20
> Being just an expiration time, seconds-level resolution is unnecessary, an=
d
> may give the wrong impression. I'd suggest either:
>=20
> 1) Hour resolution - 2^24 hours =3D 1914 years
> 2) Month resolution - 2^16 months =3D 5458 years
>=20
> 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 th=
e
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>=20
> Supporting hour-level (or just seconds) precision has the advantage of mak=
ing
> 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 a=
t
> least hour-level ensures we don't have any year 2038 problems.
>=20
> Thoughts?
>=20
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev