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 00139C016F for ; Wed, 13 May 2020 08:39:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id E1B58883F1 for ; Wed, 13 May 2020 08:39:51 +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 qV338Diz0DF6 for ; Wed, 13 May 2020 08:39:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by hemlock.osuosl.org (Postfix) with ESMTPS id BB376883E1 for ; Wed, 13 May 2020 08:39:49 +0000 (UTC) Date: Wed, 13 May 2020 08:39:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589359187; bh=ULkTGKLmMqTiK22L082oqKDtkt+iwNynZaR4qBzD13E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=oFruVwSj3J2BuRhops1Kp60eNMB8XqT9j54w3yorKULO1wSS0msRutAyvFm2kDRoN ywbSrZ/vuhkZbp15/+iERqUYnMcuO+8iPm9ZQ+FfOMro21vXm3bNfEnph6fPKuQp7R UktzmL/2IC8hFdZ0ysj7W48RsnI1F2VkHVpY19o8= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com> 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: Wed, 13 May 2020 08:39:52 -0000 Good morning Ruben, > >If the shortened refund transaction exists (labeled "refund transaction = #1" in the SVG) then the same issue still occurs=C2=A0 > > Yes, but there is one crucial difference: at that point in the protocol (= Bob has the success transaction and then stops cooperating) Alice and Bob b= oth had the opportunity not to take that path. Bob could have sent the succ= ess transaction, and Alice could have waited and sent the revoke transactio= n. They would essentially be "colluding" to fail. Okay, so the concern is basically, that Bob misses the deadline, then Alice= feels obligated to reclaim the funds. In your proposal, the tx competition is between the secret-revealing succes= s TX and the non-secret-revealing revoke tx. Whereas in my counterproposal, under the same conditions, the tx competitio= n is between the secret-revealing success tx and the secret-revealing backo= ut tx, and both transactions becoming visible on P2P network means potentia= lly both Alice and Bob know all the secrets on the LTC side and end up comp= eting over it, RBFing each other until the entire fund goes to miners. > >Without the refund#1 in your proposal, Bob refusing cooperation after Al= ice puts the BTC into lock for 3 days and 2 further onchain transactions > > I'm not sure if I correctly understood what you're saying, but it's as fo= llows: > > Refund #1 can only safely be used before the signed success tx is given t= o Bob. The cost to Alice at this point if Bob aborts is two on-chain transa= ctions while Bob hasn't put anything on-chain yet. > > Refund #2 needs to be used after Bob receives the signed success tx. The = cost to Alice is now three transactions, but Bob also went-on-chain by this= point, so causing this wasn't costless to Bob and is thus a similar failur= e mode. I think it is not accurate that Bob is already on-chain before Alice can be= forced to use 3 transactions to fail. The revoke tx signatures are shared at step 0 of your protocol description. Thus Bob has a copy of the revoke tx that is valid once Alice signs and con= firms the funding transaction. Bob can thus give a copy of the revoke tx with signature directly to its fa= vorite miner, forcing Alice to take 3 transactions to back out of the swap. Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There ain= 't no such thing as a global mempool"), Alice will only know about this eve= nt when the revoke tx is confirmed once, at which point it is very difficul= t to reverse, even if Alice has a refund#1 tx prepared. Bob can do this before step 2 in your protocol description, meaning before = Bob locks up any funds, so Bob can do this for free, and will even use fund= s going back to Alice to pay for confirmation of the revoke tx. Because Bob can do this for free, there is no disincentive for trolling Bob= s to exist whose sole life goal is to just grief possible Alices. This can be slightly mitigated by adding two CPFP outputs (one for each par= ticipant) and using the minimum relayable feerate for the revoke tx so that= Bob is forced to bring its own fees in order to incentivize miners. This is similar to the "bring your own fees" currently proposed for Lightni= ng, but note the recent hand-wringing about the various problems this adds = to mempools and CPFP and RBF rules and etc etc: https://lists.linuxfoundati= on.org/pipermail/bitcoin-dev/2020-April/017757.html We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a bring-yo= ur-own-fees, but that is not `SIGHASH_ALL` and thus marks the transaction g= raph as special. And forcing bring-your-own-fees means neither Alice nor Bob can swap all th= eir funds in a single operation, they have to keep a reserve. Bob cannot safely perform step 2 before getting both signatures for the rev= oke tx, as without Bob having access to the rveoke tx, if Bob locks up LTC,= Alice can stop responding and lock both their funds indefinitely with Bob = not having any way to recover its funds, which a rich Alice can use to comp= letely lock out an impoverished Bob. But if Bob is given both signatures for the revoke tx before step 2, then B= ob can send the revoke tx to its favorite miner, forcing Alice to take 3 tr= ansactions to back out, before Bob locks any funds in LTC side. > > I also agree with your observation that alternatively Bob can just spend = before the timelock expires. This seems to be the safest alternative; in my context, where Bob is a Coin= Swap server/maker, Bob can wait a short while for new clients/takers, and i= f no new clients arrive, spend. Bob can run multiple servers, each of which are given the completed success= transaction, and the servers can check that if the timeout is near, to spa= m the Bitcoin P2P network with the completed success transactions. (these servers need not even run fullnodes, they could just periodically po= ll a number of blockchain explorers and electrum servers, and when the bloc= kheight approaches, attempt broadcast; if the "main" server that accepts cl= ients/takers has already spent the TXO the broadcast of the completed succe= ss tx is simply rejected by the Bitcoin P2P network; if the timeout is base= d on sidereal time then the backup servers only need to be running NTP) Regards, ZmnSCPxj