in this case you wouldn't even have co-op signing, so you can skip the fancy parts.
a simple aggregate public key would do. if you go multiplicative, a·b·G instead of (a+b)G then it's basically a DH key exchange. A·b = a·B, so Alice and Bob just reveal each other their pubkey for the session, and then both can generate the same address.
also note that there is no way to prove the relationship between b from B=b·G and H(b), but that is why you have the HTLC as a fallback.
on the happy path if Bob is playing honestly Alice can spend without revealing this was a swap. it just looks like a taproot keyspend. if not, then it is an HTLC plain and simple.
It sounds like you like it! Consider writing your own version with this improvement implemented. And help me convince nostr:nprofile1qqsqcdcltmv4qanpx3p7svcufdsg9rkk00x7l2sknra4e6whkv59l7cpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtccpdmsw to implement this, or maybe write a real version and compete with them
i think from a privacy pov it's definitely a good idea not to reveal on-chain that it's an HTLC and what was the hash lock/preimage on the happy path.
i'm not sure about how UX is improved otherwise.
started writing something up, will see if this helps me get back in the saddle. i should probably check out how submarine swaps work first before i go into more details, lol!
https://gist.github.com/moonsettler/eee3e283e70751154fdf5bc0ac7c1283
Not revealing anything about the swap on-chain is already pretty much the standard nowadays: https://blog.boltz.exchange/i/140971242/increased-privacy
is it interactive or non-interactive spend on the happy path?
based on this, interactive (proper MuSig2) nostr:nprofile1qyw8wumn8ghj7mn0wd68yttsw43zuum9d45hxmmv9ejx2a30qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsqgxp7qdplauatz7vgzjwvs0hlqxq3hhruu449mctacey0260ahjz4cp9efu7
correct
it's not a huge win, but you can make it non-interactive by making the private key share for the internal key the secret for the LN invoice. probably makes more sense for LN to on-chain swaps.
in theory this makes the user able to unilaterally pay straight up from the HTLC and swipe the change.
decreases server load and might improve UX. idk.
If you think about it, all submarine swaps are LN to on chain. Even when one party is going from on chain to LN, the other party is going from LN to on chain.
