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 C81A4C0051 for ; Tue, 25 Aug 2020 03:16:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id AE0E48709D for ; Tue, 25 Aug 2020 03:16:13 +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 iKfRLBgVvuZD for ; Tue, 25 Aug 2020 03:16:11 +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 8612D86DA3 for ; Tue, 25 Aug 2020 03:16:11 +0000 (UTC) Date: Tue, 25 Aug 2020 03:16:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1598325368; bh=WGN0b7jE7jVsfEP1DRAsI2xoXKRvGJujl/AQYbCiQg0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=BD44gK940zHERDTJTQkAYrjhh+Bp7tMsGn8aBF0p4bYWWj4SPKVZzwgmRPU/VAvkJ +8bGA/xX55TV21baPVHawCR4vi6HIZ3LfSF0RmQw0PJE1YaD/rlp+zwpfHLKavgMGT O42p8Uw8mssR2BO7+kmyooFhQ9DevHbJaugc+hfo= To: Antoine Riard , Bitcoin Protocol Discussion 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 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: Tue, 25 Aug 2020 03:16:13 -0000 Good morning Antoine, > Note, I think this is independent of picking up either relative or absolu= te timelocks as what matters is the block delta between two links. I believe it is quite dependent on relative locktimes. Relative locktimes *require* a contract transaction to kick off the relativ= e locktime period. On the other hand, with Scriptless Script (which we know how to do with 2p-= ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a cont= ract transaction. With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one = participant holds a completely-signed timelock transaction while the other = participant holds a completely-signed pointlock transaction. This can be arranged by having one side offer partial signatures for the tr= ansaction of the other, and once completing the signature, not sharing it w= ith the other until we are ready to actually broadcast the transaction of o= ur own volition. There is no transaction that both participants hold in completely-signed fo= rm. This should remove most of the shenanigans possible, and makes the 30xRBF s= afe for any range of fees. I think. Since for each PTLC a participant holds only its "own" transaction, it is p= ossible for a participant to define its range of fees for the RBF versions = of the transaction it owns, without negotiation with the other participant. Since the fee involved is deducted from its own transaction, each participa= nt can define this range of RBFed fees and impose it on the partial signatu= res it gets from the other participant. -- Private key turnover is still useful even in an absolute-timelock world. If we need to bump up the block delta between links, it might be impractica= l to have the total delta of a multi-hop swap be too long at the taker. As a concrete example, suppose A is a taker who wants to route over makers = B and C. However, B and C require a CLTV delta of 1 week. If A wants to route "directly" A->B->C->A, then if something bad happens, i= t could be looking at having its funds locked for two weeks. To reduce this risk, A can instead first swap A->B->A, then when that compl= etes, A->C->A. This limits its funding lockup to 1 week. Private key turnover is useful since as soon as the A->B->A swap completes,= it can directly fund the A->C->A swap from the B-side funding transaction = of the A->B->A swap. | A->B->A | A->C->A | : : : A -:->funding A&B--> B : : : : : B -:->funding A&B -----:--> funding A&C --> C : : : : : :C-> funding A&C ------:-> to-cold A --> : : : This increases the number of transactions by 1 per swap beyond the first, c= ompared to a direct routing A->B->C->A, but this may be worth it for A if t= he timelocks involved are too big for A. With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is= unable to reliably determine if it is the last hop in the route. Without private key turnover, A would have: **NO** private key turnover! | A->B->A | A->C->A | : : : A -:->funding A&B--> B : : : : : B -:->funding A&B -----:--> claim A -> funding A&C --> C : : : : : : C-> funding A&C ------:-> to-cold = A --> : : : So if timelock-deltas are possibly-high (to reduce the probability of the M= AD-HTLC argument, and other attacks, succeeding), takers might prefer to ro= ute by completing one swap first before starting the next one, and private = key turnover is useful by reducing blockspace required by each hop. For reference, this is how it looks like with a single A->B->C->A swap with= private key turnover: | A->B->C->A | : : A -:->funding A&B--> B : : : B -:->funding B&C -> C : : : C -:->funding A&C -----:-> to-cold A --> : : This is still smaller than in the A->B->A, A->C->A with private key turnove= r, by one funding tx per hop. However, A risks a much higher timelock (twice the timelock). Thus, A might prefer a lower timelock in exchange for paying for an additio= nal transaction. Regards, ZmnSCPxj