Author: Luke Dashjr 2017-05-13 05:26:58
Published on: 2017-05-13T05:26:58+00:00
In a discussion on 13 May 2017, Russell O'Connor expressed his concern that implementing a construction based on opcode would encourage miners to false signal readiness, which undermines both BIP 9 and BIP 8. However, Luke-Jr argued that this was not the case. He suggested that rather than using the script system for this construction, it would be better to use the transaction version number instead by soft-forking in a rule that says when the most significant bits of a transaction version are 001 then the transaction can only be included in blocks whose lower 29 version bits are set at the same position as the lower 29 version bits set in the transaction version.Luke-Jr also mentioned that versionbits change/lose their meaning after the deployment timeout. For this reason, the timeout must be specified, so the check is skipped when that occurs. He further added that doing it the way O'Connor described would fail to enforce that BIP9 is actually in use for the block version, and it would not be possible to upgrade versionbits anymore.Additionally, Luke-Jr stated that making use of the transaction version number is superior to adding an opcode because it does not interfere with caching of script validity. Script validity can still be cached with this method: the opcode would always be allowed to succeed at evaluation-time, and the criteria checked separately.
Updated on: 2023-06-12T00:47:47.157962+00:00