From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 76D8EC0051 for ; Thu, 20 Aug 2020 21:38:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 59F8122122 for ; Thu, 20 Aug 2020 21:38:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDMsV1mkpZtu for ; Thu, 20 Aug 2020 21:38:29 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by silver.osuosl.org (Postfix) with ESMTPS id 4C83A204BF for ; Thu, 20 Aug 2020 21:38:29 +0000 (UTC) Date: Thu, 20 Aug 2020 21:38:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1597959506; bh=EJphkyuL38lOSdg32iC5YmGj9PfWVOtK4vMFfU7BTxM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=SP7LVnlt16BBMRRBMd6cnrJ1SIpg/bQIsJGNIw+DZSd8Y/D6asZij3MvxS7vfL87L 9u1bTmqlhsQkJ68BZtpxXFG8ylJla4XnFzoiiR9etmcP7Fyja7KbPAU16rUQ+TupXM P4v6ucQKNLqBUeE5OQTLP6ilukrDHjkt1AYITZZg= To: Nadav Kohen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap 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, 20 Aug 2020 21:38:33 -0000 Good morning Nadav, > Hey Chris and all, > > Looking good :) I have one major concern though > > >=C2=A0 =C2=A0 q =3D EC privkey generated by maker > >=C2=A0 =C2=A0 Q =3D q.G =3D EC pubkey published by maker > > > >=C2=A0 =C2=A0 p =3D nonce generated by taker > >=C2=A0 =C2=A0 P =3D p.G =3D nonce point calculated by taker > > > >=C2=A0 =C2=A0 R =3D Q + P =3D pubkey used in bitcoin transaction > >=C2=A0 =C2=A0 =C2=A0 =3D (q + p).G > > If I'm understanding this correctly (which I'm not sure I ame), it seems = like the plan is to put R on-chain as the key to an output? As stated this = is completely=C2=A0insecure as Q is known in advance so the taker can alway= s choose a nonce p but then claim that their nonce point is p.G - Q so that= the key that goes on-chain is (p.G - Q=C2=A0+ Q) =3D p.G allowing them to = steal the funds. My reading from this is that nonce `p` has to be given by the taker to the = maker outright. In original post: > Taker sends unsigned transaction which pays to multisig using pubkey Q, > and also sends nonce p. Thus, taker provides a proof-of-knowledge, i.e. the actual `p` scalar itsel= f (not zero-knowledge, but what the maker needs is proof-of-knowledge, and = could not care less if the proof is zero-knowledge or not). On the other hand, I do not see the point of this tweak if you are going to= use 2p-ECDSA, since my knowledge is that 2p-ECDSA uses the pubkey that is = homomorphic to the product of the private keys. And that pubkey is already tweaked, by the fresh privkey of the maker (and = the maker is buying privacy and wants security of the swap, so is incentivi= zed to generate high-entropy temporary privkeys for the actual swap operati= on). Not using 2p-ECDSA of some kind would remove most of the privacy advantages= of CoinSwap. You cannot hide among `2 2 OP_CHECKMULTISIG` scripts of Lightning, = because: * Lightning channel closes tend to be weeks at least after the funding outp= oint creation, whereas CoinSwap envisions hours or days. * Lightning mutual channel closes have a very high probability of spending = to two P2WPKH addresses. You need to hide among the much larger singlesig anonymity set, which means= using a single signature (created multiparty by both participants), not tw= o signatures (one from each participant). Or is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH16= 0 OP_EQUAL OP_ELSE