public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
@ 2021-06-10 17:35 Billy Tetrud
  2021-06-10 18:35 ` Russell O'Connor
  0 siblings, 1 reply; 11+ messages in thread
From: Billy Tetrud @ 2021-06-10 17:35 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- 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 --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-06-13 22:12 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-10 17:35 [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block Billy Tetrud
2021-06-10 18:35 ` Russell O'Connor
2021-06-10 22:19   ` Billy Tetrud
2021-06-10 23:20     ` Russell O'Connor
2021-06-11  5:59       ` Billy Tetrud
2021-06-11 11:12         ` James MacWhyte
2021-06-11 11:43           ` Russell O'Connor
2021-06-12  7:59             ` Billy Tetrud
2021-06-12 15:58               ` Russell O'Connor
2021-06-12 18:48                 ` Billy Tetrud
2021-06-13 22:12                   ` Billy Tetrud

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox