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 CA59FC016F for ; Tue, 12 May 2020 15:06:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id C6E3E89356 for ; Tue, 12 May 2020 15:06:15 +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 l8JIRsWayU0T for ; Tue, 12 May 2020 15:06:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by hemlock.osuosl.org (Postfix) with ESMTPS id 6EDC78939D for ; Tue, 12 May 2020 15:06:07 +0000 (UTC) Date: Tue, 12 May 2020 15:05:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589295964; bh=GHwGTYszeL7FMfnJ7Pq9sdBS0pgR0e10pu9KEAAVVaE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=kPlgurt1xdYHkoHhzlHyasyQe8LIOE2WfEz9H6RrzBSTvqFTWF6A7+u6owBE148Ps 4hwT5UKWWClvFdzO1FO0ePuCy4acjvEcQ70N43+FDV13E1CFEI+Khrf3ExUNYTuz8u C3qBL5+DiUpJXpk9dhnGxMMw/HTTD+Sc+tTaWNPE= To: Ruben Somsen 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] SAS: Succinct 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: Tue, 12 May 2020 15:06:15 -0000 Good morning Ruben, > >Would this not work? > > I considered and rejected that model for the following reason: there are = moments where both Alice and Bob can claim the BTC. If they both attempt to= do so, it also reveals both secrets, causing the LTC to also be claimable = by both parties. This chaotic scenario is a failure mode that did not seem = acceptable to me. The revoke transaction was specifically added to mitigate= that issue (invalidating any attempt of Bob to claim the coins and reveal = his secret). That said, it doesn't particularly seem in either party's inte= rest wait until a moment where two timelocks become valid, so maybe it is n= ot quite as bad as I thought. However, it still means that the incompetence= /malevolence of one party can lead to losses for both parties. I have my do= ubts a gain in privacy in the uncooperative case is worth that risk. > > Of course it also reverts the protocol to 3 transactions, instead of 2, b= ut regardless, not having to watch the chain is probably more practical in = many cases. As an aside, if both chains support timelocks then we can ensur= e that the more expensive chain only receives one transaction. If the shortened refund transaction exists (labeled "refund transaction #1"= in the SVG) then the same issue still occurs: after 1 day it is possible f= or either success or refund#1 to be broadcasted, leading to revelation of b= oth secrets, leading to the same failure mode you described. Without the refund#1 in your proposal, Bob refusing cooperation after Alice= puts the BTC into lock for 3 days and 2 further onchain transactions (with= the refund#2 transaction being relative-locked, meaning it cannot be used = to CPFP the revoke transaction; my formulation allows any of the result tra= nsactions to be CPFP directly by their beneficiaries). It seems to me that there is still an onlineness requirement in case Bob do= es not complete the protocol: once the revoke tx becomes valid an online Bo= b can cheat an offline Alice by broadcasting the revoke tx (which, if my un= derstanding of the protocol is correct, the signatures are shared to both A= lice and Bob). So Alice needs to be online starting at 2 days to 3 days in order to ensure= it reclaims it funds. I have not seen the 2-tx variant video yet, as I prefer to read than listen= , but I will also check it if I can find an opportunity. Regardless, the overall protocol of using 3 clauses in the swap, and reusin= g the privkey as the payment secret demanded by the pointlocks, is still a = significant innovation. In the context of CoinSwap, a proposal is that a CoinSwap server would prov= ide swapping service to incoming clients. Using my counterproposal, the Bob position can be taken by the server and t= he Alice position taken by the client. In this context, the L1 can be made reasonably close in the future and L2 f= ar in the future, in which case Alice the client can be "weakly offline" mo= st of the time until L2, and even in a protocol abort would be able to reco= ver its funds. If the protocol completes, the server Bob can claim its funds before L1, an= d (with knowledge of Alice[0]) can immediately put it in a new funding tx f= or a new incoming client before L1, which is a fine tradeoff for server Bob= since presumably Bob is always online. Regards, ZmnSCPxj