What role do timelocks play in PTLCs?

Let's say Alice wants to do an atomic swap, trading X BTC for Y XYZ from Bob. Here’s how I see HTLC working: 1. Alice generates a secret s and sends the hash H = h(s) to Bob, along with her BTC and XYZ addresses, plus the timeout points tA and tB where tA > tB for her HTLC and his. 2. Bob replies back to Alice with his BTC and XYZ addresses. 3. Alice sets up an HTLC that will send X BTC to Bob if he provides the preimage for H, or she gets a refund after tA. If Bob vanishes right after, she can just wait for tA and get her funds back. 4. Bob sets up his own HTLC that sends Y XYZ to Alice if she shows the preimage for H, or he can claim a refund after tB. If Alice disappears after that, he can wait for tB and get his money back. 5. Alice gives s to Bob’s HTLC and gets Y XYZ. 6. Bob finds s in the transaction data and uses it to claim X BTC from Alice's HTLC. I'm aiming for a similar grasp on PTLCs, but most of what I find talks about adaptor signatures and doesn’t really cover the timelocks or what happens if someone backs out at any point. Based on Bitcoin Optech’s example, do we just include the timelock in the transaction message m for each adaptor signature? If so, is there anything different from HTLCs or do we still just need tA > tB?

Yes, the timelocks are incorporated into the transactions similarly to HTLCs. Specifically, the timelock can be included in the transaction data or in the adaptor signatures themselves to ensure that the time conditions are respected. By integrating the timelock into the transaction message m, you ensure that the time constraints become an integral part of the swap agreement, allowing the involved parties to perform claim or refund actions The condition that tA is greater than tB remains in place to ensure the security of the atomic swap. This relationship prevents scenarios where one party could exploit the system to improperly obtain funds. Therefore, it is still necessary to maintain the hierarchy of timeouts to ensure that, in the event of a failure or aborting of the swap, each party can safely perform a refund. There are no fundamental differences regarding tA > tB when comparing PTLCs with HTLCs

I still don't really understand it. The message mA in Alice's adaptor signature would say "pay Bob X BTC if current time < tA, else pay Alice X BTC". The message mB in Bob's adaptor signature would say "pay Alice Y XYZ if current time < tB, else pay Bob Y XYZ". Both adaptor signatures require Alice's secret tweak t to complete into a Schnorr signature for the message. And yet if they both lock up their funds in their PTLCs and then Alice disappears, how can Bob turn his adaptor signature into a Schnorr signature to be able to execute his refund path? Alice never gave him the tweak t.

You are ignoring a very important part, which is that PTLCs typically combine adaptor signatures with multi-party signatures (like MultiSig) "Adaptor signatures alone often cannot fully guarantee a contract... This issue is usually resolved by combining adaptor signatures with multi-party signatures. For example, Alice deposits her funds into an address that can only be spent if she and Bob collaborate to create a valid signature"  So, in your example, when Alice disappears, Bob does not need Alice's tweak t to execute his refund. After the time tB, Bob can use a separate pre-agreed refund transaction path that does not require completing the adaptor signature. This refund mechanism would be built into the initial setup of the swap, similar to how HTLCs handle it This is why documentation notes that adaptor signatures typically require "a time-locked refund option in case one party refuses to sign." The refund path is separate from the adaptor signature path used for successful execution of the swap

Somehow I totally missed that part, thanks! Although now I'm confused about the "Alice could double spend her payment to Bob after she learned Bob’s signature" part. Bob's signature would be valid for a transaction for a specific set of UTXO inputs, wouldn't this prevent it from being used for a second transaction? Or is this referring to the fact that nothing is stopping Alice from spending the UTXOs in the adaptor-signed transaction she sends to Bob before he has the opportunity to redeem?

Observe these 3 characteristics:  - UTXOs  - Fund destinations  - Time conditions (timeouts)  Bob's signature cannot be reused for another transaction that changes any of these parameters. If Alice tries to create a second transaction using the same UTXOs, Bob's signature will not be valid for this new transaction As I mentioned above, PTLCs often combine adaptor signatures with multi-party signatures, so:  - Alice deposits her funds into a multi-sig address that requires collaboration between Alice and Bob to spend the funds - Bob holds a signature that is only valid for the specific transaction claiming the funds according to the swap terms (by presenting the secret s)     Refund Mechanism  As also mentioned earlier, in addition to swap transactions, there is a refund path that Bob can use in case Alice disappears or does not complete the swap:  - Bob does not need Alice's tweak t to execute the refund - After the timeout tB, he can sign the refund transaction using his own key, independently of Alice Consider the following scenario:  Bob signs a specific transaction that can only be executed with Alice's secret s, and Alice cannot sign additional transactions spending the same UTXOs without Bob's collaboration Thus, Alice cannot simply spend the UTXOs in another way without invalidating Bob's signature. If she attempts a double spend, the original transaction with Bob's signature will still be valid, and he will be able to execute the refund after the timeout After this magnificent explanation, do I deserve a donation?

I'll send you a few sats if I get get a swap working lol... thank you!

No problem, happy to help! Good luck with the swap!