<p>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.</p>

<p>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. </p>

<p>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:</p>

<ol>
<li>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.</li>
<li>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. </li>
</ol>

CC BY-SA 4.0
2019-10-25T07:57:42.293Z
Thank you for your answer! Yet the local commitment tx needs to be broadcasted with the htlc-timeout tx, otherwise, there would be no race condition. I'm wondering whether it's the preimage holder's responsibility to avoid the race condition?
yyforyongyu
CC BY-SA 4.0
2020-10-05T12:51:32.067Z
So I have a question over here. Suppose the timeout period is 600900 and the HTLC_success transaction is broadcasted at 600959th block. Meanwhile, at 600900, the HTLC-timeout is also broadcasted. In this case, which one will get included in the blockchain?
Subhra Mazumdar
CC BY-SA 4.0
2021-01-08T03:03:06.193Z
@SubhraMazumdar The HTLC success and timeout transactions are spending the same output, so they can't both be mined.
Janus Troelsen
CC BY-SA 4.0
2019-10-24T21:13:13.240Z
2019-10-24T21:13:13.240Z
Rene Pickhardt
<p>From the offered HTLC Outputs,</p>

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

<p>With the following conditions,</p>

<ul>
<li>a <code>locktime</code> is set to be 600900 in the HTLC-Timeout transaction.</li>
<li>the remote node has the <code>payment_secret</code>.</li>
<li>the local node wants to timeout the latest commitment transaction.</li>
</ul>

<p>From my understanding, to timeout the latest commitment transaction, the local node has to,</p>

<ol>
<li>broadcast the commitment transaction at blockheight 600900;</li>
<li>immediately broadcast the HTLC-Timeout transaction;</li>
<li>wait a few days to spend the HTLC-Timeout transaction once the specified timelock value has passed.</li>
</ol>

<p>Meanwhile, the remote node with the <code>payment_secret</code> 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?</p>

<bitcoin-core><lightning-network><hash-time-locked-contract><lightning-rfc>
Possible race condition(double spend) on HTLC-Timeout in the lightning network?
yyforyongyu
# Possible race condition(double spend) on HTLC-Timeout in the lightning network?

(Asked by: username_0 on 2019-10-24)

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?

**Tags:** bitcoin-core, lightning-network, hash-time-locked-contract, lightning-rfc


---

## 1 answers

### Answer by username_1 on 2019-10-24. Score: 3

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.

> **Comments:**
> **username_0**: Thank you for your answer! Yet the local commitment tx needs to be broadcasted with the htlc-timeout tx, otherwise, there would be no race condition. I'm wondering whether it's the preimage holder's responsibility to avoid the race condition?  
> **username_2**: So I have a question over here. Suppose the timeout period is 600900 and the HTLC_success transaction is broadcasted at 600959th block. Meanwhile, at 600900, the HTLC-timeout is also broadcasted. In this case, which one will get included in the blockchain?  
> **username_3**: @username_2 The HTLC success and timeout transactions are spending the same output, so they can't both be mined.  

---

