š
Original date posted:2017-09-28
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/04fb5921/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 18:06:26
in reply to nevent1qā¦2qr5
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:06:26Event JSON
{
"id": "649fb495d0650a246015e0edd38a8a60be84fa3859fb8baf19dc44bf2b5b4390",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161186,
"kind": 1,
"tags": [
[
"e",
"02d8c76b933e43bf4fbef62deb34ae55389c59e653682f6f8847f8910b9dcb32",
"",
"root"
],
[
"e",
"18670721fa763220783b4ed4855d61314fe38423dab6d2395b795f7d93798712",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "š
Original date posted:2017-09-28\nš Original message:On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote:\n\u003e Peter Todd wrote:\n\u003e 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.\n\u003e \n\u003e Two downsides I can think of:\n\u003e * privacy, as differences in expiration policy would be visible on chain\n\u003e * miners might be able to game it in their interaction with brokers\n\nThis has been discussed many times before; there are *severe* downsides to\nmaking it possible for transactions to become invalid after the fact.\n\n\u003e \u003e Being just an expiration time, seconds-level resolution is unnecessary, and\n\u003e \u003e may give the wrong impression. I'd suggest either:\n\u003e \u003e \n\u003e \u003e 1) Hour resolution - 2^24 hours = 1914 years\n\u003e \u003e 2) Month resolution - 2^16 months = 5458 years\n\u003e \n\u003e 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.\n\nNote that \"large range\" is a requirement driven by the fact that expiry times\nwill inevitably be specified absolutely, not relatively: when the range runs\nout you need to upgrade the standard. Better to use another character and use a\nrange that won't run out any time soon.\n\nThis wouldn't create a need for more checksum space.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/04fb5921/attachment.sig\u003e",
"sig": "7e940b6e7a93211bbca6e6821e34e490a33ba60e96af6833fa6dca18570a92a9cb5267bbdb883d6697e109c19b15ba5bb95881e8f319428b789900b29e490090"
}