Hi ZmnSCPxj,
>Would this not work?
I considered and rejected that model for the following reason: there are moments where both Alice and Bob can claim the BTC. If they both attempt to do so, it also reveals both secrets, causing the LTC to also be claimable by both parties. This chaotic scenario is a failure mode that did not seem acceptable to me. The revoke transaction was specifically added to mitigate that issue (invalidating any attempt of Bob to claim the coins and reveal his secret). That said, it doesn't particularly seem in either party's interest wait until a moment where two timelocks become valid, so maybe it is not quite as bad as I thought. However, it still means that the incompetence/malevolence of one party can lead to losses for both parties. I have my doubts a gain in privacy in the uncooperative case is worth that risk.
Of course it also reverts the protocol to 3 transactions, instead of 2, but regardless, not having to watch the chain is probably more practical in many cases. As an aside, if both chains support timelocks then we can ensure that the more expensive chain only receives one transaction.
>if relative locktimes are used as often as absolute locktimes for block-sniping-prevention and a decent Scriptless Script system, then all protocol aborts should be doable with no information leaks
I see your point, interesting observation.
>A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on the LTC side would not be in that HD, and if Alice wants to cold-store the LTC, it should move the money as well into an HD pubkey.
Agreed, I had that listed as one of the disadvantages: "Access to money is contingent on remembering secrets (backup complexity)"
Cheers,
Ruben