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
Discussion
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.