<blockquote>
  <p>As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).</p>
</blockquote>

<p>I believe you have overlooked the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#committing-updates-so-far-commitment_signed" rel="nofollow noreferrer"><code>commitment signed message</code> from bolt 02</a>. From there I quote:</p>

<blockquote>
  <p>When a node has changes for the remote commitment, it can apply them, sign the resulting transaction (as defined in BOLT #3), and send a commitment_signed message.</p>
</blockquote>

<pre><code>type: 132 (commitment_signed)
data:
[32:channel_id]
[64:signature]
[2:num_htlcs]
[num_htlcs*64:htlc_signature]
</code></pre>

<p>While we already see that signatures for all htlcs are transferred we can find the requirements further down :</p>

<blockquote>
  <p>A sending node:
  ... 
  MUST include one htlc_signature for every HTLC transaction corresponding to the ordering of the commitment transaction (see BOLT #3).</p>
</blockquote>

<p>I believe a node SHOULD NOT  forward the htlc before it validated the signatures from all the htlcs of the received commitment signed. </p>

CC BY-SA 4.0
2019-05-27T12:14:28.443Z
2019-05-27T19:57:15.590Z
2019-05-27T19:57:15.590Z
Rene Pickhardt
<p>According to BOLT #3, when constructing a HTLC output in the version of the local node (both received and offered HTLC), it requires that the payment to the local node is locked with <code>CHECKMULTISIG</code> opcode that requires both <code>localhtlcsig</code> and <code>remotehtlcsig</code> in order to spend it.</p>

<p>As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint). </p>

<p>So the question: suppose after I receive an HTLC from a node and I successfully pass it to the other nodes, the node that sent the HTLC to me became unresponsive. Now I will need to broadcast my version of the commitment transaction to the Bitcoin blockchain so that I can claim the funds that are locked with the <code>payment_hash</code> (when I receive one). But, in order to spend that output, my witness stack will need to have <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; &lt;payment_preimage&gt;</code>. Now, if the remote node is offline, how will I get my hands on the <code>remotehtlcsig</code> in order to get back the funds locked in the HTLC?</p>

<p>Just to provide additional details, below is a local node version of the received HTLC output according to BOLT #3</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_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
        2 OP_SWAP &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP &lt;cltv_expiry&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
</code></pre>

<lightning-network><lightning-routing><hash-time-locked-contract>
Remote node signature for HTLC-success and HTLC-timeout transactions
Ugam Kamat
# Remote node signature for HTLC-success and HTLC-timeout transactions

(Asked by: username_0 on 2019-05-27)

According to BOLT #3, when constructing a HTLC output in the version of the local node (both received and offered HTLC), it requires that the payment to the local node is locked with `CHECKMULTISIG` opcode that requires both `localhtlcsig` and `remotehtlcsig` in order to spend it.

As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).

So the question: suppose after I receive an HTLC from a node and I successfully pass it to the other nodes, the node that sent the HTLC to me became unresponsive. Now I will need to broadcast my version of the commitment transaction to the Bitcoin blockchain so that I can claim the funds that are locked with the `payment_hash` (when I receive one). But, in order to spend that output, my witness stack will need to have `0 <remotehtlcsig> <localhtlcsig> <payment_preimage>`. Now, if the remote node is offline, how will I get my hands on the `remotehtlcsig` in order to get back the funds locked in the HTLC?

Just to provide additional details, below is a local node version of the received HTLC output according to BOLT #3

```
# 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_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

```

**Tags:** lightning-network, lightning-routing, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2019-05-27. Score: 2 | Accepted answer

> As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).

I believe you have overlooked the [`commitment signed message` from bolt 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#committing-updates-so-far-commitment_signed). From there I quote:

> When a node has changes for the remote commitment, it can apply them, sign the resulting transaction (as defined in BOLT #3), and send a commitment\_signed message.

```
type: 132 (commitment_signed)
data:
[32:channel_id]
[64:signature]
[2:num_htlcs]
[num_htlcs*64:htlc_signature]

```

While we already see that signatures for all htlcs are transferred we can find the requirements further down :

> A sending node:
> ...
> MUST include one htlc\_signature for every HTLC transaction corresponding to the ordering of the commitment transaction (see BOLT #3).

I believe a node SHOULD NOT forward the htlc before it validated the signatures from all the htlcs of the received commitment signed.


---

