<p>My first instinct was to write that we don't know this as we don't know how the exact protocol for PTLCs looks like but then I realized that unless someone finds a cool trick it will probably be hard to combine them for the following reason:</p>
<ol>
<li>With HTLCs we basically create an output in the commitment transaction that can be spend by the receiver if the receiver provides a digital signature coming and a preimage <code>r</code> to an hash <code>h = H(r)</code>.</li>
<li>With PTLCs, we basically create an output that can be spend if someone can provide a digital signature to the address rising from the public key <code>rG</code> that comes from a secret <code>r</code> which is multiplied with the generator point <code>G</code></li>
<li>In order to make routing secure, we use the concept of atomicity in multihop locks. In the HTLC world all HTLCs commit to the same payment hash and a routing node sees the incoming HTLC and knows it is safe to offer an HTLC on a downstream channel with the same payment hash as it is able to settle / claim the incoming one. Similarly, in the PTLC world (I simplified the fact that we actually use different secrets for every hop through the adaptor trick but I don't think that this will rescue us as it heavily makes use of the linearity when going from secrets to points).</li>
</ol>
<p>Long story short, <code>rG != H(r)</code>  which means that a node that is offered an HTLC with the payment hash <code>H(r)</code> would not know against which point it would have to commit the PTLC to make the entire operation atomic and actually be guaranteed to receive a secret that would also work against the offered HTLC. Similarly, in the other way around. In both cases, the security of everything is based on the idea that you can't find the the value <code>r</code> that produced <code>H(r)</code> or the value <code>r</code> that produced <code>rG</code>.</p>
<p>Disclaimer: This question addresses recent R&amp;D and of course I might have overseen something here.</p>

CC BY-SA 4.0
2021-08-31T01:24:07.677Z
I just learned that with the help of a zero knowledge proof one might actually be able to commit to the hash / point coming from the same secret. So maybe there is a way after all to make htlcs and ptlcs compatible at least in one direction (in contradiction to my initial reply)
Rene Pickhardt
CC BY-SA 4.0
2021-08-23T20:13:11.087Z
2021-08-24T03:59:14.520Z
2021-08-24T03:59:14.520Z
Rene Pickhardt
<p>When PTLCs get introduced on the Lightning Network, do all hops along a route need to use just one of either HTLCs or PTLCs, or would it be possible to create a route where some nodes use PTLCs and some use HTLCs?</p>

<lightning-routing><hash-time-locked-contract><point-time-locked-contract>
Can PTLCs and HTLCs be mixed along a route?
Murch
# Can PTLCs and HTLCs be mixed along a route?

(Asked by: username_0 on 2021-08-23)

When PTLCs get introduced on the Lightning Network, do all hops along a route need to use just one of either HTLCs or PTLCs, or would it be possible to create a route where some nodes use PTLCs and some use HTLCs?

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


---

## 1 answers

### Answer by username_1 on 2021-08-23. Score: 4 | Accepted answer

My first instinct was to write that we don't know this as we don't know how the exact protocol for PTLCs looks like but then I realized that unless someone finds a cool trick it will probably be hard to combine them for the following reason:

1. With HTLCs we basically create an output in the commitment transaction that can be spend by the receiver if the receiver provides a digital signature coming and a preimage `r` to an hash `h = H(r)`.
2. With PTLCs, we basically create an output that can be spend if someone can provide a digital signature to the address rising from the public key `rG` that comes from a secret `r` which is multiplied with the generator point `G`
3. In order to make routing secure, we use the concept of atomicity in multihop locks. In the HTLC world all HTLCs commit to the same payment hash and a routing node sees the incoming HTLC and knows it is safe to offer an HTLC on a downstream channel with the same payment hash as it is able to settle / claim the incoming one. Similarly, in the PTLC world (I simplified the fact that we actually use different secrets for every hop through the adaptor trick but I don't think that this will rescue us as it heavily makes use of the linearity when going from secrets to points).

Long story short, `rG != H(r)` which means that a node that is offered an HTLC with the payment hash `H(r)` would not know against which point it would have to commit the PTLC to make the entire operation atomic and actually be guaranteed to receive a secret that would also work against the offered HTLC. Similarly, in the other way around. In both cases, the security of everything is based on the idea that you can't find the the value `r` that produced `H(r)` or the value `r` that produced `rG`.

Disclaimer: This question addresses recent R&D and of course I might have overseen something here.

> **Comments:**
> **username_1**: I just learned that with the help of a zero knowledge proof one might actually be able to commit to the hash / point coming from the same secret. So maybe there is a way after all to make htlcs and ptlcs compatible at least in one direction (in contradiction to my initial reply)  

---

