To: bitcoin-dev@lists.linuxfoundation.org
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: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
Date: Tue, 11 Aug 2020 13:05:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: [bitcoin-dev] Detailed protocol design for routed multi-transaction
	CoinSwap
Precedence: list

I'm currently working on implementing CoinSwap (see my other email
"Design for a CoinSwap implementation for massively improving Bitcoin
privacy and fungibility").

CoinSwaps are special because they look just like regular bitcoin
transactions, so they improve the privacy even for people who do not use
them. Once CoinSwap is deployed, anyone attempting surveillance of
bitcoin transactions will be forced to ask themselves the question: how
do we know this transaction wasn't a CoinSwap?

This email contains a detailed design of the first protocol version. It
makes use of the building blocks of multi-transaction CoinSwaps, routed
CoinSwaps, liquidity market, private key handover, and fidelity bonds.
It does not include PayJoin-with-CoinSwap, but that's in the plan to be
added later.

== Routed CoinSwap ==

Diagram of CoinSwaps in the route:

    Alice ====> Bob ====> Charlie ====> Alice

Where (====>) means one CoinSwap. Alice gives coins to Bob, who gives
coins to Charlie, who gives coins to Alice. Alice is the market taker
and she starts with the hash preimage. She chooses the CoinSwap amount
and chooses who the makers will be.

This design has one market taker and two market makers in its route, but
it can easily be extended to any number of makers.

== Multiple transactions ==

Each single CoinSwap is made up of multiple transactions to avoid amount
correlation

          (a0 BTC) --->     (b0 BTC) --->         (c0 BTC) --->
    Alice (a1 BTC) ---> Bob (b1 BTC) ---> Charlie (c1 BTC) ---> Alice
          (a2 BTC) --->     (b2 BTC) --->         (c2 BTC) --->

The arrow (--->) represent funding transactions. The money gets paid to
a 2-of-2 multisig but after the CoinSwap protocol and private key
handover is done they will be controlled by the next party in the route.

This example has 6 regular-sized transactions which use approximately
the same amount of block space as a single JoinMarket coinjoin with 6
parties (1 taker, 5 makers). Yet the privacy provided by this one
CoinSwap would be far far greater. It would not have to be repeated in
the way that Equal-Output CoinJoins must be.

== 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.


=== 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.

== Funding transaction definitions ==

Funding transactions are those which pay into the 2-of-2 multisig addresses.

Definitions:
I = initial coinswap amount sent by Alice = a0 + a1 + a2
(WA, WB, WC) = Total value of UTXOs being spent by Alice, Bob, Charlie
               respectively. Could be called "wallet Alice", "wallet
               Bob", etc
(B, C) = Coinswap fees paid by Alice and earned by Bob and Charlie.
(M1, M2, M3) = Miner fees of the first, second, third, etc sets of
               funding transactions. Alice will choose what these are
               since she's paying.
multisig(A+B) = A 2of2 multisig output with private keys held by A and B

The value in square parentheses refers to the bitcoin amount.

Alice funding txes
  [WA btc] ---> multisig (Alice+Bob) [I btc]
                change [WA-M1-I btc]
Bob funding txes
  [WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc]
                change [WB-I+B btc]
Charlie funding txes
  [WC btc] ---> multisig (Charlie+Alice) [(I-M2-B)-M3-C btc]
                change [WC-(I-M2-B)+C btc]

