Date: Thu, 28 Sep 2017 21:50:48 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20170929015048.GC11956@savin.petertodd.org>
References: <20170927160654.GA12492@savin.petertodd.org>
	<CAAS2fgRpMXdqKXeYSOtVBQQ9fmu=nQ9anEO6Wrc_5rms1Y2B2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRpMXdqKXeYSOtVBQQ9fmu=nQ9anEO6Wrc_5rms1Y2B2w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Address expiration times should be added to
	BIP-173
Precedence: list


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

On Thu, Sep 28, 2017 at 12:58:30AM +0000, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 4:06 PM, 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 a=
lso
> > operationally: services like exchanges frequently have problems with us=
ers
> > sending funds to addresses whose private keys have been lost or stolen;=
 there
>=20
> When Pieter and I were working on Bech32 we specifically designed for
> error correcting codes that had good performance for longer lengths
> than we technically needed specifically to incorporate things like
> dates and explicit amounts.
>=20
> (explicit amounts so that typos and bit flips in amounts displayed or
> in memory couldn't result in sending the wrong amount)
>=20
> But we also thought that also adding those features at the same time
> would retard adoption-- both due to debating over the encodings and
> because handling would result in different software requirements and
> layering, so you couldn't just drop them in.

Notably, even something as simple as adding a new type of confirmation wind=
ow
that might be needed is a big chance to UI logic.

> Doubly unfortunately, people have even deployed BIP173 already (prior
> to it even having much peer review or being adopted by its own
> authors), so I think a rethink now wouldn't be timely (I mean as a
> replacement to BIP173 rather than an additional format). :(

Yeah, I just noticed Pieter Wuille's BIP173-including segwit pull-req - tha=
t's
a lot of code that would get touched by this proposal, so it's likely too l=
ate
in the process.

> But I do support the idea.
>=20
> One thing to keep in mind is that address format linked fields are
> most efficient if they're multiples of 5 bits.  Perhaps use 1 bit to
> indicate an embedded amount and 19 bits of 1 day precision, resulting
> in a 1435 year span.

What do you mean by "an embedded amount"?

> Keep in mind that high precision of the expiration times is asking the
> sender to have a higher precision of idea of the time, date only is
> kinda nice.  I think shorter expiration times are unlikely to be
> useful due to clock skew-- you can't assume a signer has any access to
> the Bitcoin network at all.

I'm inclined to agree as well. Also, Bitcoin payments themselves are inhere=
ntly
imprecise, because blocks aren't found on a regular interval - Coinbase's "=
10
minute" payment expiry window is odd from that point of view.

Having said that, you'd want a resolution more precise than what you'd expe=
ct
timeouts to be set at, to avoid UI "fencepost" oddity; if I want to set a 1=
 day
timeout, users shouldn't see either 1 or 2 days depending on exactly which =
way
it happened to be rounded that particular time..

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

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

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

iQEcBAEBCAAGBQJZzab0AAoJECSBQD2l8JH760oIAJjxYsHo1bjJijWiJB4XE2lp
HrKdBjMQWJH3voNjYtyKtVadCV+0m1PqJGxlHsunUEmVGtjz30jBQozNd0nhpMVd
MMhkbx35gO5qqq7IWpts8K0luv7olxLFcNFqcEkZ3hl1ECrgkwxrUf8JteceabdU
pjlqPWkTnde4jjeMbASZDVrWTnQLQlHZAKPSnoJduztCbOfa47mf+iR+ihAljXd6
sY7Io+k3KGrd8OiapBlCSTApxHHQD9vHssiLgD7ARRmkLmXlzpEjiCSChqpoQoso
iSG9kqVmOz1l2u5+Cs89THwTajs1mgC/eqyV5h/Jc3Y3iITmSgxuHMteoJkME6M=
=ZCTH
-----END PGP SIGNATURE-----

--HG+GLK89HZ1zG0kk--