Possible race condition(double spend) on HTLC-Timeout in the lightning network?

Question

From the offered HTLC Outputs,

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

With the following conditions,

• a locktime is set to be 600900 in the HTLC-Timeout transaction.
• the remote node has the payment_secret.
• the local node wants to timeout the latest commitment transaction.

From my understanding, to timeout the latest commitment transaction, the local node has to,

1. broadcast the commitment transaction at blockheight 600900;
2. immediately broadcast the HTLC-Timeout transaction;
3. wait a few days to spend the HTLC-Timeout transaction once the specified timelock value has passed.

Meanwhile, the remote node with the payment_secret can spend the commitment transaction too. Will this cause a race condition/double spend in the Bitcoin network? If so, how can it be resolve?

Answer 1

First of all I think there seems to be a small confusion about the notation. One does not spend a transaction but transaction outputs. In the case of offered htlcs the output is only one (of potentially many others) output.

Also I understand the timelock slightly different. If you publish the commitment transaction it can be mined and verified directly. It is the time locked output e.g. the htlc that can only be spend after the timelock.

Regarding the racecondition / double spend. First of all double spends in Bitcoin are impossible by design (unless we have an unknown exploit) so we can boil it down to the question of a race condition. Here we have to distinguish two cases:

1. Before the timelock: in that case you cannot spend the htlc output and only the remote side can do so with the preimage. It is the safty Period for the remote side to get the funds if the htlc was supposed to be forwarded.
2. After the timelock: in that case in deed a race condition can emerge. At that time the remote side should not get the preimage but abort routing anyway but if you don't sweep the output and the remote side gets hold of the preimage then in deed it comes to which spend will be included to a block first.