Here we've drawn these transactions as single transactions, but they are
actually multiple transactions where the outputs add up some value (e.g.
add up to I in Alice's transactions.)

=== Table of balances before and after a successful CoinSwap ===

If a CoinSwap is successful then all the multisig outputs in the funding
transactions will become controlled unilaterally by one party. We can
calculate how the balances of each party change.

Party   | Before | After
--------|--------|-------------------------------------------
Alice   | WA     | WA-M1-I + (I-M2-B)-M3-C  = WA-M1-M2-M3-B-C
Bob     | WB     | WB-I+B + I               = WB+B
Charlie | WC     | WC-(I-M2-B)+C + I-M2-B   = WC+C

After a successful coinswap, we see Alice's balance goes down by the
miner fees and the coinswap fees. Bob's and Charlie's balance goes up by
their coinswap fees.

== 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.

(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

Alice contract tx:
    multisig (Alice+Bob) ---> (Alice+timelock_A OR Bob+hash)
    [I btc]                   [I-M~ btc]
Bob contract tx:
    multisig (Bob+Charlie) ---> (Bob+timelock_B OR Charlie+hash)
    [I-M2-B btc]                [I-M2-B-M~ btc]
Charlie contract tx:
    multisig (Charlie+Alice)  ---> (Charlie+timelock_C OR Alice+hash)
    [(I-M2-B)-M3-C btc]            [(I-M2-B)-M3-C-M~ btc]


=== Table of balances before/after CoinSwap using contracts transactions ===

In this case the parties had to get their money back by broadcasting and
mining the contract transactions and waiting for timeouts.

Party   | Before | After
--------|--------|--------------------------------------------
Alice   | WA     | WA-M1-I + I-M~                   = WA-M1-M~
Bob     | WB     | WB-I+B + I-M2-B-M~               = WB-M2-M~
Charlie | WC     | WC-(I-M2-B)+C + (I-M2-B)-M3-C-M~ = WC-M3-M~

In the timeout failure case, every party pays for their own miner fees.
And nobody earns or spends any coinswap fees. So even for a market maker
its possible for their wallet balance to go down sometimes, although as
we shall see there are anti-DOS features which make this unlikely to
happen often.

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.


There can also be a failure case where each party gets their money using
hash preimage values instead of timeouts. Note that each party has to
sweep the output before the timeout expires, so that will cost an
additional miner fee M~.

Party   | Before | After
--------|--------|------------------------------------------------------
Alice   | WA     | WA-M1-I + (I-M2-B)-M3-C-M~ - M~ = WA-M1-M2-M3-B-C-2M~
Bob     | WB     | WB-I+B + I-M~ - M~              = WB+B-2M~
Charlie | WC     | WC-(I-M2-B)+C + I-M2-B-M~ - M~  = WC+C-2M~

In this situation the makers Bob and Charlie earn their CoinSwap fees,
but they pay an additional miner fee twice. Alice pays for all the
funding transaction miner fees, and the CoinSwap fees, and two
additional miner fees. And she had her privacy damaged because the
entire world saw on the blockchain the contract script.

Using the timelock path is like a refund, everyone's coin just comes
back to them. Using the preimage is like the CoinSwap transaction
happened, with the coins being sent ahead one hop. Again note that if
the preimage is used then coinswap fees are paid.

=== Staggered timelocks ===

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.

== 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

Taker sends unsigned transaction which pays to multisig using pubkey Q,
and also sends nonce p. The maker can use nonce p to calculate (q + p)
which is the private key of pubkey R.

Taker doesnt know the privkey because they are unable to find q because
of the ECDLP.

Any eavesdropper can see the nonce p and easily calculate the point R
too but Tor communication is encrypted so this isnt a concern.

None of the makers in the route know each other's Q values, so Alice the
taker will generate a nonce p on their behalf and send it over. I
believe this cant be used for any kind of attack, because the signing
maker will always check that the nonce results in the public key
included in the transaction they're signing, and they'll never sign a
transaction not in their interests.


== Protocol ==

This section is the most important part of this document.

Definitions:
fund = all funding txes (remember in this multi-tx protocol there can be
       multiple txes which together make up the funding)
A htlc = all htlc contract txes (fully signed) belonging to party A
A unsign htcl = all unsigned htlc contract txes belonging to party A
                including the nonce point p used to calculate the
                maker's pubkey.
p = nonce point p used in the tweak EC protocol for calculating the
    maker's pubkey
A htlc B/2 = Bob's signature for the 2of2 multisig of the Alice htlc
             contract tx
privA(A+B) = private key generated by Alice in the output
             multisig (Alice+Bob)


 | Alice           | Bob             | Charlie         |
 |=================|=================|=================|
0. A unsign htlc ---->               |                 |
1.               <---- A htlc B/2    |                 |
2. ***** BROADCAST AND MINE ALICE FUNDING TXES ******  |
3. A fund+htlc+p ---->               |                 |
4.                 | B unsign htlc ---->               |
5.                 |               <---- B htlc C/2    |
6. ******* BROADCAST AND MINE BOB FUNDING TXES ******* |
7.                 | B fund+htlc+p ---->               |
8.               <---------------------- C unsign htlc |
9.    C htlc A/2 ---------------------->               |
A. ***** BROADCAST AND MINE CHARLIE FUNDING TXES ***** |
B.               <---------------------- C fund+htlc+p |
C. hash preimage ---------------------->               |
D. hash preimage ---->               |                 |
E.    privA(A+B) ---->               |                 |
F.                 |    privB(B+C) ---->               |
G.               <---------------------- privC(C+A)    |

== Protocol notes ==
0-2 are the steps which setup Alice's funding tx and her contract tx for
    possible refund
4-5 same as 0-2 but for Bob
8-9 same as 0-2 but for Charlie
3,7 is proof to the next party that the previous party has already
    committed miner fees to getting a transaction mined, and therefore
    this isnt a DOS attack. The step also reveals the fully-signed
    contract transaction which the party can use to get their money back
    with a preimage.
C-G is revealing the hash preimage to all, and handing over the private
    keys


== Analysis of aborts ==

We will now discuss aborts, which happen when one party halts the
protocol and doesnt continue. Perhaps they had a power cut, their
internet broke, or they're a malicious attacker wanting to waste time
and money. The other party may try to reestablish a connection for some
time, but eventually must give up.

Number refers to the step number where the abort happened
e.g. step 1 means that the party aborted instead of the action happening
on protocol step 1.

The party name refers to what that party does
e.g. Party1: aborts, Party2/Party3: does a thing in reaction

0. Alice: aborts. Bob/Charlie: do nothing, they havent lost any time or
   money
1. Bob: aborts. Alice: lost no time or money, try with another Bob.
   Charlie: do nothing
2-3. same as 0.
4. Bob: aborts. Charlie: do nothing. Alice: broadcasts her contract tx
   and waits for the timeout, loses time and money on miner fees, she'll
   never coinswap with Bob's fidelity bond again.
5. Charlie: aborts. Alice/Bob: lose nothing, find another Charlie to
   coinswap with.
6. same as 4.
7. similar to 4 but Alice MIGHT not blacklist Bob's fidelity bond,
   because Bob will also have to broadcast his contract tx and will also
   lose time and money.
8. Charlie: aborts. Bob: broadcast his contract transaction and wait for
   the timeout to get his money back, also broadcast Alice's contract
   transaction in retaliation. Alice: waits for the timeout on her htlc
   tx that Bob broadcasted, will never do a coinswap with Charlie's
   fidelity bond again.
9. Alice: aborts. Charlie: do nothing, no money or time lost. Bob:
   broadcast bob contract tx and wait for timeout to get money back,
   comforted by the knowledge that when Alice comes back online she'll
   have to do the same thing and waste the same amount of time and
   money.
A-B. same as 8.
C-E. Alice: aborts. Bob/Charlie: all broadcast their contract txes and
     wait for the timeout to get their money back, or if Charlie knows
     the preimage he uses it to get the money immediately, which Bob can
     read from the blockchain and also use.
F. Bob: aborts. Alice: broadcast Charlie htlc tx and use preimage to get
   money immediately, Alice blacklists Bob's fidelity bond. Charlie:
   broadcast Bob htlc and use preimage to get money immediately.
G. Charlie: aborts. Alice: broadcast Charlie htlc and use preimage to
   get money immediately, Alice blacklists Charlie's fidelity bond. Bob:
   does nothing, already has his privkey.

==== Retaliation as DOS-resistance ====

In some situations (e.g. step 8.) if one maker in the coinswap route is
the victim of a DOS they will retaliate by DOSing the previous maker in
the route. This may seem unnecessary and unfair (after all why waste
even more time and block space) but is actually the best way to resist
DOS because it produces a concrete cost every time a DOS happens.


== 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
3. 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.
7. 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
8. Charlie: nothing else is possible except following the protocol or
   aborting.
9. 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).


== Conclusion ==

This document describes the first version of the protocol which
implements multi-transaction Coinswap, routed Coinswap, fidelity bonds,
a liquidity market and private key handover. I describe the protocol and
also analyze aborts of the protocols and deviations from the protocol.