path: root/08/99ceeec014253941af9da9e84836f26bcdb499

Return-Path: <belcher@riseup.net>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0E52EC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Aug 2020 22:15:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 0332486B60
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Aug 2020 22:15:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8H0ctVjN0okI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Aug 2020 22:15:42 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 1A4BD86B5B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Aug 2020 22:15:42 +0000 (UTC)
Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
 by mx1.riseup.net (Postfix) with ESMTPS id 4BXf9T02v5zDt1p;
 Thu, 20 Aug 2020 15:15:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1597961741; bh=ByjtBZlqI8XwUhOEy6mqp0E/tOkGkjbkyuhFsIn3UoY=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=Hch8xbXt+jTtfeHitiMDztOtib/hSAFcHzhexfhueAH9ShZ88XFsQujdgoJWuCAuU
 5ldzFZLJ6rJEVHS9onCCA1/6XDSoF07CvFhmE9ksdnhpsMfhRmUrclYCMxe2O83YeF
 UPitbrgsN/VqmzkmoNsmfn4OgJ+S36sGjDejzb6Y=
X-Riseup-User-ID: 133CFD508615DB734D8FF901BB97BE8FDB5542A428BF5F08C39B6051F7B4248D
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by bell.riseup.net (Postfix) with ESMTPSA id 4BXf9S0prSzJmg8;
 Thu, 20 Aug 2020 15:15:39 -0700 (PDT)
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <xhRsCejqgUjoLy5hPMHgFcZdiqJsO7TfS0azWhis9-tvSgXodoKe7gN5IXyiVIVqUWSm7FoY-aBUaJCCDgixdWUN4n8EzhQlSNshsQeIFsw=@protonmail.com>
From: Chris Belcher <belcher@riseup.net>
Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata=
 xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92
 f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl
 YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR
 FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE
 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7
 ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz
 WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu
 sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht
 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi
 Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj
 aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV
 CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX
 TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA
 btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A
 HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm
 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF
 LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA
 wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7
 OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb
 jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl
 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2
 k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr
 ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r
 KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf
 xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM
 KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6
 q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC
 z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW
 dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI
 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc
 /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA
 DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN
 IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93
 qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0
 +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON
 xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA
 aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ
 uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK
 MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc
 d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN
 HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM
 1aSoTg==
Message-ID: <e8ca67be-d07c-3f2e-4318-0d2bab061dd9@riseup.net>
Date: Thu, 20 Aug 2020 23:15:34 +0100
MIME-Version: 1.0
In-Reply-To: <xhRsCejqgUjoLy5hPMHgFcZdiqJsO7TfS0azWhis9-tvSgXodoKe7gN5IXyiVIVqUWSm7FoY-aBUaJCCDgixdWUN4n8EzhQlSNshsQeIFsw=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Thu, 20 Aug 2020 22:15:44 -0000

Hello ZmnSCPxj,

Thanks for the review. My comments are inline.

On 20/08/2020 12:17, ZmnSCPxj wrote:
> Good morning Chris,
> 
> Great to see this!
> 
> Mostly minor comments.
> 
> 
> 
>>
>> == Direct connections to Alice ===
>>
>> Only Alice, the taker, knows the entire route, Bob and Charlie just know
>> their previous and next transactions. Bob and Charlie do not have direct
>> connections with each other, only with Alice.
>>
>> Diagram of Tor connections:
>>
>> Bob Charlie
>> | /
>> | /
>> | /
>> Alice
>>
>> When Bob and Charlie communicate, they are actually sending and
>> receiving messages via Alice who relays them to Charlie or Bob. This
>> helps hide whether the previous or next counterparty in a CoinSwap route
>> is a maker or taker.
>>
>> This doesn't have security issues even in the final steps where private
>> keys are handed over, because those private keys are always for 2-of-2
>> multisig and so on their own are never enough to steal money.
> 
> This has a massive advantage over CoinJoin.
> 
> In CoinJoin, since all participants sign a single transaction, every participant knows the total number of participants.
> Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, the maker knows exactly which output belongs to the taker.
> Even if all communications were done via the single paying taker, the maker(s) are shown the final transaction and thus can easily know how many participants there are (by counting the number of equal-valued outputs).
> 
> With CoinSwap, in principle no maker has to know how many other makers are in the swap.
> 
> Thus it would still be useful to make a single-maker CoinSwap, as that would be difficult, for the maker, to diferentiate from a multi-maker CoinSwap.

