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
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
