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 440AEC0051 for ; Sun, 30 Aug 2020 13:38:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id C8BFC20480 for ; Sun, 30 Aug 2020 13:38:28 +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 0Ed9tPlW5XsG for ; Sun, 30 Aug 2020 13:38:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by silver.osuosl.org (Postfix) with ESMTPS id D89BA1FC94 for ; Sun, 30 Aug 2020 13:38:25 +0000 (UTC) Date: Sun, 30 Aug 2020 13:38:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1598794701; bh=z6ZuQBVtE9FEBuDylNrVmx4/DjNSIVcDcphvvAHY+Uw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=oWO1sI45ZNMZFqgU1140hPF7FKn8Dv+D0VY5struS5GSBW6XUUB/UgDwdRHytFHlU 7oyRHNijGGm1gP42Gf6WOB1YFqXoUQGnBLabMl2CRNUre3pdv/2rmgdcw01weC00DY UHdVw3+QX5p2FqxUUGEG9b39Kbo9TBEwGC5x9cn0= To: Chris Belcher , 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: Sun, 30 Aug 2020 13:38:29 -0000 Good morning Chris, > It seems having just one contract transaction which includes anchor > outputs in the style already used by Lightning is one way to fix both > these vulnerabilities. > > For the first attack, the other side cannot burn the entire balance > because they only have access to the small amount of satoshi of the > anchor output, and to add miner fees they must add their own inputs. So > they'd burn their own coins to miner fees, not the coins in the contract. Minimum output size is 547 sats, so anchor outputs are that amount at minim= um. A P2SH-P2WPKH output costs something like ~130 vbytes to spend, at 1.000 sa= t/vbyte that is only ~130 sats to spend a 547 sat anchor output, an opportu= nistic camper could collect from a few swaps it would have done anyway (e.g= . as a passive popular maker?) and broadcast the contract txes of those swa= ps and then spend the anchor outputs together to get a few sats in a not-so= -dusty UTXO, getting (547 - 130) sat per input minus the cost of creating a= new tiny output. Assuming the camper has already claimed its side of the swap in order to pu= t it in cold, this is basically a tiny but free amount of extra money, and = if small CoinJoins in JoinMarket are any indication, the 547 sats minus fee= to spend it minus fee to create (amortized among the multiple contract txe= s) new UTXO might be comparable to the actual maker fee. Since this camping attack is done after the CoinSwap, the maker fidelity bo= nd is a weak protection against this. The maker can keep around contract transactions indefinitely, and if standa= rd wallets assume they can leave the coins in the same UTXO indefinitely, t= he contract transactions remain valid indefinitely, including up to fidelit= y bond timeout. When the fidelity bond times out, the maker has to destroy its identity any= way, so it could opportunistically wait for a low-fee period after fidelity= -bond timeout (we currently get low fee periods once a week, for example, s= o the camper can wait for at most a week to do this) to publish all still-v= alid contract transactions, and spend all the anchor outputs including the = fidelity bond at the minimum feerate, getting a slightly larger fidelity bo= nd fund, then CoinSwap it to honest makers to clean it, then make a new fid= elity bond. And if one of the takers happens to not be watching for contract tx timeout= , it can potentially get free money, again, from the inattention. (I call it a "camper attack" since the attacking CoinSwap participant waits= around in a single place (maker fidelity bond) and snipes passing contract= transactions to extract value from them when opportunity (low fee rate) is= good, like a camper.) To protect against this, we should force contract txes to signal RBF, make = contract txes min-relay=3Dfeerate (requires CPFP package relay at base laye= r tho), and during low-fee periods we should collect outputs whose private = key have been turned over to us, paying at a feerate slightly higher than 5= 47 sat / 130 vbyte fee rate (at which point it becomes uneconomical for cam= pers to mount their sniping attack as they would lose the anchor output amo= unt to fees anyway). In fact the wallet can do that all the time, and if prevailing fees are abo= ve the 547 / 130 rate it will not confirm and the wallet that wants to spen= d its funds *now* can sign a new RBF tx at higher feerate to replace it. Low fees, who would have thought that would enable an attack vector.... Regards, ZmnSCPxj