[bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

[Billy Tetrud <billy.tetrud@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

Hi Everyone,

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
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>
.

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
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>
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

[-- Attachment #2: Type: text/html, Size: 3532 bytes --]