<p>Digital signature algorithms take a “message” they are committing to as an input. In the case of Bitcoin transactions, this message is a digest of the transaction data specific to each input referred to as <em>signed hash</em>. Additionally, a random secret nonce <code>k</code> is used to create a signature (although some signing implementations pick this nonce deterministically).</p>
<p>So, when signing</p>
<ul>
<li>inputs of different transactions with the same key</li>
<li>different inputs of the same transaction with the same key</li>
<li>the same input of the same transaction a second time</li>
</ul>
<p>you will still always produce a new unique signature (with the exception of the last case which will produce exactly the same signature when performed with a deterministic nonce).</p>
<p>IIRC HTLCs always use a new key taken from a hierarchical deterministic chain of keys derived from a <em>basepoint</em> shared with their channel partner on channel opening. This construction allows for effective reconstruction of the relevant keys from a minimal backup while using distinct keys for each output ever added to the channel's commitment transactions. I suspect that always using the same key would still be secure but a bad privacy leak, but have not verified this theory.</p>

CC BY-SA 4.0
2022-12-30T19:18:29.020Z
2022-12-30T19:18:29.020Z
Murch
<p>I have a question regarding the security of HTLCs in a LN-channel.
In a LN-transaction with multiple HTLCs (routings) to the destination one is using the signature of each node provider so that the first one who knows the secret &quot;R&quot; is not able to spend the other HTLCs in the channel.</p>
<p>That means for redemption of an HTLC the following criteria have to be presented:</p>
<ul>
<li>Signature</li>
<li>Secret &quot;R&quot;</li>
</ul>
<p>If I am participating in two LN-channels. Is it then necessary out of security reasons to use two private keys so that my signature for the two HTLCs are not identical?</p>
<p>Example:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>LN-channel 1</th>
<th>LN-channel 2</th>
</tr>
</thead>
<tbody>
<tr>
<td>1. Alice</td>
<td>1. Dina</td>
</tr>
<tr>
<td>2. Bob</td>
<td>2. Bob</td>
</tr>
<tr>
<td>3. Chan</td>
<td>3. Chan</td>
</tr>
<tr>
<td>4. Eve</td>
<td>4. Tom</td>
</tr>
</tbody>
</table>
</div>
<p>Let's suppose Bob uses for both channels the same private key.</p>
<ol>
<li>Chan receives the secret &quot;R1&quot; from Eve (channel 1) and &quot;R2&quot; from Tom (channel 2) after providing the respective funds to them.</li>
<li>Now Chan can provide the secret &quot;R2&quot; to Bob, who uses his signature to unlock the HTLC to Dina.</li>
<li>If Bob has used to same private key for both HTLCs, couldn't Chan now copy and paste the signature from Bob from channel 2 and use the known secret &quot;R1&quot; to unlock the HTLC between Bob and Alice?</li>
</ol>
<p>Can someone verify or help me to correctly understand it?
Thank you very much in advance.</p>

CC BY-SA 4.0
2022-12-30T16:56:19.273Z
I have researched a little bit further. I assume the answer is that the signatures would be different even though using the same private key, because the signature is created with the private key and transaction data. So they would differ in the LN-Channel 1 and 2. Can someone confirm this? Thank you!
Robee
<lightning-network><signature><hash-time-locked-contract>
LN-Channel: Do I have to use new private keys for each HTLCs out of security?
Robee
# LN-Channel: Do I have to use new private keys for each HTLCs out of security?

(Asked by: username_0 on 2022-12-30)

I have a question regarding the security of HTLCs in a LN-channel.
In a LN-transaction with multiple HTLCs (routings) to the destination one is using the signature of each node provider so that the first one who knows the secret "R" is not able to spend the other HTLCs in the channel.

That means for redemption of an HTLC the following criteria have to be presented:

* Signature
* Secret "R"

If I am participating in two LN-channels. Is it then necessary out of security reasons to use two private keys so that my signature for the two HTLCs are not identical?

Example:

| LN-channel 1 | LN-channel 2 |
| --- | --- |
| 1. Alice | 1. Dina |
| 2. Bob | 2. Bob |
| 3. Chan | 3. Chan |
| 4. Eve | 4. Tom |

Let's suppose Bob uses for both channels the same private key.

1. Chan receives the secret "R1" from Eve (channel 1) and "R2" from Tom (channel 2) after providing the respective funds to them.
2. Now Chan can provide the secret "R2" to Bob, who uses his signature to unlock the HTLC to Dina.
3. If Bob has used to same private key for both HTLCs, couldn't Chan now copy and paste the signature from Bob from channel 2 and use the known secret "R1" to unlock the HTLC between Bob and Alice?

Can someone verify or help me to correctly understand it?
Thank you very much in advance.

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

> **Comments:**
> **username_0**: I have researched a little bit further. I assume the answer is that the signatures would be different even though using the same private key, because the signature is created with the private key and transaction data. So they would differ in the LN-Channel 1 and 2. Can someone confirm this? Thank you!  

---

## 1 answers

### Answer by username_1 on 2022-12-30. Score: 1

Digital signature algorithms take a “message” they are committing to as an input. In the case of Bitcoin transactions, this message is a digest of the transaction data specific to each input referred to as *signed hash*. Additionally, a random secret nonce `k` is used to create a signature (although some signing implementations pick this nonce deterministically).

So, when signing

* inputs of different transactions with the same key
* different inputs of the same transaction with the same key
* the same input of the same transaction a second time

you will still always produce a new unique signature (with the exception of the last case which will produce exactly the same signature when performed with a deterministic nonce).

IIRC HTLCs always use a new key taken from a hierarchical deterministic chain of keys derived from a *basepoint* shared with their channel partner on channel opening. This construction allows for effective reconstruction of the relevant keys from a minimal backup while using distinct keys for each output ever added to the channel's commitment transactions. I suspect that always using the same key would still be secure but a bad privacy leak, but have not verified this theory.


---

