From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9227AC0051 for ; Thu, 3 Sep 2020 09:46:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 7EF1920501 for ; Thu, 3 Sep 2020 09:46:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDgrROtuzK3q for ; Thu, 3 Sep 2020 09:46:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by silver.osuosl.org (Postfix) with ESMTPS id 5BBEC20373 for ; Thu, 3 Sep 2020 09:46:05 +0000 (UTC) Date: Thu, 03 Sep 2020 09:45:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1599126362; bh=1M2XM5/p2UK6ENhs76salrku2QJ05Z4Z5p8VyyXMmSk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=mxfhpQJze+DKV9L6VkriFnGDYzArLv6JbKfFiXJ8apn0OepGh1z0auCGiyzoI8aS0 fkQTm0jl5mmdgFts0MTcSMswzq4UnbWR5mMOfJwa9kCaD1MegxktmS0h4GyFoaEY7t LNITiWuvbV9Mr+aps2khD+I5pqeUzGlNHkFnB/XM= To: Chris Belcher From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net> References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> <0ac3fecb-012b-e210-55bb-36809682634a@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: Thu, 03 Sep 2020 09:46:08 -0000 Good morning Chris, > A big downside is that it really ruins the property of allowing coins to > remain unspent indefinitely. That has privacy implications: if a coin > remains unspent for longer than 2 weeks (or another short locktime) then > for sure the transaction was not a CoinSwap, and so the anonymity set of > the CoinSwap system would be far smaller For this reason I'm pretty > desperate to solve the vulnerability without losing the coins remaining > unspent indefinitely feature. Ah, right.... accept no small privacy leaks! > > We need to solve the vulnerability you found, which I'll call the > riskless theft attempt problem. So what do you think of this solution: > > =3D=3D Building block 1: A, B and C having different contract txes =3D=3D > > In the original proposal each CoinSwap peer has the same contract > transaction, and either side can broadcast it whenever they like. This > actually isn't necessary. We can have a contract transaction > fully-signed but only known to one peer, with a possibly-different > transaction transaction fully-signed and only known to the other peer. > > Obviously for the CoinSwap to work both contract transactions must have > the same hash-time-locked contract, but they can differ in other ways. > > =3D=3D Building block 2: collateral payments =3D=3D > > The riskless theft attempt problem happens because the previous owner of > the coins knows the fully-signed contract transaction and can broadcast > it at no cost to themselves. So to solve the problem we add a cost. > > There is a 2of2 multisig made up of Bob's and Charlie's keys. The > associated contract transaction known to Bob must now also have one of > Bob's single-sig inputs. The outputs are such that some of the money > from Bob's input now ends up in the HTLC output. The result is that > after the CoinSwap if Bob broadcasts his contract transaction but fails > to take the money from the HTLC output, then Bob will have lost money. Just to be clear: * B is the one who originally funded the HTLC, and owns the timelock. * C is the one who will accept the HTLC, and owns the hashlock. > I'm calling this idea collateral payments, by analogy with collateral > used for loans. A collateral is someone valuable a debtor puts on the > table, and if they don't repay the loan then they lose the collateral > (presumably the creditor sells it to repay the loan). > > Here is a diagram of the contract transaction known to Bob: > > multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc] > > collateral(B) [J btc] (Bob) [J-K btc] > > > where: > I =3D CoinSwap amount > J =3D Value of Bob's collateral input > K =3D Value that Bob loses if he broadcasts his contract tx but doesnt > get the money > M~ =3D miner fee (random variable) > > The value K is something that can be set by the protocol, and made high > enough so that doing a riskless theft attempt is not worth it. Probably > the value of K will be quite small because the odds of a riskless > payment attempt succeeding is very small (assuming the makers all use > multiple redundant watchtowers). Mostly likely K will be smaller than > M~, so if the collateral is lost to Bob then the miners will the ones to > gain, rather than Charlie. This seems a great solution! Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be = B as well. This means, the taker has to have *some* collateral input, of at least valu= e K, that it cannot swap (because if it tried to swap that amount, it would= be unable to provide a collateral as well). How much does C need to know about the B collateralized contract transactio= n? At the minimum, it has to know the output pays out to the correct contract,= so it seems to me it has to know the entire B collateralized contract tran= saction, meaning it learns another input of B ("collateral(B)") that is not= otherwise involved in the CoinSwap. This is important, again, if B is a taker, as it means an unrelated input o= f B is now learned by C as having the same ownership as B. A fresh maker that is given its starting funds in a single UTXO needs to sp= lit up its funds to make at least one collateral input it can use. Of note is that the B output also serves as a point for CPFPing this transa= ction, thus only one version of the B collateralized contract transaction n= eeds to be made, and the B collateralized contract transaction can be at or= close to the minimum relay feerate and later CPFPed. In terms of onchain analysis heuristics, it looks like the B output is chan= ge, while the B+C contract output is the send-out, I think, for most cases. In case of a protocol abort, this heuristic is misled, since both outputs b= ecome owned by B due to the protocol abort. In case of a protocol completion, this heuristic is accurate, since the B+C= contract output will be claimed by C, but we do not expect this transactio= n to be confirmed onchain after protocol completion anyway (it effectively = donates K to C or miners), so this is fine. > The other contract transaction, known only to Charlie, does not contain > a collateral input or collateral value (K), because Charlie can't do a > riskless theft attempt to Bob. Because it has a single output only, the C contract transaction needs to ha= ve RBFed versions. > If Bob ever spends his collateral input in another transaction, then his > contract transaction will become invalid. However Bob will only be > harming himself, so he'll never do this. At least until B gets its own incoming funds in the swap, at which point th= e collateral input can be used for other purposes (and effectively "release= s" the lease of B on that output). Since C knows the collateral input (it has to, in order to verify the B col= lateralized contract transaction is correct), it can monitor the collateral= input for spendedness, and stop watching for the B collateralized contract= transaction in its watchtower(s) if the collateral input is deeply spent. The B collateralized contract transaction is invalidated if the collateral = input is spent, and then only C can spend the funding outpoint at that poin= t, so it can remove that from the watchtower. This can be significant if C is using a for-pay watchtower that supports de= letion of watches, which I believe is planned for watchtowers as well, and = reduces the operating cost of C. Regards, ZmnSCPxj