FROST isn’t n-n multisig. It’s m-n threshold signature scheme. You combine several parts into a single signature. In the video, I create a 2 out of 3 sig.
Shielded sapling zcash has no scripting capability so I don’t think there will be shielded atomic swaps before halo.
I’d like to be proven wrong but I have a lot of skepticism towards projects that claim they can. Usually, it is either:
the logic is implemented out of chain, with some multi sig factor. As you said, there is a risk of counterparty,
or based on transparent zcash. In which case, a couple of days of work should suffice because of the similarity with bitcoin.
If someone has a design that doesn’t do either of these, it’d be very interesting to review it.
Thanks for the correction about FROST. Definitely my bad there.
To be clear, shielded atomic swaps (z <-> BTC) have already been done. It’s shielded <-> shielded that remain an issue, as the one protocol for it (Paymo) has a horrible UX. The reason I dislike FROST being included in these discussions is because as you say, it can’t be done atomically.
PayMo was for Monero, as was Bitcoin-Monero Cross-chain Atomic Swap. That didn’t stop the latter from being implemented for ZCash. Both currencies can be reduced to having a single private key for recovery, letting all other keys be shared as mutual knowledge. I don’t see why it wouldn’t be possible to implement PayMo’s VDFs over JubJub instead of Ed25519, hence why I’m discussing it. That said, I will admit to not being an expert cryptographer versus just someone who knows how to put things together.
I was going to post the above, yet I’m an idiot who misremembered the PayMo paper. I thought it implemented key recovery using a VDF, yet it implements signatures with a VDF. While that may be quickly applicable to ZCash, as if I’m reading this correctly, it’s about encoding a scalar of the signature as a VDF, which isn’t tied directly into signing and therefore doesn’t need to be ported to RedDSA, I don’t have enough cryptographic knowledge to properly comment. The point I wanted to make, which is true regardless of PayMo specifically, is VDF based swaps are the one path I know of (and I believe anyone knows of at this time) for scriptless swaps. PayMo is just the first paper to actually utilize VDFs in swaps, hence why I brought it up.
I do want to note PayMo explicitly supports usage in Schnorr signatures as well, not just ring signatures. If it’s truly encoding scalars from signatures (which is where my cryptography knowledge bows out, so I easily could be wrong here, sorry), then the scalar component of the RedDSA signature from the authorizing spend key should be usable. ask is what I recovered when implementing z <-> t atomic swaps.
There are much “easier” ways to do that in zcash (HTLC & ZTE). Yet, it still takes a huge amount of work to get right. I think we agree that the best course of action is to see how we can use Halo. Tbh, I am not sure what the situation will be (between the marketing materials, the technical papers, and the code). But I hope we won’t have to come up with complex workarounds anymore.
Sorry, how do you propose to do a shielded <-> shielded swap with a HTLC? The whole issue is that they don’t have scripting functionality. Also, I’m not familiar with the phrase ZTE.
As for Halo, I’m still not sure how it helps. I don’t see any multisig offerings as beneficial, so if that’s the only reason it ‘helps’ here…
If you don’t need to shielded <-> shielded, then there’s already fully working code for that, and yes, it uses a HTLC on one side. I’m explicitly only suggesting PayMo for shielded <-> shielded (and I’m not even doing that as the UX is horrible. I’m commenting it’s the only protocol theoretically enabling them).
As for TZE, that breaks privacy to a degree. If you don’t mind breaking privacy to a degree, all you have to do is temporarily unshield to a P2SH and then reshield, That ‘solves’ shielded swaps by… not solving them. Yes, TZE would still be a step up as it wouldn’t leak the amount, but it still reveals a swap happened which can be problematic.
As for custom circuits, I haven’t heard any discussion of a TX being able to define its own circuit, and that sounds incredibly problematic for a lot of reasons. That said, even if it was implemented, you’d have the same issue as TZE. It’d reveal a swap happened. That doesn’t solve shielded <-> shielded.
TL;DR Unshielded <-> Shielded is solved. The only discussion is about solving Shielded <-> Shielded. The only thing currently in front of us for that is PayMo. P2SH can be used as a compromise, and TZE is another compromise that doesn’t reveal the amounts. They aren’t fully private however, like PayMo offers. PayMo isn’t feasible due to a UX standpoint though.