I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY (OP_BBV) which is similar to ones that have been discussed before (eg OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a number representing a block height, and marks the transaction invalid if the current block the transaction is being evaluated for is greater than or equal to that block height, the transaction is invalid. I wrote up a bip for OP_BBV here.

The motivation for this opcode is primarily to do switch-off kinds of transactions. Eg, an output that contains both a spend path that uses OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a particular block one person can spend, and after that block a different person can spend. This can allow doing things like expiring payments or reversible payments in a cheaper way. Currently, things like that require a sequence of multiple transactions, however OP_BBV can do it in a single transaction, making these applications a lot more economically feasible. 

The particular application I'm most interested in is more efficient wallet vaults. However, wallet vaults requires other new opcodes, and I've been given the (good, I think) advice to start off this discussion with something a bit more bite sized and manageable. So I want to keep this discussion to OP_BBV and steer away from the specifics of the wallet vaults I'm thinking of (which are more involved, requiring other new opcodes that I think makes more sense to discuss in a different thread).

The main thing I'd like to discuss is the historical avoidance of and stigma toward opcodes that can cause a valid transaction to become invalid.

It seems there are two concerns:

1. that an opcode like might create a DOS vector where a malicious actor might be able to spam the mempool with transactions containing this opcode.

2. that an opcode like this could cause "bad" reorg behavior, where in a reorg, transactions that were spent become not spend and not spendable because they were mined too near their expiry point. 

While I don't want to claim anything about opcodes that can cause spend paths to expire in general, I do want to claim that *some* opcodes like that are safe - in particular OP_BBV. In the context of OP_BBV specifically, it seems to me like item 1 (mempool handling) is a solvable problem and that point 2 (reorg issues) is not really a problem since people should generally be waiting for 6 confirmations and software can warn the user to wait for 6 confirmations in relevant scenarios where a 6-block reorg might reverse the transaction. I discuss this in detail in the Design Tradeoffs and Risks section of the document I wrote for OP_BBV. I'd love to hear thoughts from others on here about these things and especially the discussion of these issues in the document I linked to. 

Thanks,

BT