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 81D79C0051 for ; Sat, 22 Aug 2020 01:09:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 47A66203BB for ; Sat, 22 Aug 2020 01:09:45 +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 cBZLWXbpqCg4 for ; Sat, 22 Aug 2020 01:09:42 +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 silver.osuosl.org (Postfix) with ESMTPS id 660FB203B5 for ; Sat, 22 Aug 2020 01:09:42 +0000 (UTC) Date: Sat, 22 Aug 2020 01:09:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1598058579; bh=qnz/xD9HNlbKhwS7oynUacowVNi6+j91m6tBDc9kF4s=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=WIK3HA+AluWJEUdcUvK63S2tnvYvKBtsbKlvzPYfga+EF2Ehj7pO21rfLVNIR+Ozl bCHeo0v2Vk1jSnL9J/RgxoJYNdDHnc8jUAXLT1bjncfb5EeN4HfRFdpVs6dc9PCKb+ VF5hg4SdubG4Cjv9KV4zdKfCHdc2Bs3sK2NtNkbs= To: Chris Belcher 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, 22 Aug 2020 01:09:45 -0000 Good morning Chris, > > Absolute timelocks mean that you can set a timer where you put your nod= e to sleep without risk of loss of funds (basically, once the absolute time= locks have resolved, you can forget about CoinSwaps). > > But I think the ability to spend at any time would be better, and getti= ng 100% online 144 blocks a day, 2016 blocks a retargeting period is becomi= ng more and more feasible. > > You can always put your node to sleep as a maker, and your watchtowers > will protect you. Assuming you have multiple watchtowers, yes. It would be best if watchtowers for CoinSwap and watchtowers for Lightning = could be the same thing, and ideally, a watchtower would not even know if w= hat it was watching were a Lightning channel or a CoinSwap until an attack = happens. > > What do you mean by the point about 100% online nodes getting more > feasible? Many bitcoin nodes have been always-on for years, I think I > missed something. Not all locations on Earth make it easy to be 100% online. However, as the technology of you puny humans advance, it becomes more and = more possible for a random point on Earth to be 100% online. > > > You're right that attempting such an move by the taker is riskless, b= ut > > > its not costless. The taker sets up the entire CoinSwap protocol beca= use > > > they wanted more privacy; but if the taker broadcasts the Alice contr= act > > > transaction and waits for the timeout, then all they've achieved is > > > spent miner fees, got their own coin back and draw attention to it wi= th > > > the unusual HTLC script. They've achieved no benefit from what I see,= so > > > they won't do this. Any taker or maker who attempts anything like thi= s > > > will be spending miner fees. > > > > They would be spending miner fees from the funds being stolen, thus sti= ll costless. > > In particular, let us imagine a simple 1-maker swap. > > > > - The taker and the maker complete the swap. > > - The taker now has possession of: > > - The private key for its incoming HTLC. > > - The pre-signed contract transaction for its outgoing HTLC. > > - The taker spends from its incoming HTLC using the private key. > > - The maker ignores this, because this is just normal operation. > > - Fees paid for this is not an additional cost, because a taker t= hat wants to put its freshly-private funds into cold storage will do this a= nyway. > > - The taker gets a fresh, private coin from this incoming HTLC, s= o it gets the privacy it paid for. > > - The taker waits for the incoming-HTLC-spend to confirm. > > - The taker broadcasts the pre-signed contract transaction, in the ho= pe that the maker is offline. > > - The fees paid for this are from the contract transaction that t= he taker is trying to steal. > > Even if the theft attempt fails, the taker has already gotten i= ts private money out, and is thus not risking anything. > > > > - Semantically, the outgoing HTLC is already "owned" by the maker= (the maker has private key to it). > > - Thus, the taker commits an action that the maker pays fees = for! > > - The maker cannot react except to spend via the hashlock branch. > > In particular, because the taker-incoming (maker-outgoing) UTXO= is already spent, it cannot retaliate by also broadcasting the contract tr= ansaction of the taker-incoming (maker-outgoing) HTLC. > > > > - The theft succeeds (the timelock passes) because the maker happens = to be offline for that long. > > - This is "free money" to the taker, who has already gotten what = it paid for --- private money in cold storage --- from the CoinSwap. > > - Even if the stolen fund reveals the contract, the taker can re-= acquire privacy for the funds it stole for free, by paying for --- wait for= it --- another CoinSwap for its swag. > > Yep you're right, I get it. > > The biggest defense against theft will have to be multiple redundant > watchtowers. But as you say the attack is riskless and costless for the > taker to attempt, so they might try anyway even if the probability of > success is very low. > > If this attack becomes widespread then it effectively breaks the > property that maker's coins remain unspent indefinitely. It seems like > that would lead to makers increasing their CoinSwap fees because they > know they'll always have to spend a bit of miner fees afterwards. > > Hopefully the success rate for this attack can be low enough that > taker's human niceness will stop them trying. But for sure this is a > concerning problem. Indeed. We also cannot use succinct atomic swaps because their asymmetry makes them= unroutable --- you can only use it for single-maker swaps. This makes it obvious to the maker that you have only a single maker. > > Using an absolute timelock (implemented by a `nLockTime` tx directly of= f the 2-of-2, not `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 2p-EC= DSA (again implemented by a tx directly off the 2-of-2) instead of a hashlo= ck, seems to avoid this, I think, at the cost of reducing the utility of pr= ivate key turnover by having a deadline where the private key has to be use= d. > > This is because there is no contract transaction that is share-owned by= both participants in the swap. > > Instead there are two distinct transactions with separate ownerships: a= timeout tx (that is owned by the participant paying for the HTLC/PTLC) and= a claim tx (that is owned by the participant accepting the HTLC/PTLC). > > A downside of using absolute timelocks is that it combines the two time > periods: the time period where a watchtower must respond and the time > period under which private keys must be used. > > So for example if the absolute timelock is set to 3 weeks, that means > the maker has 3 weeks to spend their coins using the private keys which > is a nice long period. However if the CoinSwaps fails with the timeout > case then the maker has to wait 3 weeks to get their coins back, which > is a long time. > > We can go the other extreme and set the absolute timelock to be 2 days. > Then the maker only has to wait 2 days in the unfortunate event that > their coinswap fails with the timeout case. But it means they must use > their private keys to spend coins within the short period of 2 days(!) > > Though this still might be worth it to solve the riskless/costless > stealing attempts. Yes. Note that this only works if you dive into Scriptless Script 2p-ECDSA/Schno= rr immediately. It also makes watchtowers for Lightning inherently incompatible with watcht= owers for CoinSwaps using absolute timelocks. A watchtower guarding for CoinSwaps using absolute timelocks would: * Need to know the funding outpoint it is guarding. * Watchtowers for Lightning (and contract-transaction-based CoinSwap) do = *not* need to know this, they just need to know a transaction ID that, if c= onfirmed, they will broadcast *another* transaction. * Need to watch *blockheight*. * Watchtowers for Lightning (and contract-transaction-based CoinSwap) onl= y check for transactions matching txids they are watching for. In particular the first point is a massive privacy lose. Lightning watchtowers can have the txid they are watching for in the clear,= and the transaction they will broadcast in reaction to the watched txid be= ing confirmed is encrypted using a key derived from the transaction with th= e given txid, and thus do not learn which funding outpoint it is protecting= until an attack occurs, which is very good for privacy. (even if the maker were to run private watchtowers of their own rather than= using some public watchtower service, if the private watchtower is hacked = it contains information that can be used to identify funding outpoints, thu= s making them targets. Thus, it is best if watchtowers, whether public or private, do not contain = any privacy-damaging information, to reduce the attack surface on privacy.) A way to make watchtowers for absolute-timelock CoinSwap also have the same= interface (i.e. "Watch for this txid, if it appears onchain broadcast this= transaction") as Lightning watchtowers would be to have the timeout tx pay= out to a `OP_IF <1 day> OP_CHECKSEQUENCEVERIFY OP_DROP OP_ELSE OP_ENDIF OP_CHECKSIGVERIFY`. The revocation key would be the same private key that is turned over at the= end of the CoinSwap. So, if the absolute timelock expires and the other participant broadcasts t= he timeout tx, the maker still has an opportunity to revoke that output, fo= r one additional day. Then, at the end of the CoinSwap where the private key is turned over, the = maker can hand the txid of the timeout tx, plus an encrypted transaction th= at spends from the revocation branch of the timeout tx back to the maker an= d a tip to the watchtower, to the watchtower, who remains unaware what the = funding txo is (it only gets a txid and an encrypted blob, so gets no infor= mation). The same interface can be used by Lightning Poon-Dryja (it is sub-optimal, = but usable, for Decker-Russell-Osuntokun), and the watchtower would not eve= n learn if it was watching for a Lightning channel or for a CoinSwap. Then, if the maker were holding on to the funding outpoint of its incoming = HTLC in the hope another taker arrives for its services, and then some sill= y human trips over the maker hardware power cord, and the condition is not = fixed by the timeout, it can still be privately protected by watchtowers. This comes at the cost of even worse UX if something goes wrong with the sw= ap: an increased timeout. Regards, ZmnSCPxj