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 19585C0051 for ; Sat, 5 Sep 2020 02:29:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id F086B8753D for ; Sat, 5 Sep 2020 02:29:35 +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 JWiWUPZoCjGQ for ; Sat, 5 Sep 2020 02:29:34 +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 hemlock.osuosl.org (Postfix) with ESMTPS id 0FBDA87522 for ; Sat, 5 Sep 2020 02:29:33 +0000 (UTC) Date: Sat, 05 Sep 2020 02:29:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1599272970; bh=aIqAzTB+A9fVLCj1Suyr0D184rPn1GqBtWoJVUCt07M=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=stGbyQ6jP+azmRbUZkgzzTrxdlefKBIAQCIkvtKdgF/gyOqw0V2pSH2eZmgJiMF2t b+gc/jh0wlda5WoIBvcA8jGmdU+DzcX4dTsfBwQVkiJULqIfeD/YOIDYq66wqEaNwW gst4F+idjwLmf/g9oYrhWHDi38/vpx6tetx2yhE0= To: Antoine Riard 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: Sat, 05 Sep 2020 02:29:36 -0000 Good morning Antoine, > > This can be arranged by having one side offer partial signatures for th= e transaction of the other, and once completing the signature, not sharing = it with the other until we are ready to actually broadcast the transaction = of our own volition. > > There is no transaction that both participants hold in completely-signe= d form > > I don't think that's different from the current model where you have eith= er a valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never = full witness material to build both ? It is different in that the current (actually, now *previous*) model looks = like this: funding out -> contract tx --> HTLC-timeout OR HTLC-success Whereas what I am describing looks like this: funding out -> HTLC-timeout OR HTLC-success The attack being described has to do with the fact that, after private key = turnover (i.e. after hash-lock resolution), the contract tx can be used to = at least annoy the supposed new owner of the funding out, since the contrac= t tx deducts fees from its input to pay for itself. And at the end of the swap (after private key turnover) the one who funded = the funding outpoint (and swapped its control for this outpoint already, fo= r a different outpoint) can at least try to broadcast the contract tx for a= *chance* that the HTLC-timeout becomes valid and it can steal the coin eve= n after taking the swapped coin on the other side of the swap. Chris recently described a different technique, which has different contrac= t txes, with the contract tx held by the offerrer of the HTLC (who can othe= rwise later annoy the acceptor of the HTLC once the HTLC has been hash-reso= lved) costing the offerrer of the HTLC some coins if it is published after = swap completion. > > To reduce this risk, A can instead first swap A->B->A, then when that c= ompletes, A->C->A. > This limits its funding lockup to 1 week. > > Okay I think I understand your point. So by intermediating the chain with= the taker you ensure that in case of previous hop failure, taker funds are= only timelocked for the delta of this faulting hop not the whole route. Bu= t still not anchoring onchain the next route segment means that any moment = the next maker can exit from the proposed position ? > > That's interesting, so a) you require all takers to lock their funds onch= ain before initiating the whole routing and you will pay more in service fe= es or b) you only lock them step by step but you increase risk of next hop = default and thus latency. Roughly. > =C2=A0 > It might be an interesting construction to explore on its own, minus the = downside of producing weird spend patterns due to next hop maker bidding wi= th another party. > Correct, a taker can pay higher fees for lots of smaller swaps that reduce = its lockup risk, or pay less (with similar privacy bought) but with greater= total lockup risk. Regards, ZmnSCPxj