maximum block height on transaction



Summary:

The email thread discusses the idea of specifying maximum block height on a transaction. An argument against using an opcode to impose the max-block constraint is that it would greatly increase CPU usage because the script cache would need to be reworked. Adding a field would significantly increase code complexity to the level of SegWit, without all the important bugfixes+features (tx malleability, quadratic sighash, well-defined extensible outputs) that SegWit provides. It is suggested that a second `nLockTime`d transaction can be used to do what one wants, which is easier and requires less computation power. The email also discusses some technical aspects of Bitcoin Core implementation, such as how SCRIPT is evaluated only when a transaction enters the mempool and not at any other time, and how the mempool assumes that once a SCRIPT accepts, it will always accept in the future.


Updated on: 2023-06-14T20:02:50.589933+00:00