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 C6FF3C016F for ; Thu, 14 May 2020 04:49:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id AC3D387CD4 for ; Thu, 14 May 2020 04:49:34 +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 N-iq2bhYHFiQ for ; Thu, 14 May 2020 04:49:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) by whitealder.osuosl.org (Postfix) with ESMTPS id B420187C49 for ; Thu, 14 May 2020 04:49:31 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 132EF260020D; Thu, 14 May 2020 04:49:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1589431770; bh=TpmRgeeg0WQc55Xg9LuvWXVcdiUtmJFv4tXOYuE5lxs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Tp+VQ6JsxPfCd6BS392fwcceWOOKR0Xk+QD6NgvW2TUrV75bzO+Hma+BsUBxj1rD/ d2jyz8fysc2V3HEDCNmFQ0a6ERsmd51AZyLpa3ZDaiEhJgWED6cLM7Q/PCkI+mLfPd H3HJ9gbC8BLenMjTl21gdL4zrf8aSaeu3C/0yVVk= Date: Thu, 14 May 2020 09:52:15 +0500 From: Dmitry Petukhov To: Ruben Somsen Message-ID: <20200514095215.4ea20666@simplexum.com> In-Reply-To: References: <20200513220222.24953c0a@simplexum.com> Organization: simplexum.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 14 May 2020 04:59:36 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap 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, 14 May 2020 04:49:34 -0000 =D0=92 Wed, 13 May 2020 21:03:17 +0200 Ruben Somsen wrote: > Or perhaps you're referring to the issue ZmnSCPxj pointed out after > that, where refund transaction #1 and the success transaction could > both become valid at the same time. It would make sense for the test > to pick up on that, but I believe that is ultimately also not an > issue (see my last reply in the thread). This one. The issue as I see it: Bob can not broadcast success_tx and wait until Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly miner to have a chance to invalidate success_tx. Bob already learned secretAlice, so he grabs his LTC back. If the Bob-friendly miner has luck, success_tx is confirmed while refund_tx_1 is invalidated, and Bob now have both LTC and BTC, while Alice is out of her BTC. > >I did not understand what the destination of Alice&Bob cooperative > >spend =20 > of refund_tx#1 will be >=20 > This transaction can be spent by Alice & Bob right away or by Alice a > day later (in relative time, so the tx has to confirm first). The > Alice & Bob condition is there purely to ensure that Bob can spend > the money before Alice once he receives her key at the end of the > protocol. Ah, so this is possible because of the step 5 in the diagram: ``Alice gives Bob her key ("Alice")'' -- As I understand, this is a way to deny Alice to use refund_tx_1. Then if Alice gives her _key_ to Bob before Bob has to share secretBob via success_tx, could Bob just spend the Alice&Bob output of the very first, "commitment" transaction that locks BTC ? Bob will receive BTC, and the LTC can be locked forever, but Bob doesn't care, he got his BTC.