German Luna [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-22 📝 Original message:Hello All, ## Objective * ...

📅 Original date posted:2020-04-22
📝 Original message:Hello All,

## 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200422/1253207d/attachment.html>;