From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9DD27C0175 for ; Wed, 22 Apr 2020 18:51:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 8D1D086AD8 for ; Wed, 22 Apr 2020 18:51:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9QdZsdg6Twc for ; Wed, 22 Apr 2020 18:51:00 +0000 (UTC) X-Greylist: delayed 00:07:57 by SQLgrey-1.7.6 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by fraxinus.osuosl.org (Postfix) with ESMTPS id F084586AD1 for ; Wed, 22 Apr 2020 18:50:28 +0000 (UTC) Received: by mail-wm1-f46.google.com with SMTP id x25so3649407wmc.0 for ; Wed, 22 Apr 2020 11:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=diviproject-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9nWBUSmJ4EavOiq/iF13xzrR0wLLoC3vTPrlQ8uH+Qs=; b=x2ql5mreOfa00ZAJBJzc2/0jOlU2wM/OXJBfxEO8GCPAXq+/sbKmZdHt1m0SumjTOj s46/KECHuRq7LValygG1leuYRdDKU61mkbPjnt1sY7Qm8UMn3+hMoboOiEY9UEIC8wiJ uPZYdwhiXnhoa4Bq/wJVGg2rReWU/DeA0F/jr2DGxd1cJ3W/o6YDPRzIroixjhaObg3g 7+VexLC+Czd44mm0DKbwIZ9VA6p4nopDXr5uj7Is2O5CqOfckjX/D85QdJk3rzO4BRJ3 QUNoernvAiKprMFTFVMCa73pitZuSrIuCDaQB+DnspdOpEC2sYGKq0+BapPlZGgw90ZT 4miQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9nWBUSmJ4EavOiq/iF13xzrR0wLLoC3vTPrlQ8uH+Qs=; b=KBkzqK9vyRuOAhRCd96n4lkUGT3tf9jeUv9BPsxVN/m86IAzmat249QrQ+UyhA5MUY LBE5RpLTzYOn/zOSWicSNG8WrzDvMo0HIjU42ENQG8g08Nz1OHMk+fsZ4NiZIgmt16yP Mtsh/rTcfR1+Mm8ssTlJA3oJdvLNpHsDIesKXjPKhp0YsJ5j45DD5pY2tiCcBHmY0vEq N0P3AgaoNqtR+kBBdAe6z6LWD0GP80dzAEOPn1KxLKflHSlslU2RBtWTLOU1DtKaiJxV amB1H7gi4u0x8IdeI/GH0SmNbSwVPUPbO520Cs3J5sqyOmlNv5gHKXqnznbTpAsNqNz0 7IAQ== X-Gm-Message-State: AGi0PuY+o0yEPQisP/vv0mxPDqIbowtxGhvfa4gKpHhF2tTDfsWi5FUJ DX5YJIcgu7iF1Ani/YRKoTP5m1ve2rqSmx867eCd1ej/ X-Google-Smtp-Source: APiQypKyym5gyGJG2Vm1rvCsb5Q4WMKA2bFGhlsmOrl3rZWrGzX+e/U8OvT4HvoMrcMCHhS214VF541scAK6jF22aW8= X-Received: by 2002:a1c:9e52:: with SMTP id h79mr12031654wme.84.1587580949486; Wed, 22 Apr 2020 11:42:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: German Luna Date: Wed, 22 Apr 2020 12:42:18 -0600 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000008bf12e05a3e57e53" X-Mailman-Approved-At: Wed, 22 Apr 2020 19:53:18 +0000 Subject: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 18:51:01 -0000 --0000000000008bf12e05a3e57e53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=80=9Cexchanged=E2=80=9D the history at= tached 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=E2=80= =99s 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 =3D Hash(P_A+P_B1) [whe= re the UTXO1 funds will be sent to eventually] and Addr2 =3D 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) != =3D 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) =3D 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, --=20 Germ=C3=A1n Mathematician --0000000000008bf12e05a3e57e53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,
## Objective
* Make atomic swaps within the same chain p= ossible in a traceless way
* Achieving traceless same-chain atomi= c-swaps effectively turns an entire chain into a=C2=A0 (P2PKH) mixer by def= ault

## Proposed solution
Si= milar 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 r= esult 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 th= e (schnorr) multisig that pays them.
On-chain, this would appear = like two independent transactions, even though effectively the two parties = have =E2=80=9Cexchanged=E2=80=9D the history attached to the UTXOs. Unlike = a mixing service, in which all of the histories get merged, with this proto= col histories can be pairwise swapped without anybody=E2=80=99s knowledge.<= /div>

## Protocol description
* Alice and Bob,= holding funds at UTXO1 (controlled by Alice) and UTXO2 (controlled by Bob)= wish to swap them.=C2=A0
* Alice provides Bob with a single publ= ic key P_A
* Bob provides Alice two pubkeys P_B1, P_B2.
* Bob and Alice construct the P2PKH addresses Addr1 =3D Hash(P_A+P_B1) [wh= ere the UTXO1 funds will be sent to eventually] and Addr2=C2=A0 =3D 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 tran= sactions sending the funds to Addr1 and Addr2.
* Bob and Alice submit th= e funding transactions (Alice pays to Addr1 from UTXO1; Bob pays to Addr2 f= rom UTXO2)
* Alice sends Bob an adaptor signature: r1=C2=A0+ H(r1 | m)*x= _a=C2=A0+ r2=C2=A0+ H( r2 | m')*x_a
* Bob verifies the adaptor signa= ture Alice sent contains a valid signature for spending from Addr1 AND anot= her valid signature for spending from Addr2. Both signatures from Alice. Bo= b cannot separate out the two signatures and hence cannot claim any of the = funds, provided H( r1 | m) !=3D H( r2 | m') in the signature commitment= .=C2=A0
* Bob now sends Alice the valid signature: r2=C2=A0+ H( r2 | m&#= 39; )*x_b2
* Alice can now add her signature to Bob's and get: r2 + = H( r2| m' )*(x_b2=C2=A0+ x_a) which is a valid signature to spend the f= unding transaction sent to Addr2.
* Finally, Bob sees Alice claim= s the fund sent to Addr2 and uses that signature to subtract his own: r2 + = H( r2 | m' )*(x_b2=C2=A0+ x_a) - (r2=C2=A0+ H( r2 | m' )*x_b2) =3D = H( r2 | m ')*x_a
* Bob takes the original adaptor signature and subt= racts the known quantity r2+ H( r2 | m' )*x_a, to get a valid signature= : r1=C2=A0+ H( r1 | m )*x_a
* Bob can now add to that valid signature, h= is 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 u= pon discarding signatures since the joint private keys (x_a=C2=A0+ x_b*)=C2= =A0are unavailable.

I'm interested in hearing = feedback on this idea if possible, and deemed interesting enough.

Best regards,
--
Germ=C3=A1n
Mathematician
--0000000000008bf12e05a3e57e53--