Author: Sjors Provoost 2017-09-29 07:18:06
Published on: 2017-09-29T07:18:06+00:00
The discussion on Bitcoin development mailing list on Sep 28, 2017, revolved around the idea of baking expiration policy into the protocol. The proposal was to disallow a transaction that gets confirmed too late, thus removing the need for refund logic or asking customers to pay extra. However, there are severe downsides to making this possible as discussed before. It is unclear if it is a peer-to-peer or mempool issue. Once in a block, a transaction does not become invalid later. But, as miners try to find a block and update the timestamp, they would have to toss out the transaction at some point. Another objection is that the soft fork introducing this change would have to use a non-standard transaction type, which would make it difficult for a non-upgraded node to broadcast such a transaction.The discussion also covered the resolution required for setting the expiration time. Hour resolution - 2^24 hours, which equals 1914 years, or month resolution - 2^16 months = 5458 years, were suggested as alternatives to seconds-level resolution. A large range seems more useful than high precision, and relative time makes no sense. It would take five characters to get roughly two-minute resolution that lasts for 100 years. Using another character and a range that won't run out anytime soon would not create a need for more checksum space.
Updated on: 2023-06-12T19:07:01.109375+00:00