Author: Billy Tetrud 2021-04-12 20:04:51
Published on: 2021-04-12T20:04:51+00:00
In a bitcoin-dev mailing list, a discussion was sparked around Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER. A user suggested that software could be written to warn users about edge cases and argued that if a person waited for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They also believed that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software was not seen as a good reason to block an opcode, and they were curious if there was something more to this or if thinking was simply decided that OP_BLOCKNUMBER wasn't useful enough to warrant the potential footgun of people accepting sub-6-block transactions from a transaction that uses an expired spend-path. Another user suggested accomplishing the goal of a rough expiry by having two transactions: tx A with desired expiry at H and tx B with nlocktime H and using the same inputs as A, creating outputs equivalent to inputs. After a timeout, the participants in A can cancel the action using TX B. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asked if there was any way to specify a maximum block height on a transaction and believed it would be useful. Overall, the discussion revolved around the implementation of OP_BLOCKNUMBER and its potential risks and limitations.
Updated on: 2023-06-14T20:03:16.249142+00:00