From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 97F51C016E for ; Sat, 6 Jun 2020 03:59:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 7DE1189275 for ; Sat, 6 Jun 2020 03:59:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O84ipbvypfv for ; Sat, 6 Jun 2020 03:59:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by hemlock.osuosl.org (Postfix) with ESMTPS id F097689272 for ; Sat, 6 Jun 2020 03:59:36 +0000 (UTC) Date: Sat, 06 Jun 2020 03:59:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591415973; bh=WOv4rA7+ipRx298absH2x2+q/UTqWqse42Qri+j+yPA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=LepfbpoiZnKBZlwredi98KJhVSGMPEVWXcRikKy7DKpMoYx2omGiizYidxf4eevMq OmFaporUZavMRzrTLOtQeWnTOsfZirHKTejOSo03in+d9/5fI4iLHyJFqvRaXlyLkd rTh5XulveJOLfprkCQiI82HxYHb9rckNC8RUzZbE= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility 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: Sat, 06 Jun 2020 03:59:38 -0000 Good morning again Chris, I am uncertain if you are aware, but some years ago somebody claimed that 2= p-ECDSA could use Scriptless Script as well over on lightning-dev. * https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/201= 80426/fe978423/attachment-0001.pdf * https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/0012= 21.html I cannot claim to follow the math enough to say it is actually secure, but = the idea does exist. If this is sufficiently secure, we can fold the Spilman backout into the sc= riptless script swap as well. * Alice creates secret keypairs A[0] =3D a[0] * G, A[1] =3D a[1] * G * Bob creates secret keypairs B[0] =3D b[0] * G, B[1] =3D b[1] * G * Alice creates (but does not sign) funding from Alice -> A[0] && B[0] * Bob provides partial signature for A[0] && B[0] -(nLockTime=3Dlocktime1)-= > Alice to Alice and Alice completes this signature and stashes it. * Bob creates (but does not sign) funding from Bob -> A[1] && B[1] * Alice provides partial signature for A[1] && B[1] -(nLockTime=3DlockTime2= )-> Bob to Bob and Bob completes this signature and stashes it. * Alice and Bob sign and broadcast their funding transactions. * This can safely be done in any order; Bob will refuse to continue with = the protocol until it sees Alice funding is confirmed, and will abort if lo= cktime2 is too near. * Alice waits for Bob funding tx to confirm. * Alice provides a 2p-ECDSA adaptor signature for A[1] && B[1] --> Alice; t= he adaptor signature, when completed, reveals the secret a[0] to Bob. * Bob waits for Alice funding tx to confirm. * Bob provides the partial signature for the given adaptor signature for A[= 1] && B[1] --> Alice and Alice completes this signature and stashes it. * Alice gives a[0] outright to Bob. * Bob gives b[1] outright to Alice. * Alice spends the A[1] && B[1] output before locktime2. * Bob spends the A[0] && B[0] output before locktime1. I also pointed out the griefing problem in Lightning also applies to SwapMa= rket. Bob can limit the griefing problem by requiring that locktime2 <=3D now + 1= 2, and requiring that locktime1 >=3D now + 60. This means that Alice has to lock its funds for 10 hours if it forces Bob t= o lock its funds for 2 hours, making it undesirable as an attack on competi= ng makers. This does prevent chaining (no maker is going to accept the outgoing), but = if Alice wants chaining it can always use the private key handed over to im= mediately start a funding tx with another Bob. (This is not a good solution for griefing in the Lightning Network since ch= annels are intended to be reused there, whereas the Spilman channels in Coi= nSwap exist only to allow funding transactions to confirm in any order onch= ain, and are used only for the specific swap; in Lightning the forwarding n= ode has an incentive to release the incoming HTLC immediately instead of im= posing the incoming wait time since the funding can be reused for a differe= nt payment, but in CoinSwap it cannot be reused anyway, so it could just le= t the incoming timelock lapse instead of releasing that encumbrance as woul= d be done in Lightning.) Regards, ZmnSCPxj