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 1B350C0178 for ; Thu, 14 May 2020 07:05:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0C36E873F0 for ; Thu, 14 May 2020 07:05:24 +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 9lCJQnpeaWXX for ; Thu, 14 May 2020 07:05:23 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id CBEAC86103 for ; Thu, 14 May 2020 07:05:22 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 4183A260020D; Thu, 14 May 2020 07:05:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1589439920; bh=tn5qLSagLPoZWoxS1RlKZzgT4LiDdcnPZyMvM7RPgNk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ep+Utk8tfM2KAEFMnvxKVyP735mtt+XDwLDqDBIVj0x1Yg0aNcRXlGSMJuOlM6OC0 ewSb6z3mS90cv6Cx+JnCvK2XTU2GNEhRBXNbtKSWiZ0y8ffekcVokfMzxN3H+dU965 y0WflKRR09VOAQIi2Nzl2hMvhqMOY4pQ4IF1ajxk= Date: Thu, 14 May 2020 12:08:05 +0500 From: Dmitry Petukhov To: Ruben Somsen Message-ID: <20200514120805.521fbaa2@simplexum.com> In-Reply-To: References: <20200513220222.24953c0a@simplexum.com> <20200514095215.4ea20666@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 11:42:45 +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 07:05:24 -0000 =D0=92 Thu, 14 May 2020 07:31:13 +0200 Ruben Somsen wrote: > Hi Dmitry, >=20 > >While refund_tx_1 is in the mempool, Bob gives success_tx to the > >friendly miner >=20 > I see, so you're talking about prior to protocol completion, right > after Alice sends Bob the success_tx. The reason this is not an issue > is because Alice and Bob both had to misbehave in order for this to > happen. Bob is misbehaving here because he should have published the > success_tx before refund_tx_1 became valid, and Alice is misbehaving > here because she should have sent the revoke_tx (which invalidates > the success_tx) followed by refund_tx_2 (revealing her secret only > AFTER Bob can no longer claim the BTC). In other words: yes, the > protocol can fail if Alice and Bob together work towards that goal. A > feature, not a bug. This won't happen if either of them doesn't want > it to. I imagine this is difficult to model. Right. But it should be noted that it is not enough that Bob publishes success_tx before refund_tx_1 became valid. The success_tx needs to be confirmed before refund_tx_1 became valid. Only Bob can spend success_tx so this is unlikely to be the practical problem, unless the original fee of success_tx is too small and Bob epically screws up CPFP-ing it. > >Bob will receive BTC, and the LTC can be locked forever, but Bob > >doesn't =20 > care, he got his BTC. >=20 > No, because diagram step 5 comes before step 6 -- Alice won't give > her key until she learns secretBob. I somehow missed it, and steps 5 and 6 in the diagram was not modelled at all (on the other hand, it made the model simpler and I had something working relatively quick). I now made the `signers_map` into variable that can be changed to give Bob the ability to sign for Alice. With that change, step 6 can be modelled, but this will add a bunch of new txs to the model (each Alice&Bob spend will have 'Bob unilateral override' case)