Yes great point.

> There are still a few potential leaks though:
> 
> * If paying through a CoinSwap, the cheapest option for the taker would be to send out a single large UTXO (single-output txes) to the first maker, and then demand the final payment and any change as two separate swaps from the final maker.
>   * Intermediate makers are likely to not have exact amounts, thus is unlikely to create a single-output tx when forwarding.
>   * Thus, the first maker could identify the taker.

Right, so if the taker uses only a single maker then they must have more
than one UTXO.

This leak in the case of a taker spending a single UTXO also happens
when the taker needs to create a branching route. I described this in my
original email "Design for a CoinSwap implementation for massively
improving Bitcoin privacy and fungibility" under the section "Combining
multi-transaction with routing" (the second diagram).

I think this might be unavoidable. If the taker has just one UTXO they'd
be much better off using multiple makers for this reason.


> * The makers can try timing the communications lag with the taker.
>   The general assumption would be that more makers == more delay in taker responses.

Sounds like adding random delays would fix this. The protocol already
involves waiting for a confirmation (average waiting time 10 minutes, at
best) and might involve more confirmations for extra security and
privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause
too many issues.
Also the Tor network can be pretty laggy so that might add enough noise
anyway.

>>
>> === Miner fees ===
>>
>> Makers have no incentive to pay any miner fees. They only do
>> transactions which earn them an income and are willing to wait a very
>> long time for that to happen. By contrast takers want to create
>> transactions far more urgently. In JoinMarket we coded a protocol where
>> the maker could contribute to miner fees, but the market price offered
>> of that trended towards zero. So the reality is that takers will pay all
>> the miner fees. Also because makers don't know the taker's time
>> preference they don't know how much they should pay in miner fees.
>>
>> The taker will have to set limits on how large the maker's transactions
>> are, otherwise makers could abuse this by having the taker consolidate
>> maker's UTXOs for free.
> 
> Why not have the taker pay for the *first* maker-spent UTXO and have additional maker-spent UTXOs paid for by the maker?
> i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).
> 
> Disagreements on feerate can be resolved by having the taker set the feerate, i.e. "the customer is always right".
> Thus if the maker *has to* spend two UTXOs to make up the 0.4 BTC bag, it pays for the mining fees for that extra UTXO.
> The maker can always reject the swap attempt if it *has to* spend multiple UTXOs and would lose money doing so if the taker demands a too-high feerate.

