During the works on new, trully atomic trading protocol (i.e., without the unpleasant malleability vulnerability), I explored several options. How does BIP112/OP_CheckSequenceVerify stand? Could it be used as a base for such a protocol?

Just a quick reminder, how this operation works. CheckSequenceVerify takes an argument that states for how long that output cannot be spent. It can be either time in seconds or time in number of blocks. Counting starts at the moment the transaction with this output gets into a block. The operation compares “age” of the output with the argument on top of the stack.

Using this operation, we can say, for instance, that an output can be spent only after at least two days from the moment the transaction was confirmed. This may sound like a feasible alternative to the previously proposed protocol where time-based locks are also used. So let’s take a closer look at this.

First, the script could look something like this:

  <Bob's public key>
  <24 hours>
  <Alice's public key>

No other special output script is needed, no presigned rollback transaction (that someone could attack using malleability) is needed. Now, this really looks promising, but it turns out that it cannot be safely used for Coincer’s purposes.

The time lock seems to always give a sufficient time frame for the other party to take action. However, it also means that time locks of both commitment transactions (Alice’s and Bob’s) become independent of each other. This leads to a potential issue: the transaction with a shorter time lock could get into a block with such a delay that its time lock would actually expire after the other transaction. Alice could then rollback her transaction and at the same time claim money from Bob’s transaction (using the value of x).

You see that it’s outside of Bob’s scope of influence when his transaction gets into a block (remember that not all cryptocurrencies support RBF and even then the possibilities may be limited). Due to these risks, Coincer doesn’t use OP_CSV for its protocol.