From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <3CCFB7B0-10FC-4860-86C0-29472B76B129@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
Date: Fri, 29 Sep 2017 10:18:06 +0300
In-Reply-To: <20170929021846.GB12303@savin.petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <20170927160654.GA12492@savin.petertodd.org>
	<oqihpf$5gc$1@blaine.gmane.org>
	<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
	<20170929021846.GB12303@savin.petertodd.org>
Subject: Re: [bitcoin-dev] Address expiration times should be added to
	BIP-173
Precedence: list


--Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Op 29 sep. 2017, om 05:18 heeft Peter Todd <pete@petertodd.org> het =
volgende geschreven:
>=20
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via =
bitcoin-dev wrote:
>> Peter Todd wrote:
>> Perhaps outside the scope of BIP173, but what about baking it into =
the protocol? That way a transaction that's sent too late, simply won't =
get confirmed. This removes the need for refund logic or asking a =
customer to pay just 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
>=20
> This has been discussed many times before; there are *severe* =
downsides to
> making it possible for transactions to become invalid after the fact.

I've heard of that general principe, but I'm having trouble finding a =
good resource that describes it more precisely.

Is it a peer to peer or mempool issue? E.g a transaction might be =
accepted into the mempool and relayed at one point in time and suddenly =
become invalid before they're committed to a block? Or that a node =
receives a transaction, thinks it's invalid because the address already =
expired, but then receives an older block later which contains that =
transaction?

Once in a block, I don't see how it would become invalid later. But as a =
miner tries to find a block and updates the timestamp, they would have =
toss the transaction out at some point.

Another objection I can think of, is that the soft fork introducing this =
change would have to use a transaction type that's non-standard at the =
moment. This would make it difficult for a non-upgraded node to =
broadcast such a transaction. The recipient would have to know if the =
sender has upgraded before communicating an address, which sounds =
impractical at best.

>>> 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 instance a merchant doesn't care if the customer pays =
within 10:00:00 minutes or 10: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 is not practical.
>=20
> Note that "large range" is a requirement driven by the fact that =
expiry times
> will inevitably be specified absolutely, not relatively: when the =
range runs
> out you need to upgrade the standard. Better to use another character =
and use a
> range that won't run out any time soon.
>=20
> This wouldn't create a need for more checksum space.

You're right, relative time makes no sense. So it would take 5 =
characters to get roughly two minute resolution that lasts for 100 =
years.

Sjors


--Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlnN864ACgkQV/+b28ww
EAlPDhAAtLjb6pVImRmktnBPsPp+TVlb8k7tN+6PS5eyv6H+l890ogQzONLGFQJm
2uYFlfsrKAvya6lUDQQQoW7TWBlDawYJc/Ui3hXhT7aE+UjynlOVkuky3Zy2u/Jg
DYdG5RIZOWRNERxkIeFW2rxjEZA6tBjMyuIFw9UNWVlFCWMs9ss6WOLR4Wg64mg3
REED2qvE2VS38zDBLb/2pgws463fOrNW/cfQ4Cd3cKPc0agLub7S/MgRzZUtn+n5
xfz/20tLEyaKhkFrU5BFQ8m32aCvHyscurn1OPx3t+Z1rQJ5GQAU4EucEoiXQ+F2
FAOw1S5omHK+6ZGWDtVMrALCrKmEBL8wlLKMRlGMKK3DdIx/YVcB2yA79zDdS0V7
3ezCX9lj/sJQ/sb+cY4GmO+3kztekzgX+gDncW9tFViMLstwbR6GIGSodDVbuWjK
mioLSnagwMSbElaDh3TKACoZPYlOuCM1BID4v2JaKjXLXk4tGUP7ahV9n4lshsMI
HVH4WdqmJZJ7uvqaOjaEz0lQSZqt2Q54gugrveUBnlRsqO+1RWYKgUshEfQr6EN5
ajZcyLxZ8oeiLw99e29zELxajX56/51Jzrt/valeffhxGiPmpUqgGi+HQHeLgv+X
/1IQj5G/y/HBrwNQdQ18E2GG2ut9HjjNlu5x4QavuHHgTqJk+6M=
=melJ
-----END PGP SIGNATURE-----

--Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983--