Date: Thu, 28 Sep 2017 22:18:46 -0400
From: Peter Todd <pete@petertodd.org>
To: Sjors Provoost <sjors@sprovoost.nl>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170929021846.GB12303@savin.petertodd.org>
References: <20170927160654.GA12492@savin.petertodd.org>
	<oqihpf$5gc$1@blaine.gmane.org>
	<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM"
Content-Disposition: inline
In-Reply-To: <B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] Address expiration times should be added to
	BIP-173
Precedence: list


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

On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wr=
ote:
> Peter Todd wrote:
> Perhaps outside the scope of BIP173, but what about baking it into the pr=
otocol? That way a transaction that's sent too late, simply won't get confi=
rmed. This removes the need for refund logic or asking a customer to pay ju=
st a few extra cents. You could also disallow a second payment.
>=20
> Two downsides I can think of:
> * privacy, as differences in expiration policy would be visible on chain
> * miners might be able to game it in their interaction with brokers

This has been discussed many times before; there are *severe* downsides to
making it possible for transactions to become invalid after the fact.

> > Being just an expiration time, seconds-level resolution is unnecessary,=
 and
> > 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
> So that's 4.8 characters for hours, or 3.2 for years, plus checksum space=
? The shorter the better. Perhaps one or two bits can be used to specify an=
 exponent; a large range seems more useful than high precision. For instanc=
e a merchant doesn't care if the customer pays within 10:00:00 minutes or 1=
0:00:01 minutes and you wouldn't care if your address is valid 50 years or =
50 years and 3 minutes. This point may be mute if minute level resolution i=
s not practical.

Note that "large range" is a requirement driven by the fact that expiry tim=
es
will inevitably be specified absolutely, not relatively: when the range runs
out you need to upgrade the standard. Better to use another character and u=
se a
range that won't run out any time soon.

This wouldn't create a need for more checksum space.

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

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

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

iQEcBAEBCAAGBQJZza2CAAoJECSBQD2l8JH75kUIALvQHss2EXm9I7sHNJC/viZ+
1W8UlAyvuQLAg2ZJdK3bk0+7LT8uGDysqe6QeThexIyBMxjGjGl8zerdbxKiLwym
OEQgWueU1/lVqMuKweUwW3NpuLZvlwtnttGW8lYVIs5wrCelADKHFgDKTQBdvenq
W7sSsYlNB87IRoCqi5edGq+TT7xqx0U5AshK5Fg6KWVmfiVRUbGrVQVwW2gKMOI7
2v4td49JWlupyJ28d3GN/+ZzVz/PDN/WXqR3x/7Pg4URyLYYXmb9Vcp1V9mwLWGH
1HSIM/OFEiHOXhUDQWT8jNjuGWX9j/6yPESGQ8mi+olgy/u/UdSwDxaB4BMgWzs=
=1bzB
-----END PGP SIGNATURE-----

--ZfOjI3PrQbgiZnxM--