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:npub1psm37hke2pmxzdzraqe3cjmqs28dv77da74pdx8mtn5a0vegtlas9q8970 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:npub1c8cp58lhn4vte3q2fejp7luqczx7u0njk5h0p0hry3atflk7g2hqc7xzqk
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.
