Published on: 2021-05-03T02:30:07+00:00
The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined.
Updated on: 2023-08-02T03:34:07.044664+00:00