📅 Original date posted:2017-09-29
📝 Original message:Op 29 sep. 2017, om 05:18 heeft Peter Todd <pete at petertodd.org> het volgende geschreven:
>
> 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.
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:
>>>
>>> 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/47107d36/attachment.sig>;
Sjors Provoost [ARCHIVE] /
npub1ux…7wq7p
2023-06-07 18:06:26
in reply to nevent1q…uzgc
Author Public Key
npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7pPublished at
2023-06-07 18:06:26Event JSON
{
"id": "15ff4b0feaac67a62de97a74db505c8973d3aaf6249a97f031122b2b08beb4c2",
"pubkey": "e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e",
"created_at": 1686161186,
"kind": 1,
"tags": [
[
"e",
"02d8c76b933e43bf4fbef62deb34ae55389c59e653682f6f8847f8910b9dcb32",
"",
"root"
],
[
"e",
"649fb495d0650a246015e0edd38a8a60be84fa3859fb8baf19dc44bf2b5b4390",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2017-09-29\n📝 Original message:Op 29 sep. 2017, om 05:18 heeft Peter Todd \u003cpete at petertodd.org\u003e het volgende geschreven:\n\u003e \n\u003e On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote:\n\u003e\u003e Peter Todd wrote:\n\u003e\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\u003e \n\u003e\u003e Two downsides I can think of:\n\u003e\u003e * privacy, as differences in expiration policy would be visible on chain\n\u003e\u003e * miners might be able to game it in their interaction with brokers\n\u003e \n\u003e This has been discussed many times before; there are *severe* downsides to\n\u003e making it possible for transactions to become invalid after the fact.\n\nI've heard of that general principe, but I'm having trouble finding a good resource that describes it more precisely.\n\nIs 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?\n\nOnce 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.\n\nAnother 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.\n\n\u003e\u003e\u003e Being just an expiration time, seconds-level resolution is unnecessary, and\n\u003e\u003e\u003e may give the wrong impression. I'd suggest either:\n\u003e\u003e\u003e \n\u003e\u003e\u003e 1) Hour resolution - 2^24 hours = 1914 years\n\u003e\u003e\u003e 2) Month resolution - 2^16 months = 5458 years\n\u003e\u003e \n\u003e\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\u003e \n\u003e Note that \"large range\" is a requirement driven by the fact that expiry times\n\u003e will inevitably be specified absolutely, not relatively: when the range runs\n\u003e out you need to upgrade the standard. Better to use another character and use a\n\u003e range that won't run out any time soon.\n\u003e \n\u003e This wouldn't create a need for more checksum space.\n\nYou're right, relative time makes no sense. So it would take 5 characters to get roughly two minute resolution that lasts for 100 years.\n\nSjors\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/47107d36/attachment.sig\u003e",
"sig": "574803ef6395269a4878c14e79ba9c85856092b52c34dffe4ecb7bd6995c08a46768a03ef06af402b8521a90af73336911044faf83aaf52d4d6b936e8802df14"
}