From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 02AD7C0175 for ; Thu, 23 Apr 2020 17:56:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id DFCC3876DD for ; Thu, 23 Apr 2020 17:56:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfX2cqpUCHXF for ; Thu, 23 Apr 2020 17:56:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by whitealder.osuosl.org (Postfix) with ESMTPS id DF11A87E32 for ; Thu, 23 Apr 2020 17:56:13 +0000 (UTC) Date: Thu, 23 Apr 2020 17:56:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587664571; bh=Be6EcEqfg3oYwbNCAvIt5m0tFH2JMnQ2s1T1SNFh/wk=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=GipFb6M5lLm+mPcsslp2ZO+T82sol+QtVharV6tf58aXvpZWDdgaM4SQKGx7RokmG d/yIQtEOV6jNMCDCmqZV+Ilkz3baMP77uxbPfadHZ8ieN2eULAumlPSp5d2UKrJ3IV yuZxKWppLUOMvI1lBPKPakPy7an/au00Qirez4rI= To: German Luna , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Thu, 23 Apr 2020 17:56:16 -0000 Good morning Germ=C3=A1n, 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=C2=A0 (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 p= lace of the secret 't' - a suitably chosen schnorr signature. The end resul= t being that when one counterparty claims their side of the funds, the part= y can obtain the signature they're missing to claim the funds in the (schno= rr) multisig that pays them. > On-chain, this would appear like two independent transactions, even thoug= h 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 histori= es 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.=C2=A0 > * 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) [w= here 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 = 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=C2=A0+ H(r1 | m)*x_a=C2=A0+ r2= =C2=A0+ H( r2 | m')*x_a > * Bob verifies the adaptor signature Alice sent contains a valid signatur= e for spending from Addr1 AND another valid signature for spending from Add= r2. 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.=C2=A0 > * Bob now sends Alice the valid signature: r2=C2=A0+ H( r2 | m' )*x_b2 > * Alice can now add her signature to Bob's and get: r2 + H( r2| m' )*(x_b= 2=C2=A0+ x_a) which is a valid signature to spend the funding transaction s= ent to Addr2. > * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that sig= nature 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 subtracts the known quanti= ty 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, his own signature and retrieve= the funds. > ## Notes > * It is possible for the counterparty to store copies of the signatures a= s proof that such a join has taken place. But plausible deniability is avai= lable upon 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 i= nteresting enough. > > Best regards, > -- > Germ=C3=A1n > Mathematician