Good morning Germán, It looks to me like this is CoinSwap with Schnorr Scriptless Scripts.
* https://joinmarket.me/blog/blog/coinswaps/ * https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/ I also recently put up an article on extending such a protocol across 3 or more participants: * https://zmnscpxj.github.io/bitcoin/multiswap.html Regards, ZmnSCPxj > ## Objective > * Make atomic swaps within the same chain possible in a traceless way > * Achieving traceless same-chain atomic-swaps effectively turns an entire > chain into a (P2PKH) mixer by default > > ## Proposed solution > Similar to the way that atomic swaps would work with schnorr signatures (i.e. > leveraging adaptor signatures), the proposed solution is to use - in place of > the secret 't' - a suitably chosen schnorr signature. The end result being > that when one counterparty claims their side of the funds, the party can > obtain the signature they're missing to claim the funds in the (schnorr) > multisig that pays them. > On-chain, this would appear like two independent transactions, even though > effectively the two parties have “exchanged” the history attached to the > UTXOs. Unlike a mixing service, in which all of the histories get merged, > with this protocol histories can be pairwise swapped without anybody’s > knowledge. > > ## Protocol description > * Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2 > (controlled by Bob) wish to swap them. > * Alice provides Bob with a single public key P_A > * Bob provides Alice two pubkeys P_B1, P_B2. > * Bob and Alice construct the P2PKH addresses Addr1 = Hash(P_A+P_B1) [where > the UTXO1 funds will be sent to eventually] and Addr2 = Hash(P_A+P_B2) > [where the UTXO2 funds will be sent to eventually] > * Bob and Alice exchange time-locked refund transactions for the funding > transactions sending the funds to Addr1 and Addr2. > * Bob and Alice submit the funding transactions (Alice pays to Addr1 from > UTXO1; Bob pays to Addr2 from UTXO2) > * Alice sends Bob an adaptor signature: r1 + H(r1 | m)*x_a + r2 + H( r2 | > m')*x_a > * Bob verifies the adaptor signature Alice sent contains a valid signature > for spending from Addr1 AND another valid signature for spending from Addr2. > Both signatures from Alice. Bob cannot separate out the two signatures and > hence cannot claim any of the funds, provided H( r1 | m) != H( r2 | m') in > the signature commitment. > * Bob now sends Alice the valid signature: r2 + H( r2 | m' )*x_b2 > * Alice can now add her signature to Bob's and get: r2 + H( r2| m' )*(x_b2 + > x_a) which is a valid signature to spend the funding transaction sent to > Addr2. > * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that > signature to subtract his own: r2 + H( r2 | m' )*(x_b2 + x_a) - (r2 + H( r2 | > m' )*x_b2) = H( r2 | m ')*x_a > * Bob takes the original adaptor signature and subtracts the known quantity > r2+ H( r2 | m' )*x_a, to get a valid signature: r1 + H( r1 | m )*x_a > * Bob can now add to that valid signature, his own signature and retrieve the > funds. > ## Notes > * It is possible for the counterparty to store copies of the signatures as > proof that such a join has taken place. But plausible deniability is > available upon discarding signatures since the joint private keys (x_a + > x_b*) are unavailable. > > I'm interested in hearing feedback on this idea if possible, and deemed > interesting enough. > > Best regards, > -- > Germán > Mathematician _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
