Topic: How do timelocks come into play for PTLCs? (Read 145 times)
No problem, happy to help! Good luck with the swap!
I'll send you a few sats if I get get a swap working lol... thank you!
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?
- 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?
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?
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
"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
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.
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.
Quote
would we just add the timelock into the transaction message m in each adaptor signature?
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 actionsQuote
If so, is anything different from how it is in HTLCs, or is all we need still tA > tB?
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
Suppose Alice agrees to atomic swap X BTC for Y XYZ owned by Bob. Here's my understanding of an HTLC implementation:
1. Alice creates secret s and sends H = h(s) to Bob, along with her BTC address, her XYZ address, and the proposed timeout points tA > tB for her and his HTLC respectively
2. Bob sends Alice his BTC and XYZ addresses back to Alice
3. Alice funds an HTLC that sends X BTC to Bob if he can present the preimage to H, or allows Alice to refund after tA. If Bob disappears right after, she can wait till tA and claim her refund.
4. Bob funds an HTLC that sends Y XYZ to Alice if she can present the preimage to H, or allows Bob to refund after tB. If Alice disappears right after, he can wait till tB and claim his refund.
5. Alice presents s to Bob's HTLC and claims Y XYZ.
6. Bob learns s from the transaction data and presents it to Alice's HTLC to claim X BTC.
I'm trying to get a similar level of understanding for PTLCs, but most resources seem to focus on the adaptor signatures and not where the timelocks go, or exactly what happens when a party aborts in each stage. Going off of Bitcoin Optech's example (https://bitcoinops.org/en/topics/adaptor-signatures/), would we just add the timelock into the transaction message m in each adaptor signature? If so, is anything different from how it is in HTLCs, or is all we need still tA > tB?
1. Alice creates secret s and sends H = h(s) to Bob, along with her BTC address, her XYZ address, and the proposed timeout points tA > tB for her and his HTLC respectively
2. Bob sends Alice his BTC and XYZ addresses back to Alice
3. Alice funds an HTLC that sends X BTC to Bob if he can present the preimage to H, or allows Alice to refund after tA. If Bob disappears right after, she can wait till tA and claim her refund.
4. Bob funds an HTLC that sends Y XYZ to Alice if she can present the preimage to H, or allows Bob to refund after tB. If Alice disappears right after, he can wait till tB and claim his refund.
5. Alice presents s to Bob's HTLC and claims Y XYZ.
6. Bob learns s from the transaction data and presents it to Alice's HTLC to claim X BTC.
I'm trying to get a similar level of understanding for PTLCs, but most resources seem to focus on the adaptor signatures and not where the timelocks go, or exactly what happens when a party aborts in each stage. Going off of Bitcoin Optech's example (https://bitcoinops.org/en/topics/adaptor-signatures/), would we just add the timelock into the transaction message m in each adaptor signature? If so, is anything different from how it is in HTLCs, or is all we need still tA > tB?
Jump to: