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.
> 
> 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:
> > 
> > 1) Hour resolution - 2^24 hours = 1914 years
> > 2) Month resolution - 2^16 months = 5458 years
> 
> 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.

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.

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

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