|
Title: OP_CSV, opt-in RBF, and making outputs invalid after timelock Post by: colatkinson on January 10, 2018, 11:10:02 PM 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 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? Title: Re: OP_CSV, opt-in RBF, and making outputs invalid after timelock Post by: achow101 on January 11, 2018, 01:58:45 AM 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.Title: Re: OP_CSV, opt-in RBF, and making outputs invalid after timelock Post by: pebwindkraft on January 11, 2018, 08:59:37 AM 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? Quote IF 2 [alice pubkey] [bob pubkey] 2 CHECKMULTISIGVERIFY ELSE [time] CHECKSEQUENCEVERIFY DROP [bob pubkey] ENDIF CHECKSIG Title: Re: OP_CSV, opt-in RBF, and making outputs invalid after timelock Post by: colatkinson on January 11, 2018, 12:47:33 PM 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 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. |