path: root/f5/d158bb6922acce66db15e255422409a9f973cd

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 81D79C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <mht_82bLLV27HegePe5Cl_jSLnQ0qHYeH7V-aUNT3H6JYcECIG135hvxwrJr0QvLM5_7VpOd7cUUXZegQv5K0y27feckAe2B84oBz-2ZhqE=@protonmail.com>
In-Reply-To: <f5ba3015-2ec8-b35d-dc40-3e3e9e11449f@riseup.net>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <xhRsCejqgUjoLy5hPMHgFcZdiqJsO7TfS0azWhis9-tvSgXodoKe7gN5IXyiVIVqUWSm7FoY-aBUaJCCDgixdWUN4n8EzhQlSNshsQeIFsw=@protonmail.com>
 <e8ca67be-d07c-3f2e-4318-0d2bab061dd9@riseup.net>
 <WtKtWCdqIFVTTqw9-EggdsTIo6ejfP8my868MYyAqO8FUboiXWZUd0hw2PyvEKZNJxqAWJ_9BnOllAGEuUYYcA654amKTC4MSmO3TO4A7pU=@protonmail.com>
 <f5ba3015-2ec8-b35d-dc40-3e3e9e11449f@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <taker> OP_ELSE <re=
vocationkey> 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