Having the taker pay for just one UTXO will have an unfortunate side
effect of resulting in the maker's money being split up into a large
number of UTXOs, because every CoinSwap they take part in has an
incentive to increase their UTXO count by one. At the start of
JoinMarket this was an issue where then a taker wanting to CoinJoin a
large would come along and the result would be a huge CoinJoin
transaction with many many small inputs. Perhaps the taker could pay for
2-3 UTXOs to counteract this. (Of course the exact number would be
configurable by the taker user, but defaults usually don't get changed).

I'm still not convinced with having makers contribute to miner fees. In
JoinMarket we tried to get makers to contribute a little to miner fees
and simply they never did in any meaningful way. The market has spoken.
In terms of incentives makers are happy to wait a very long time, if we
assume they're just HODLers then even if they earn a few thousand
satoshis that's good.

>> == Contract transaction definitions ==
>>
>> Contract transactions are those which may spend from the 2-of-2 multisig
>> outputs, they transfer the coins into a contract where the coins can be
>> spent either by waiting for a timeout or providing a hash preimage
>> value. Ideally contract transactions will never be broadcast but their
>> existence keeps all parties honest.
>>
>> M~ is miner fees, which we treat as a random variable, and ultimately
>> set by whichever pre-signed RBF tx get mined. When we talk about the
>> contract tx, we actually mean perhaps 20-30 transactions which only
>> differ by the miner fee and have RBF enabled, so they can be broadcasted
>> in sequence to get the contract transaction mined regardless of the
>> demand for block space.
> 
> The highest-fee version could have, in addition, CPFP-anchor outputs, like those being proposed in Lightning, so even if onchain fees rise above the largest fee reservation, it is possible to add even more fees.
> 
> Or not.
> Hmm.

I think RBF transactions are better because they ultimately use less
block space than CPFP.

There seems to be very little cost in signing many additional
precomputed RBF transactions. So the taker and makers could sign
transactions all the way up to 10000 sat/vbyte. I think this doesn't
apply to Lightning, because bandwidth seems to be more constrained
there: even a tiny micropayment for 1 satoshi would require 10x or 100x
more bandwidth if every lightning htlc used precomputed RBF.

> Another thought: later you describe that miner fees are paid by Alice by forwarding those fees as well, how does that work when there are multiple versions of the contract transaction?

Alice only pays the miner fees for the funding transactions, not the
contract transaction. The miner fees for the contract transactions are
taken from the contract balance. The contract transactions are 1-input
1-output, and whoever ends up with the money will be the one who paid
the miner fee.

>> (Alice+timelock_A OR Bob+hash) = Is an output which can be spent
>> either with Alice's private key
>> after waiting for a relative
>> timelock_A, or by Bob's private key by
>> revealing a hash preimage value
> 
> The rationale for relative timelocks is that it makes private key turnover slightly more useable by ensuring that, after private key turnover, it is possible to wait indefinitely to spend the UTXO it received.
> This is in contrast with absolute timelocks, where after private key turnover, it is required to spend received UTXO before the absolute timeout.
> 
> The dangers are:
> 
> * Until it receives the private key, if either of the incoming or outgoing contract transactions are confirmed, every swap participant (taker or maker) should also broadcast the other contract transaction, and resolve by onchain transactions (with loss of privacy).
> * After receiving the private key, if the incoming contract transaction is confirmed, it should spend the resulting contract output.
> * It is possible to steal from a participant if that participant goes offline longer than the timeout.
>   This may imply that there may have to be some minimum timeout that makers indicate in their advertisements.
>   * The taker can detect if the first maker is offline, then if it is offline, try a contract transaction broadcast, if it confirms, the taker can wait for the timeout; if it times out, the taker can clawback the transaction.
>     * This appears to be riskless for the taker.
>     * Against a similar attack, Lightning requires channel reserves, which means the first hop never gains control of the entire value, which is a basic requirement for private key turnover.
>   * On the other hand, the taker has the largest timeout before it can clawback the funds, so it would wait for a long time, and at any time in between the first maker can come online and spend using the hashlock branch.
>     * But the taker can just try on the hope it works; it has nothing to lose.
>   * This attack seems to be possible only for the taker to mount.
>     Other makers on the route cannot know who the other makers are, without cooperation of the taker, who is the only one who knows all the makers.
>     * On the other hand, the last maker in the route has an outgoing HTLC with the smallest timelock, so it is the least-risk and therefore a maker who notices its outgoing HTLC has a low timeout might want to just do this anyway even if it is unsure if the taker is offline.

Every off-chain protocol like this has the livelyness requirement. Each
party must always be watching the chain and be ready to broadcast
something in response. I'm not sure how any of this relates to the
choice of relative vs absolute time locks.

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.

I also envision that makers will run their own personal "watchtowers",
similar to watchtowers in the lightning world, which would watch the
blockchain and be ready to broadcast a transaction. In terms of
incentives, makers are HODLers and we can expect them to protect their
stash very carefully by running perhaps multiple redundant watchtowers
in multiple locations and multiple networks. Therefore a taker noticing
that a maker's .onion is down does not imply that all the maker's
watchtowers are down.

Of course we will choose the timelocks to be long enough so that
everyone has enough time to broadcast a transaction in response, even in
times of congested mempools.

>   * Participants might want to spend from the UTXO to a new address after private key turnover anyway.
>     Makers could spend using a low-fee RBF-enabled tx, and when another request comes in for another swap, try to build a new funding tx with a higher-fee bump.

I don't think this will happen very often. It's spending money on block
space for not much benefit. If the maker ever decides to shut down their
maker they can transfer all their coins in HTLCs to single-sig
transactions exclusively controlled by them, but in normal operation I
doubt it will happen.


>> A possible attack by a malicious Alice is that she chooses M1 to be very
>> low (e.g. 1 sat/vbyte) and sets M2 and M3 to be very high (e.g. 1000
>> sat/vb) and then intentionally aborts, forcing the makers to lose much
>> more money in miner fees than the attacker. The attack can be used to
>> waste away Bob's and Charlie's coins on miner fees at little cost to the
>> malicious taker Alice. So to defend against this attack Bob and Charlie
>> must refuse to sign a contract transaction if the corresponding funding
>> transaction pays miner fees greater than Alice's funding transaction.
> 
> Sorry, I do not follow the logic for this...?

I'll try to explain again with an example, hopefully it clarifies.

Recall the table of balances before/after CoinSwap using contracts
transactions:

Party   | Before | After
--------|--------|--------------------------------------------
Alice   | WA     | WA-M1-I + I-MA~                  = WA-M1-MA~
Bob     | WB     | WB-I+B + I-M2-B-MB~              = WB-M2-MB~


What the table says is that if the CoinSwap results in the HTLC
transactions being mined and the locktime branch being used, then both
Alice and Bob will see their wallet balance fall by two miner fees (in
Alice's case the miner fee of the Alice funding transaction plus the
miner fee of the Alice contract transaction).

The attack I describe works because Alice chooses both MA~ and MB~. The
attack is that Alice chooses MA~ to be a very low value (e.g. 1 sat/vb)
and chooses MB~ to be a very high value (e.g. 1000 sat/vb). Then Alice
intentionally sabotages the CoinSwap and forces it to go to the timeout
case, what happens is that Bob's wallet balance falls by much more than
Alice's, because MB~ > MA~. So this is a DOS attack: Alice can waste
Bob's resources without wasting much of her own.

>> The timelocks are staggered so that if Alice uses the preimage to take
>> coins then the right people will also learn the preimage and have enough
>> time to be able to get their coins back too. Alice starts with knowledge
>> of the hash preimage so she must have a longest timelock.
> 
> More precisely:
> 
> * The HTLC outgoing from Alice has the longest timelock.
> * The HTLC incoming into Alice has the shortest timelock.
> 
> For the makers, they only need to ensure that the incoming timelock is much larger than the outgoing timelock.

Agreed.

Perhaps I chose confusing terminology, "Alice contract transaction"
means the transaction which pays money to Alice after a timeout. The
text you quoted is confusingly written, and it would've been better to
write: "Alice starts with knowledge of the hash preimage so the Alice
contract transaction must have a longest timelock."

>> == EC tweak to reduce one round trip ==
>>
>> When two parties are agreeing on a 2-of-2 multisig address, they need to
>> agree on their public keys. We can avoid one round trip by using the EC
>> tweak trick.
>>
>> When Alice, the taker, downloads the entire offer book for the liquidity
>> market, the offers will also contain a EC public key. Alice can tweak
>> this to generate a brand new public key for which the maker knows the
>> private key. This public key will be one of the keys in the 2-of-2
>> multisig. This feature removes one round trip from the protocol.
>>
>> q = EC privkey generated by maker
>> Q = q.G = EC pubkey published by maker
>>
>> p = nonce generated by taker
>> P = p.G = nonce point calculated by taker
>>
>> R = Q + P = pubkey used in bitcoin transaction
>> = (q + p).G
> 
> Whoa whoa whoa whoa.
> 
> All this time I was thinking you were going to use 2p-ECDSA for all 2-of-2s.
> In which case, the private key generated by the taker would be sufficient tweak to blind this.
> 
> In 2p-ECDSA, for two participants M = m * G; T = t * G, the total key is m * t * G = m * T = t * M.
> 
> Are you going to use `2 <T> <Q+P> 2 OP_CHECKMULTISIG` instead of 2p-ECDSA?
> Note that you cannot usefully hide among Lightning mutual closes, because of the reserve; Lightning mutual closes are very very likely to be spent in a 1-input (that spends from a 2-of-2 P2WSH), 2-output (that pays to two P2WPKHs) tx.

Yes, I intend for 2p-ECDSA to be used eventually, but for the first
version I'll only implement regular multisigs with OP_CHECKMULTISIG.
Once all the other details of this protocol are implemented correctly
and mostly-bug-free then 2p-ECDSA can be added. It can be added in the
protocol steps 0-1, 3-5 and 7-9.

This document also doesn't talk about PayJoin-with-CoinSwap, but that
can be added later too.

>>
>>     == Analysis of deviations ==
>>
>>     This section discusses what happens if one party deviates from the
>>     protocol by doing something else, for example broadcasting a htlc
>>     contract tx when they shouldnt have.
>>
>>     The party name refers to what that party does, followed by other party's
>>     reactions to it.
>>     e.g. Party1: does a thing, Party2/Party3: does a thing in reaction
>>
>>     If multiple deviations are possible in a step then they are numbered
>>     e.g. A1 A2 A2 etc
>>
>>     0-2. Alice/Bob/Charlie: nothing else is possible except following the
>>     protocol or aborting
>>
>> 8.  Alice: broadcasts one or more of the A htlc txes. Bob/Charlie/Dennis:
>>     do nothing, they havent lost any time or money.
>>     4-6. Bob/Charlie: nothing else is possible except following the protocol
>>     or aborting.
>>
>> 9.  Bob: broadcasts one or more of the B htlc txes, Alice: broadcasts all
>>     her own A htlc txes and waits for the timeout to get her money back.
>>     Charlie: do nothing
>>
>> 10.  Charlie: nothing else is possible except following the protocol or
>>     aborting.
>>
>> 11.  Alice: broadcasts one or more of the A htlc txes. Bob: broadcasts all
>>     his own A htlc txes and waits for the timeout.
>>     A. same as 8.
>>     B. Charlie: broadcasts one or more of the C htlc txes, Alice/Bob:
>>     broadcasts all their own htlc txes and waits for the timeout to get
>>     their money back.
>>     C-E1. Alice: broadcasts all of C htlc txes and uses her knowledge of the
>>     preimage hash to take the money immediately. Charlie: broadcasts
>>     all of B htlc txes and reading the hash value from the blockchain,
>>     uses it to take the money from B htlc immediately. Bob: broadcasts
>>     all of A htlc txes, and reading hash from the blockchain, uses it
>>     to take the money from A htlc immediately.
>>     C-E2. Alice: broadcast her own A htlc txes, and after a timeout take the
>>     money. Bob: broadcast his own B htlc txes and after the timeout
>>     take their money. Charlie: broadcast his own C htlc txes and after
>>     the timeout take their money.
>>     F1. Bob: broadcast one or more of A htcl txes and use the hash preimage
>>     to get the money immediately. He already knows both privkeys of the
>>     multisig so this is pointless and just damages privacy and wastes
>>     miner fees. Alice: blacklist Bob's fidelity bond.
>>     F2. Bob: broadcast one or more of the C htlc txes. Charlie: use preimage
>>     to get his money immediately. Bob's actions were pointless. Alice:
>>     cant tell whether Bob or Charlie actually broadcasted, so blacklist
>>     both fidelity bonds.
>>     G1. Charlie: broadcast one or more of B htcl txes and use the hash
>>     preimage to get the money immediately. He already knows both
>>     privkeys of the multisig so this is pointless and just damages
>>     privacy and wastes miner fees. Alice: cant tell whether Bob or
>>     Charlie actually broadcasted, so blacklist both fidelity bonds.
>>     G2. Charlie: broadcast one or more of the A htlc txes. Alice: broadcast
>>     the remaining A htlc txes and use preimage to get her money
>>     immediately. Charlies's actions were pointless. Alice: blacklist
>>     Charlie's fidelity bond.
>>
>>     The multisig outputs of the funding transactions can stay unspent
>>     indefinitely. However the parties must always be watching the network
>>     and ready to respond with their own sweep using a preimage. This is
>>     because the other party still possesses a fully-signed contract tx. The
>>     parties respond in the same way as in steps C-E1, F2 and G2. Alice's
>>     reaction of blacklisting both fidelity bonds might not be the right way,
>>     because one maker could use it to get another one blacklisted (as well
>>     as themselves).
> 
> Looks OK, though note that a participant might try to do so (as pointed out above) in the hope that the next participant is offline.

I really hope that everyone (the makers at least) is running multiple
redundant watchtowers, so that anyone attempting this attack just wastes
money on miner fees and achieves nothing.