Published on: 2015-09-22T17:45:00+00:00
The discussions surrounding the implementation of a "fill-or-kill" system in Bitcoin transactions revolve around finding a consensus on how to ensure transaction safety, validity, and ease of use. One proposal suggests requiring OP_MATURITY 100 in all scriptPubKeys of the expiry transaction to make them as reorg-safe as coinbase transactions, but this may not work well with p2sh. Another proposal is to implement a "treat like Coinbase" flag in the UTXO set when creating the output. Some developers argue for using accurate terminology, such as nExpiryTime instead of fill or kill, to facilitate learning and understanding.There is also a discussion about the maturity requirement for these transactions. Dropping the 100 block maturity requirement could resolve delays in receiving funds, making the system more appealing to recipients. However, another developer points out that this would not make the transactions as safe as mined bitcoins, which have additional requirements and costs.In terms of implementation, suggestions include repurposing a small range of nLockTime or adding a new nKillTime field to the transaction. However, the latter would require a hardfork. Other alternatives discussed involve embedding nKillTime data within other unused fields or utilizing per-input nKillTime and nLockTime with nSequence.A fill-or-kill system can be implemented by utilizing the unused range in Satoshi's implementation of nLockTime. This involves introducing two new parameters, nLockTime2 and nKillTime, which determine the functionality of the system. The resolution for this system is four blocks or 2048 seconds, with a maximum confirmation window of 8188 blocks or 16,769,024 seconds. Activation of the system is achieved by setting a bit flag in the transaction nVersion.It should be noted that the growth of nLockTime will never catch up with nLockTime2. For height-based nLockTime2, the lock time with the new rule must be 1-2048 seconds later than the original rule for every nLockTime2 value greater than or equal to 720,000, resulting in a soft fork. Similarly, for time-based nLockTime2, confirmation is not allowed until a specific median time-past, also requiring a soft fork.To customize transaction confirmation times, users can set their desired values for nLockTime2 and nKillTime. However, compatibility issues arise with height-based OP_CLTV, necessitating the creation of a new OP_CLTV2 to verify both nLockTime and nLockTime2.The height-based nLockTime2 will eventually overflow in 55 years, which would require a hard fork to implement a more effective fill-or-kill system. Alternatively, if a hard fork does not occur, a new tx nVersion could be used to restart the system for another 55 years.In summary, a fill-or-kill system can be established by leveraging the unused range in Satoshi's nLockTime implementation through the use of nLockTime2 and nKillTime parameters. However, compatibility issues arise with height-based OP_CLTV, necessitating the creation of a new OP_CLTV2. Additionally, the height-based nLockTime2 will eventually overflow, potentially leading to a necessary hard fork for system improvement.
Updated on: 2023-08-01T16:11:01.346247+00:00