OP_CSV, opt-in RBF, and making outputs invalid after timelock

[colatkinson]

It's my understanding that all transactions spending an OP_CHECKSEQUENCEVERIFY input will have RBF implicitly enabled (as all valid nSequence locktimes are less than 0xFFFFFF).

I was wondering what the recommended solution for a case where the contract is something like

Code:

IF
    [alice pubkey]
ELSE
    [time] CHECKSEQUENCEVERIFY DROP
    [bob pubkey]
ENDIF
CHECKSIG

Where the goal is that Bob can spend the funds only after an escrow period, but Alice can spend them at any time, revoking payment for an ongoing service between the two. As I understand it, the effects of RBF would be such that Alice would be able to spend this output, even after Bob has published it to the network.

My question is essentially: is there any way to make it so that Alice could not spend the output after the relative locktime has passed?

[achow101]

My question is essentially: is there any way to make it so that Alice could not spend the output after the relative locktime has passed?

No, there is no way for that currently.

[pebwindkraft]

Implicitly the network would make it impossible, that Alice spends the funds after CSV (and Bob executed the tx). If Alice then spends, it would be a double spend?
So question remains, if Bob did not execute the tx, then how to prevent Alice from still spending it?
When there is no direct possibility, a workaround might be to extend first condition?

IF
    2 [alice pubkey] [bob pubkey] 2 CHECKMULTISIGVERIFY
ELSE
    [time] CHECKSEQUENCEVERIFY DROP
    [bob pubkey]
ENDIF
CHECKSIG

[colatkinson]

So I've done some more thinking about this, and I think I've come up with a solution. The contract would be as follows

Code:

IF
    0 CHECKSEQUENCEVERIFY DROP
    <alice pubkey>
ELSE
    <lock date> CHECKLOCKTIMEVERIFY DROP
    <bob pubkey>
ENDIF
CHECKSIG

If Alice wishes to spend before lock date, she publishes a transaction with the input sequence number set as [0x0000, 0xffff]. Bob cannot double spend, as his transaction would not be accepted into the mempool.

If Bob wishes to spend after lock date, he publishes a transaction with the appropriate nLockTime and the input sequence number set as 0xfffffffe, signaling that it is using locktime and is not replaceable.

If Alice publishes a transaction after lock date, then Bob can publish his with a slightly higher fee, which will supersede Alice's due to the higher nSequence. The one potential weakness I can see is if Alice intentionally publishes a version with extremely high fees, essentially destroying some of the funds Bob is owed.