<p>To enforce the HTLC semantic, the offered and received HTLC outputs must <em>only</em> be spendable through the paths outlined in the schema.</p>
<p>If we were to require a single signature, from the remote party, on these outputs then they could unilaterally spend this output. We need both parties to commit to the logic of the contract, and this is done with a multisig and presigned transactions.</p>

CC BY-SA 4.0
2022-08-01T09:12:15.833Z
2022-08-01T09:12:15.833Z
Antoine Poinsot
<p>Because also in the second stage (which are the offered htlcs) there is the revocation and penalty mechanism. Since this mechanism always works via 2-2 multisig addresses this also needs signatures from the remote channel partner</p>

CC BY-SA 4.0
2022-03-04T06:12:18.500Z
2022-03-04T06:12:18.500Z
Rene Pickhardt
<pre><code>  |        +-------------+
  \--------| commit tx B |
           +-------------+

              |  |  |  |  
              |  |  |  | A's main output
              |  |  |  \------------------ to A
              |  |  |
              |  |  |
              |  |  |                  ,-- to B (&amp; delay)
              |  |  | B's main output /
              |  |  \----------------&lt;
              |  |                    \ 
              |  |                     `-- to A (&amp; revocation key)
              |  |
              |  |                                                ,-- to B (&amp; delay)
              |  |                        +-----------------+    /
              |  |                     ,--| HTLC-timeout tx |---&lt;
              |  | HTLC offered by B  /   +-----------------+    \
              |  \-------------------&lt;     (after timeout)        `-- to A (&amp; revocation key)
              |                       \
              |                        `-- to A (&amp; payment preimage)
              |                        \
              |                         `- to A (&amp; revocation key)
              |                   
              |                                                   ,-- to B (&amp; delay)
              |                           +-----------------+    /
              |                        ,--| HTLC-success tx |---&lt;
              | HTLC received by B    /   +-----------------+    \
              \----------------------&lt;     (w/ payment preimage)  `-- to A (&amp; revocation key)
                                      \
                                       `-- to A (after timeout)
                                       \
                                        `- to A (&amp; revocation key)
</code></pre>
<p>The above is the logic  found in <a href="https://github.com/lightning/bolts/issues/553" rel="nofollow noreferrer">here</a>.</p>
<p>And i find that when i go into the 2nd stage, it always needs a 2 of 2 multisig. I think it's enough to get remote signature to go to the 2nd stage, so why do i need to sign here by myself.</p>

<lightning-network>
Why do i need two signatures to enter 2nd stage in lightning network?
KHJUAF403456ZS3K564WAEF
# Why do i need two signatures to enter 2nd stage in lightning network?

(Asked by: username_0 on 2022-03-04)

```
  |        +-------------+
  \--------| commit tx B |
           +-------------+

              |  |  |  |  
              |  |  |  | A's main output
              |  |  |  \------------------ to A
              |  |  |
              |  |  |
              |  |  |                  ,-- to B (& delay)
              |  |  | B's main output /
              |  |  \----------------<
              |  |                    \ 
              |  |                     `-- to A (& revocation key)
              |  |
              |  |                                                ,-- to B (& delay)
              |  |                        +-----------------+    /
              |  |                     ,--| HTLC-timeout tx |---<
              |  | HTLC offered by B  /   +-----------------+    \
              |  \-------------------<     (after timeout)        `-- to A (& revocation key)
              |                       \
              |                        `-- to A (& payment preimage)
              |                        \
              |                         `- to A (& revocation key)
              |                   
              |                                                   ,-- to B (& delay)
              |                           +-----------------+    /
              |                        ,--| HTLC-success tx |---<
              | HTLC received by B    /   +-----------------+    \
              \----------------------<     (w/ payment preimage)  `-- to A (& revocation key)
                                      \
                                       `-- to A (after timeout)
                                       \
                                        `- to A (& revocation key)

```

The above is the logic found in [here](https://github.com/lightning/bolts/issues/553).

And i find that when i go into the 2nd stage, it always needs a 2 of 2 multisig. I think it's enough to get remote signature to go to the 2nd stage, so why do i need to sign here by myself.

**Tags:** lightning-network


---

## 2 answers

### Answer by username_1 on 2022-08-01. Score: 1

To enforce the HTLC semantic, the offered and received HTLC outputs must *only* be spendable through the paths outlined in the schema.

If we were to require a single signature, from the remote party, on these outputs then they could unilaterally spend this output. We need both parties to commit to the logic of the contract, and this is done with a multisig and presigned transactions.


---

### Answer by username_2 on 2022-03-04. Score: 1

Because also in the second stage (which are the offered htlcs) there is the revocation and penalty mechanism. Since this mechanism always works via 2-2 multisig addresses this also needs signatures from the remote channel partner


---

