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

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 than 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 trasaction that can be spend by the receiver if they recipient 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 save 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 hope through the adoptor trick but I don’t think that this will rescue us as it heavily makes use of the lineary when going from secrets to poins.

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 secrete 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