From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Chris Belcher <belcher@riseup•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Sat, 22 Aug 2020 01:09:35 +0000 [thread overview]
Message-ID: <mht_82bLLV27HegePe5Cl_jSLnQ0qHYeH7V-aUNT3H6JYcECIG135hvxwrJr0QvLM5_7VpOd7cUUXZegQv5K0y27feckAe2B84oBz-2ZhqE=@protonmail.com> (raw)
In-Reply-To: <f5ba3015-2ec8-b35d-dc40-3e3e9e11449f@riseup.net>
Good morning Chris,
> > Absolute timelocks mean that you can set a timer where you put your node to sleep without risk of loss of funds (basically, once the absolute timelocks have resolved, you can forget about CoinSwaps).
> > But I think the ability to spend at any time would be better, and getting 100% online 144 blocks a day, 2016 blocks a retargeting period is becoming 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 what 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, but
> > > its not costless. The taker sets up the entire CoinSwap protocol because
> > > they wanted more privacy; but if the taker broadcasts the Alice contract
> > > 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 with
> > > 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 this
> > > will be spending miner fees.
> >
> > They would be spending miner fees from the funds being stolen, thus still 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 that wants to put its freshly-private funds into cold storage will do this anyway.
> > - The taker gets a fresh, private coin from this incoming HTLC, so 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 hope that the maker is offline.
> > - The fees paid for this are from the contract transaction that the taker is trying to steal.
> > Even if the theft attempt fails, the taker has already gotten its 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 transaction 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 off the 2-of-2, not `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 2p-ECDSA (again implemented by a tx directly off the 2-of-2) instead of a hashlock, seems to avoid this, I think, at the cost of reducing the utility of private key turnover by having a deadline where the private key has to be used.
> > 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/Schnorr immediately.
It also makes watchtowers for Lightning inherently incompatible with watchtowers 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 confirmed, they will broadcast *another* transaction.
* Need to watch *blockheight*.
* Watchtowers for Lightning (and contract-transaction-based CoinSwap) only 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 being confirmed is encrypted using a key derived from the transaction with the 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, thus 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 <revocationkey> 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 the timeout tx, the maker still has an opportunity to revoke that output, for 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 that spends from the revocation branch of the timeout tx back to the maker and 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 information).
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 even 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 silly 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 swap: an increased timeout.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-08-22 1:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 12:05 Chris Belcher
2020-08-20 11:17 ` ZmnSCPxj
2020-08-20 15:28 ` Nadav Kohen
2020-08-20 21:38 ` ZmnSCPxj
2020-08-20 22:37 ` Chris Belcher
2020-08-20 22:15 ` Chris Belcher
2020-08-21 4:20 ` ZmnSCPxj
2020-08-21 9:47 ` Chris Belcher
2020-08-22 1:09 ` ZmnSCPxj [this message]
2020-08-24 19:30 ` Antoine Riard
2020-08-25 3:16 ` ZmnSCPxj
2020-09-03 9:00 ` Chris Belcher
2020-09-03 9:45 ` ZmnSCPxj
2020-09-03 10:50 ` Chris Belcher
2020-09-03 23:39 ` ZmnSCPxj
2020-09-05 2:45 ` ZmnSCPxj
2020-09-05 1:10 ` Antoine Riard
2020-09-05 2:29 ` ZmnSCPxj
2020-08-29 22:03 ` Chris Belcher
2020-08-30 13:38 ` ZmnSCPxj
2020-09-05 1:07 ` Antoine Riard
2020-09-06 3:06 ` seid Mohammed
2020-10-03 10:36 ` [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher
2020-10-03 13:31 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='mht_82bLLV27HegePe5Cl_jSLnQ0qHYeH7V-aUNT3H6JYcECIG135hvxwrJr0QvLM5_7VpOd7cUUXZegQv5K0y27feckAe2B84oBz-2ZhqE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox