path: root/b4/1655b6b42ab4a84a82a2a3ee15d1f731df15ec

Return-Path: <rsomsen@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D995AC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 May 2020 16:00:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id BC24D8859D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 May 2020 16:00:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7OlS6p-DKpus
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 May 2020 16:00:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com
 [209.85.218.51])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 930CC88596
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 May 2020 16:00:20 +0000 (UTC)
Received: by mail-ej1-f51.google.com with SMTP id l27so5115878ejc.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 May 2020 09:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=vx8dqCdMu7mWYpi5nJYo6m+qR1+WlbPaA5bgE1lz19c=;
 b=I2okbiNp57r7zRTmBeS86nZ7uaFqOZqDXqhpw2MmUkyJQhMSn2PoBS+KYzPnVlE5od
 OcvZGKkb1MxYXOZok7uBxjs9w2Spj2atHJSPF1brha5Deq6Nw5mxSSffWNApKKz3hqbt
 Ss1uZb2JZJL+QnSRvLw7eRl8SVsyYz69dZ/92KnGSwQKqqAN6NFtn59T2V1x9kudw22j
 rdCWAMywOhr1p6lT9dmdnyhcKUdRtr7JcC5ew6waFIntJsjDfolCJ1PgHIouXiNaTpNe
 KhYogwnpVoxMzPYItIOPoLtJD1ohuP3845jVK/YzJyOJ9s6KAECpIlaPdnIkkTRNz40T
 KWUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=vx8dqCdMu7mWYpi5nJYo6m+qR1+WlbPaA5bgE1lz19c=;
 b=VQv778MaGhuJhMQ2AKqCCg3Ac2SwubewrKdKr4uQX42Y6NeQf2SFxppLtFfY5oVLR0
 dhApuQxm7A14iv6wpQ9m2rar58+oAu8b5TGbu/IO0moPJFLtPxt9SmXOIHgU07uOoo2O
 66nN4+UFVnHKPRa+gLl8dxpKFQzuTRjgLk8ahSpmJs6jdKC6E5Inih/Lv0uJiQgDBnVR
 XygPCogj6n0dmE9HGUwNF8xYiLv76+aVx7eSpBTIc2Pt2AVku8g+MfPePvoel9WDD9NQ
 Zvrd1Ow7xAnnrmgHR6Rxtcmusck068jmynyl5w1otLOf9wj2J7S+FSzieaAUsO7LPyXZ
 iotg==
X-Gm-Message-State: AOAM530EAI/JvP+dyAmbZ3iwk0+BdKT2QMv56H72MAWu2jy/s0u7ATut
 2zai+o944xmi9FuqhACjRKKi4ilrWaqKuFComEuyX6FDA5w=
X-Google-Smtp-Source: ABdhPJw+o+X8hy1h9Ynno/nRk01oo7LXW2r3eWgWkbWs6pZJcCpQsO5Ad1+F9bRJtpE8wZsbIm8Ku+15GDBZHy+pTYE=
X-Received: by 2002:a17:906:2f8d:: with SMTP id
 w13mr12965263eji.102.1590854418308; 
 Sat, 30 May 2020 09:00:18 -0700 (PDT)
MIME-Version: 1.0
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
In-Reply-To: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sat, 30 May 2020 18:00:05 +0200
Message-ID: <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007e238e05a6dfa8a0"
X-Mailman-Approved-At: Sat, 30 May 2020 16:01:23 +0000
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
 massively improving Bitcoin privacy and fungibility
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, 30 May 2020 16:00:26 -0000

--0000000000007e238e05a6dfa8a0
Content-Type: text/plain; charset="UTF-8"

Hey Chris,

Excellent write-up. I learned a few new things while reading this
(particularly how to overcome the heuristics for address reuse and address
types), so thank you for that.

I have a few thoughts about how what you wrote relates to Succinct Atomic
Swaps (SAS)[0]. Perhaps it's useful.

>For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2
multisignature addresses that look the same as regular single-signature
addresses

This may perhaps be counter-intuitive, but SAS doesn't actually require
multisig for one of the two outputs, so a single key will suffice. ECDSA is
a signing algorithm that doesn't support single key multisig (at least not
without 2p-ECDSA), but notice how for the non-timelocked SAS output we
never actually have to sign anything together with the other party. We swap
one of the two keys, and the final owner will create a signature completely
on their own. No multisig required, which means we can simply use MuSig,
even today without Schnorr.

Of course the other output will still have to be a 2-of-2, for which you
rightly note 2p-ECDSA could be considered. It may also be interesting to
combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
want to open a channel with 1 BTC each, but Alice funds it in her entirety
with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
to tell Bob entered the Lightning Network, especially if the channel is
opened in a state that isn't perfectly balanced. And Alice will gain an
uncorrelated single key output.

As a side note, we could use the same MuSig observation on 2-of-2 outputs
that need multisig by turning the script into (A & B) OR MuSig(A,B), which
would shave off quite a few bytes by allowing single sig spending once the
private key is handed over, but this would also make the output stick out
like a sore thumb... Only useful if privacy is not a concern.

>=== Multi-transaction CoinSwaps to avoid amount correlation ===

This can apply cleanly to SAS, and can even be done without passing on any
extra secrets by generating a sharedSecret (Diffie-Hellman key exchange).

Non-timelocked:
CoinSwap AddressB = aliceSecret + bobSecret
CoinSwap AddressC = aliceSecret + bobSecret + hash(sharedSecret,0)*G
CoinSwap AddressD  = aliceSecret + bobSecret + hash(sharedSecret,1)*G

The above is MuSig compatible (single key outputs), there are no timelocks
to worry about, and the addresses cannot be linked on-chain.

>they would still need to watch the chain and respond in case a
hash-time-locked contract transaction is broadcasted

Small detail, but it should be noted that this would require the atomic
swap to be set up in a specific way with relative timelocks.

>=== PayJoin with CoinSwap ===

While it's probably clear how to do it on the timelocked side of SAS, I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement). I can
explain it in detail, if it happens to catch your interest.

Cheers,
Ruben


[0]  Succinct Atomic Swaps (SAS)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html

On Mon, May 25, 2020 at 3:21 PM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> === Abstract ===
>
> Imagine a future where a user Alice has bitcoins and wants to send them
> with maximal privacy, so she creates a special kind of transaction. For
> anyone looking at the blockchain her transaction appears completely
> normal with her coins seemingly going from address A to address B. But
> in reality her coins end up in address Z which is entirely unconnected
> to either A or B.
>
> Now imagine another user, Carol, who isn't too bothered by privacy and
> sends her bitcoin using a regular wallet which exists today. But because
> Carol's transaction looks exactly the same as Alice's, anybody analyzing
> the blockchain must now deal with the possibility that Carol's
> transaction actually sent her coins to a totally unconnected address. So
> Carol's privacy is improved even though she didn't change her behaviour,
> and perhaps had never even heard of this software.
>
> In a world where advertisers, social media and other companies want to
> collect all of Alice's and Carol's data, such privacy improvement would
> be incredibly valuable. And also the doubt added to every transaction
> would greatly boost the fungibility of bitcoin and so make it a better
> form of money.
>
> This undetectable privacy can be developed today by implementing
> CoinSwap, although by itself that isn't enough. There must be many
> building blocks which together make a good system. The software could be
> standalone as a kind of bitcoin mixing app, but it could also be a
> library that existing wallets can implement allowing their users to send
> Bitcoin transactions with much greater privacy.
>
> == CoinSwap ==
>
> Like CoinJoin, CoinSwap was invented in 2013 by Greg Maxwell[1]. Unlike
> CoinJoin it is relatively complicated to implement and so far has not
> been deployed. But the idea holds great promise, and fixes many of the
> problems of some kinds of CoinJoins. CoinSwap is the next step for
> on-chain bitcoin privacy.
>
> CoinSwap is a way of trading one coin for another coin in a
> non-custodial way. It is closely related to the idea of an atomic swap.
> Alice and Bob can trade coins with each other by first sending to a
> CoinSwap address and having those coins then sent to Bob:
>
>     Alice's Address 1 ----> CoinSwap Address 1 ----> Bob's Address 1
>
> An entirely separate set of transactions gives Bob's coins to Alice in
> return:
>
>     Bob's Address 2 ----> CoinSwap Address 2 ----> Alice's Address 2
>
> Where the symbol ----> is a bitcoin transaction.
>
> Privacy is improved because an observer of the blockchain cannot link
> Alice's Address 1 to Alice's Address 2, as there is no transaction
> between them. Alice's Address 2 could either be an address in Alice's
> wallet, or the address of someone else she wants to transfer money to.
> CoinSwap therefore breaks the transaction graph heuristic, which is the
> assumption that if a transaction A -> B is seen then the ownership of
> funds actually went from A to B.
>
> CoinSwap doesnt break any of bitcoin's assumptions or features like an
> auditable supply or pruning. It can be built on today's bitcoin without
> any new soft forks.
>
> CoinSwap can't improve privacy much on its own, so it requires other
> building block to create a truly private system.
>
> === ECDSA-2P ===
>
> The original CoinSwap idea uses 2-of-2 multisig. We can get a slightly
> bigger anonymity set by using 2-of-3 multisigs with a fake third public
> key. For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses[2]. Even the old-style p2pkh addresses
> starting with 1 can be CoinSwap addresses.
>
> Because the transactions blend in with the rest of bitcoin, an
> application based on CoinSwap would provide much more privacy than the
> existing equal-output coinjoin apps (JoinMarket, Wasabi Wallet and
> Samourai Wallet's Whirlpool). CoinSwaps would also be cheaper for the
> same amount of privacy, as CoinJoin users usually create multiple
> CoinJoins to get effective privacy, for example JoinMarket's tumbler
> script does between 7-12 coinjoins (which are bigger than regular
> transactions too) when run with default parameters.
>
> Schnorr signatures with Musig provide a much easier way to create
> invisible 2-of-2 multisig, but it is not as suitable for CoinSwap. This
> is because the anonymity set for ECDSA would be much greater. All
> addresses today are ECDSA, and none are schnorr. We'd have to wait for
> schnorr to be added to bitcoin and then wait for users to adopt it. We
> see with segwit that even after nearly 3 years that segwit adoption is
> only about 60%, and segwit actually has a sizeable financial incentive
> for adoption via lower fees. Schnorr when used for single-sig doesn't
> have such an incentive, as Schnorr single-sig costs the same size as
> today's p2wpkh, so we can expect adoption to be even slower. (Of course
> there is an incentive for multisig transactions, but most transactions
> are single-sig). As schnorr adoption increases this CoinSwap system
> could start to use it, but for a long time I suspect it will mostly be
> using ECDSA for a greater anonymity set.
>
> === Liquidity market ===
>
> We can create a liquidity market for CoinSwap very similar to how
> JoinMarket works for CoinJoins. In our example above Alice would be a
> market taker and Bob would be a market maker. The taker Alice pays a fee
> to the maker Bob in return for choosing the amount of a CoinSwap and
> when it happens. This allows an excellent user experience because Alice
> can create CoinSwaps for any size she wants, at any time she wants.
> Right now in JoinMarket there is liquidity to create CoinJoins of sizes
> up to about 200 BTC, and we can expect a similar kind of thing with
> CoinSwap.
>
>
> === Multi-transaction CoinSwaps to avoid amount correlation ===
>
> This CoinSwap is vulnerable to amount correlation:
>
>     AliceA (15 BTC) ----> CoinSwap AddressA ----> BobA (15 BTC)
>     BobB (15 BTC) ----> CoinSwap AddressB ----> AliceB (15 BTC)
>
> Where AliceA, AliceB are addresses belonging to Alice. BobA, BobB are
> addresses belonging to Bob. If an adversary starts tracking at address
> AliceA they could unmix this CoinSwap easily by searching the entire
> blockchain for other transactions with amounts close to 15 BTC, which
> would lead them to address AliceB. We can beat this amount correlation
> attack by creating multi-transaction CoinSwaps. For example:
>
>     AliceA (15 BTC) ----> CoinSwap AddressA ----> BobA (15 BTC)
>
>     BobB (7 BTC) ----> CoinSwap AddressB ----> AliceB (7 BTC)
>     BobC (5 BTC) ----> CoinSwap AddressC ----> AliceC (5 BTC)
>     BobD (3 BTC) ----> CoinSwap AddressD ----> AliceD (3 BTC)
>
> Now in the multi-transaction CoinSwap, the market taker Alice has given
> 10 BTC and got back three transactions which add up to the same amount,
> but nowhere on the blockchain is there an output where Alice received
> exactly 15 BTC.
>
> === Routing CoinSwaps to avoid a single points of trust ===
>
> In the original CoinSwap idea there are only two parties Alice and Bob,
> so when they CoinSwap Bob will know exactly where the Alice's coins
> went. This means Bob is a single point of failure in Alice's privacy,
> and Alice must trust him not to spy on her.
>
> To spread out and decentralize the trust, we can create CoinSwaps where
> Alice's payment is routed through many Bobs.
>
>     AliceA ====> Bob ====> Charlie ====> Dennis ====> AliceB
>
> Where the symbol ====> means one CoinSwap. In this situation Alice will
> be a market taker in the liquidity market, and all the other entities
> (Bob, Charlie, Dennis) will be market makers. Only Alice will know the
> entire route, and the makers will only know the previous and next
> bitcoin addresses along the route.
>
> This could be made to work by Alice handling almost everything about the
> CoinSwap on the other maker's behalf. The makers wouldn't have TCP
> connections between each other, but only to Alice, and she would relay
> CoinSwap-relevant information between them. The other makers are not
> aware whether their incoming coins came from Alice herself or the
> previous maker in Alice's route.
>
>
> === Combining multi-transaction with routing ===
>
> Routing and multi-transaction must be combined to get both benefits. If
> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
> easy with this configuration:
>
>              Alice
>     (6 BTC) (8 BTC) (1 BTC)
>        |       |       |
>        |       |       |
>        v       v       v
>               Bob
>     (5 BTC) (5 BTC) (5 BTC)
>        |       |       |
>        |       |       |
>        v       v       v
>             Charlie
>     (9 BTC) (5 BTC) (1 BTC)
>        |       |       |
>        |       |       |
>        v       v       v
>             Dennis
>     (7 BTC) (4 BTC) (4 BTC)
>        |       |       |
>        |       |       |
>        v       v       v
>              Alice
>
> Where the downward arrow symbol is a single CoinSwap hash-time-locked
> contract. Each hop uses multiple transactions so no maker (Bob, Charlie,
> Dennis) is able to use amount correlation to find addresses not directly
> related to them, but at each hop the total value adds up to the same
> amount 15 BTC. And all 3 makers must collude in order to track the
> source and destination of the bitcoins.
>
> If Alice starts with only a single UTXO then the above configuration is
> still vulnerable to amount correlation. One of the later makers (e.g.
> Dennis) knows that the total coinswap amount is 15 BTC, and could search
> the blockchain to find Alice's single UTXO. In such a situation Alice
> must use a branching configuration:
>
>                           Alice
>                          (15 BTC)
>                             |
>                             |
>                             v
>                            Bob
>                           /   \
>                          /     \
>              <-----------       ----------->
>              |                             |
>   (2 BTC) (2 BTC) (2 BTC)        (3 BTC) (3 BTC) (3 BTC)
>              |                             |
>              |                             |
>              v                             v
>           Charlie                       Dennis
>   (1 BTC) (2 BTC) (3 BTC)       (5 BTC) (3 BTC) (1 BTC)
>      |       |       |             |       |       |
>      |       |       |             |       |       |
>      v       v       v             v       v       v
>           Edward                          Fred
>   (4 BTC) (1 BTC) (1 BTC)       (4 BTC) (2 BTC) (1 BTC)
>      |       |       |             |       |       |
>      |       |       |             |       |       |
>      v       v       v             v       v       v
>            Alice                         Alice
>
> In this diagram, Alice sends 15 BTC to Bob via CoinSwap who sends 6 BTC
> on to Charlie and the remaining 9 BTC to Dennis. Charlie and Dennis do a
> CoinSwap with Edward and Fred who forward the coins to Alice. None of
> the makers except Bob know the full 15 BTC amount and so can't search
> the blockchain backwards for Alice's initial UTXO. Because of multiple
> transactions Bob cannot look forward to search for the amounts he sent 6
> BTC and 9 BTC. A minimum of 3 makers in this example need to collude to
> know the source and destination of the coins.
>
> Another configuration is branch merging, which Alice would find useful
> if she has two or more UTXOs for which there must not be evidence that
> they're owned by the same entity, and so they must not be spent together
> in the same transaction.
>
>            Alice                         Alice
>           (9 BTC)                       (6 BTC)
>              |                             |
>              |                             |
>              v                             v
>             Bob                         Charlie
>   (4 BTC) (3 BTC) (2 BTC)       (1 BTC) (2 BTC) (3 BTC)
>      |       |       |             |       |       |
>      |       |       |             |       |       |
>       \       \       \           /       /       /
>        \       \       \         /       /       /
>         \       \       \       /       /       /
>          >------->-------\     /-------<-------<
>                           \   /
>                           Alice
>                          (15 BTC)
>
> In this diagram Alice sends the two UTXOs (9 BTC and 6 BTC) to two
> different makers, who forward it onto Alice. Because the two UTXOs have
> been transferred to different makers they will likely never be co-spent.
>
> These complex multi-transaction routed coinswaps are only for the
> highest threat models where the makers themselves are adversaries. In
> practice most users would probably choose to use just one or two hops.
>
>
> === Breaking change output and wallet fingerprinting heuristics ===
>
> Equal-output CoinJoins easily leak change addresses (unless they are
> sweeps with no change). CoinSwap doesn't have this flaw which allows us
> to break some of the weaker change output heuristics[3].
>
> For example address reuse. If an output address has been reused it is
> very likely to be a payment output, not a change output. In a CoinSwap
> application we can break this heuristic by having makers randomly with
> some probability send their change to an address they've used before.
> That will make the heuristics think that the real change address is
> actually the payment address, and the real payment is actually the
> change, and could result in an analyzer of the blockchain grouping the
> payment address inside the maker's own wallet cluster.
>
> Another great heuristic to break is the script type heuristic. If the
> maker's input are all in p2sh-p2wpkh addresses, and their payment
> address is also of type p2sh-p2wpkh, then the maker could with some
> probability set the change address to a different type such as p2wpkh.
> This could trick a chain analyzer in a similar way.
>
> === Fidelity bonds ===
>
> Anybody can enter the CoinSwap market as a maker, so there is a danger
> of sybil attacks. This is when an adversary deploys huge numbers of
> maker bots. If the taker Alice chooses maker bots which are all
> controlled by the same person then that person can deanonymize Alice's
> transaction by tracking the coins along the route.
>
> A solution to this is fidelity bonds. This is a mechanism where bitcoin
> value is deliberately sacrificed to make a cryptographic identity
> expensive to obtain. The sacrifice is done in a way that can be proven
> to a third party. One way to create a fidelity bond is to lock up
> bitcoins in a time-locked address. We can code the taker bots to behave
> in a way that creates market pressure for maker bot operators to publish
> fidelity bonds. These fidelity bonds can be created anonymously by
> anyone who owns bitcoin.
>
> Fidelity bonds are a genuine sacrifice which can't be faked, they can be
> compared to proof-of-work which backs bitcoin mining. Then for a sybil
> attacker to be successful they would have to lock up a huge value in
> bitcoin for a long time. I've previously analyzed fidelity bonds for
> JoinMarket[4], and using realistic numbers I calculate that such a
> system would require about 55000 BTC (around 500 million USD at today's
> price) to be locked up for 6 months in time-locked addresses. This is a
> huge amount and provides strong sybil resistance.
>
> ==== Who goes first ====
>
> Fidelity bonds also solve the "who goes first" problem in CoinSwap.
>
> This problem happens because either Alice or Bob must broadcast their
> funding transaction first, but if the other side halts the protocol then
> they can cause Alice or Bob's to waste time and miner fees as they're
> forced to use the contract transactions to get their money back. This is
> a DOS attack. If a malicious CoinSwapper could keep halting the protocol
> they could stop an honest user from doing a CoinSwap indefinitely.
> Fidelity bonds solve this by having the fidelity bond holder go second.
> If the fidelity bond holder halts the protocol then their fidelity bond
> can be avoid by the user in all later CoinSwaps. And the malicious
> CoinSwapper could pack the orderbook with their sybils without
> sacrificing a lot of value for fidelity bonds.
>
> As a concrete example, Alice is a taker and Bob is a maker. Bob
> publishes a fidelity bond. Alice "goes first" by sending her coins into
> a 2-of-2 multisig between her and Bob. When Bob sees the transaction is
> confirmed he broadcasts his own transactions into another 2-of-2
> multisig. If Bob is actually malicious and halts the protocol then he
> will cost Alice some time and money, but Alice will refuse to ever
> CoinSwap with Bob's fidelity bond again.
>
> If DOS becomes a big problem even with fidelity bonds, then its possible
> to have Alice request a "DOS proof" from Bob before broadcasting, which
> is a set of data containing transactions, merkle proofs and signatures
> which are a contract where Bob promises to broadcast his own transaction
> if Alice does so first. If Alice gets DOSed then she can share this DOS
> proof publicly. The proof will have enough information to convince
> anyone else that the DOS really happened, and it means that nobody else
> will ever CoinSwap with Bob's fidelity bond either (or at least assign
> some kind of ban score to lower the probability). I doubt it will come
> to this so I haven't expanded the idea much, but theres a longer writeup
> in the reference[5].
>
> === Private key handover ===
>
> The original proposal for CoinSwap involved four transactions. Two to
> pay into the multisig addresses and two to pay out. We can do better
> than this with private key handover[6]. This is an observation that once
> the CoinSwap preimage is revealed, Alice and Bob don't have to sign each
> other's multisig spend, instead they could hand over their private key
> to the other party. The other party will know both keys of the 2-of-2
> multisig and therefore have unilateral control of the coins. Although
> they would still need to watch the chain and respond in case a
> hash-time-locked contract transaction is broadcasted.
>
> As well as saving block space, it also improves privacy because the
> coins could stay unspent for a long time, potentially indefinitely.
> While in the original coinswap proposal an analyst of the chain would
> always see a funding transaction followed closely in time by a
> settlement transaction, and this could be used as a fingerprint.
>
> We can go even further than private key handover using a scheme called
> SAS: Succinct Atomic Swap[7]. This scheme uses adapter signatures[8] to
> create a similar outcome to CoinSwap-with-private-key-handover, but only
> one party in the CoinSwap must watch and respond to blockchain events
> until they spend the coin. The other party just gets unilateral control
> of their coins without needing to watch and respond.
>
>
> === PayJoin with CoinSwap ===
>
> CoinSwap can be combined with CoinJoin. In original CoinSwap, Alice
> might pay into a CoinSwap address with a regular transaction spending
> multiple of her own inputs:
>
>     AliceInputA (1 BTC) ----> CoinSwap Address (3 BTC)
>     AliceInputB (2 BTC)
>
> This leaks information that all of those inputs are owned by the same
> person. We can make this example transaction a CoinJoin by involving
> Bob's inputs too. CoinJoin requires interaction but because Alice and
> Bob are already interacting to follow the CoinSwap protocol, so it's not
> too hard to have them interact a bit more to do a CoinJoin too. The
> CoinJoin transaction which funds the CoinSwap address would look like this:
>
>     AliceInputA (1 BTC) ----> CoinSwap Address (7 BTC)
>     AliceInputB (2 BTC)
>     BobInputA   (4 BTC)
>
> Alice's and Bob's inputs are both spent in a same transaction, which
> breaks the common-input-ownership heuristic. This form of CoinJoin is
> most similar to the PayJoin protocol or CoinJoinXT protocol. As with the
> rest of this design, this protocol does not have any special patterns
> and so is indistinguishable from any regular bitcoin transaction.
>
> To make this work Bob the maker needs to provide two unrelated UTXOs,
> one that is CoinSwapped and the other CoinJoined.
>
> ==== Using decoy UTXOs to protecting from leaks ====
>
> If Bob the maker was just handing out inputs for CoinJoins to any Alice
> who asked, then malicious Alice's could constantly poll Bob to learn his
> UTXO and then halt the protocol. Malicious Alice could learn all of
> Bob's UTXOs and easily unmix future CoinSwaps by watching their future
> spends.
>
> To defend against this attack we have Bob maintain a list of "decoy
> UTXOs", which are UTXOs that Bob found by scanning recent blocks. Then
> when creating the CoinJoin, Bob doesn't just send his own input but
> sends perhaps 50 or 100 other inputs which don't belong to him. For the
> protocol to continue Alice must partially-sign many CoinJoin
> transactions; one for each of those inputs, and send them back to Bob.
> Then Bob can sign the transaction which contains his genuine input and
> broadcast it. If Alice is actually a malicious spy she won't learn Bob's
> input for sure but will only know 100 other inputs, the majority of
> which have nothing to do with Bob. By the time malicious Alice learns
> Bob's true UTXO its already too late because its been spent and Alice is
> locked into the CoinSwap protocol, requiring time, miner fees and
> CoinSwap fees to get out.
>
> This method of decoy UTXOs has already been written about in the
> original PayJoin designs from 2018[9][10].
>
> === Creating a communication network using federated message boards ===
>
> Right now JoinMarket uses public IRC networks for communication. This is
> subpar for a number of reasons, and we can do better.
>
> I propose that there be a small number of volunteer-operated HTTP
> servers run on Tor hidden services. Their URLs are included in the
> CoinSwap software by default. They can be called message board servers.
> Makers are also servers run on hidden services, and to advertise
> themselves they connect to these message board servers to post the
> makers own .onion address. To protect from spam, makers must provide a
> fidelity bond before being allowed to write to the HTTP server.
>
> Takers connect to all these HTTP message boards and download the list of
> all known maker .onion addresses. They connect to each maker's onion to
> obtain parameters like offered coinswap fee and maximum coinswap size.
> This is equivalent to downloading the orderbook on JoinMarket. Once
> takers have chosen which makers they'll do a CoinSwap with, they
> communicate with those maker again directly through their .onion address
> to transmit the data needed to create CoinSwaps.
>
> These HTTP message board servers can be run quite cheaply, which is
> required as they'd be volunteer run. They shouldn't require much
> bandwidth or disk space, as they are well-protected from spam with the
> fidelity bond requirement. The system can also tolerate temporary
> downtimes so the servers don't need to be too reliable either. It's easy
> to imagine the volunteers running them on a raspberry pi in their own
> home. These message board servers are similar in some ways to the DNS
> seeds used by Bitcoin Core to find its first peers on bitcoin's p2p
> network. If the volunteers ever lose interest or disappear, then the
> community of users could find new volunteer operators and add those URLs
> to the default list.
>
> In order to censor a maker, _all_ the message board servers would have
> to co-operate to censor him. If censorship is happening on a large scale
> (for example if the message board servers only display sybil makers run
> by themselves) then takers could also notice a drop in the total value
> of all fidelity bonds.
>
>
> == How are CoinSwap and Lightning Network different? ==
>
> CoinSwap and Lightning Network have many similarities, so it's natural
> to ask why are they different, and why do we need a CoinSwap system at
> all if we already have Lightning?
>
> === CoinSwap can be adopted unilaterally and is on-chain ===
>
> Today we see some centralized exchange not supporting so-called
> ``privacy altcoins'' because of regulatory compliance concerns. We also
> see some exchanges frowning upon or blocking CoinJoin transaction they
> detect[11]. (There is some debate over whether the exchanges really
> blocked transactions because they were CoinJoin, but the principle
> remains that equal-output CoinJoins are inherently visible as such).
> It's possible that those exchanges will never adopt Lightning because of
> its privacy features.
>
> Such a refusal would simply not be possible with CoinSwap, because it is
> fundamentally an on-chain technology. CoinSwap users pay to bitcoin
> addresses, not Lightning invoices. Anybody who accepts bitcoin today
> will accept CoinSwap. And because CoinSwap transactions can be made
> indistinguishable from regular transactions, it would be very difficult
> to even determine whether they got paid via a CoinSwap or not. So
> CoinSwap is not a replacement for Lightning, instead it is a replacement
> for on-chain privacy technology such as equal-output CoinJoins which are
> implemented today in JoinMarket, Wasabi Wallet and Samourai Wallet.
> Ideally this design, if implemented, would be possible to include into
> the many already-existing bitcoin wallets, and so the CoinSwaps would be
> accessible to everyone.
>
> This feature of CoinSwap will in turn help Lightning Network, because
> those censoring exchanges won't be able to stop transactions with
> undetectable privacy no matter what they do. When they realize this
> they'll likely just implement Lightning Network anyway regardless of the
> privacy.
>
> Bitcoin needs on-chain privacy as well, otherwise the bad privacy can
> leak into layer-2 solutions.
>
> === Different ways of solving liquidity ===
>
> Lightning Network cannot support large payment amounts. Liquidity in
> payment channels on the Lightning network is a scarce resource. Nodes
> which relay lightning payments always take care that a payment does not
> exhaust their liquidity. Users of Lightning today must often be aware of
> inbound liquidity, outbound liquidity and channel rebalancing. There
> even exist services today which sell Lightning liquidity.
>
> This CoinSwap design solves its liquidity problem in a completely
> different way. Because of the liquidity market similar to JoinMarket,
> all the required liquidity is always available. There are never any
> concerns about exhausting channel capacity or a route not being found,
> because such liquidity is simply purchased from the liquidity market
> right before it is used.
>
> It is still early days for Lightning, and liquidity has been a known
> issue since the start. Many people are confident that the liquidity
> issue will be improved. Yet it seems hard to imagine that Lightning
> Network will ever reliably route payments of 200 BTC to any node in the
> network (and it doesn't have to to be successful), yet on JoinMarket
> today as I write these words there are offers to create CoinJoins with
> amounts up to around 200 BTC. We can expect similar large amounts to be
> sendable in CoinSwap. The liquidity market as a solution is known to
> work and has been working for years.
>
> === Sybil resistance ===
>
> CoinSwap can support fidelity bonds and so can be made much more
> resistant to sybil attacks. We saw in the earlier section that realistic
> numbers from JoinMarket imply a sybil attacker would have to lock up
> hundreds of millions of USD worth of bitcoin to successfully deanonymize
> users.
>
> It's difficult to compare this to the cost of a sybil attack in
> Lightning network as such attacks are hard to analyze. For example, the
> attacker needs to convince users to route payments through the
> attacker's own nodes, and maybe they could do this, but putting numbers
> on it is hard. Even so it is very likely that the true cost is much less
> than 500 million USD locked up for months because Lightning nodes can be
> set up for not more than the cost of hardware and payment channel
> capacity, while CoinSwap makers would require expensive fidelity bond
> sacrifices.
>
> As this CoinSwap design would cost much more sybil attack, its privacy
> would be much greater in this respect.
>
>
> == How are CoinSwap, PayJoin and PaySwap different? ==
>
> PayJoin can also be indistinguishable from regular bitcoin transaction,
> so why don't we all just that and not go further?
>
> The answer is the threat models. PayJoin works by having the customer
> and merchant together co-operate to increase both their privacy. It
> works if the adversary of both of them is a passive observer of the
> blockchain.
>
> PayJoin doesnt help a customer at all if the user's adversary is the
> merchant. This situation happens all the time today, for example
> exchanges spying on their customers. CoinSwap can help in this
> situation, as it doesn't assume or require that the second party is your
> friend. The same argument applies to PaySwap.
>
> Obviously PayJoin and PaySwap are still very useful, but they operate
> under different threat models.
>
>
> == Conclusion ==
>
> CoinSwap is a promising privacy protocol because it breaks the
> transaction graph heuristic, but it cant work on its own. In order to
> create a truly private system of sending transactions which would
> improve bitcoin's fungibility, CoinSwap must be combined with a couple
> of other building blocks:
>
> * ECDSA-2P
> * Liquidity market
> * Routed CoinSwaps
> * Multi-transaction CoinSwaps
> * Breaking change output heuristics
> * Fidelity bonds
> * PayJoin with CoinSwap
> * Federated message boards protected from spam with fidelity bonds
>
> CoinSwap transactions could be made to look just like any other regular
> bitcoin transaction, with no distinguishing fingerprint. This would make
> them invisible.
>
> I intend to create this CoinSwap software. It will be almost completely
> decentralized and available for all to use for free. The design is
> published here for review. If you want to help support development I
> accept donations at https://bitcoinprivacy.me/coinswap-donations
>
>
> == References ==
>
> - [1] "CoinSwap: Transaction graph disjoint trustless trading"
> https://bitcointalk.org/index.php?topic=321228.0
>
> - [2]
>
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/
>
> - [3] https://en.bitcoin.it/wiki/Privacy#Change_address_detection
>
> - [4] "Design for improving JoinMarket's resistance to sybil attacks
> using fidelity bonds"
> https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/
>
> - [5] https://github.com/AdamISZ/CoinSwapCS/issues/50
>
> - [6] https://github.com/AdamISZ/CoinSwapCS/issues/53
>
> - [7]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html
>
> - [8]
>
> https://github.com/ElementsProject/scriptless-scripts/blob/master/md/atomic-swap.md
>
> - [9]
>
> https://blockstream.com/2018/08/08/en-improving-privacy-using-pay-to-endpoint/
>
> - [10] https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6
>
> - [11]
>
> https://cointelegraph.com/news/binance-returns-frozen-btc-after-user-promises-not-to-use-coinjoin
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000007e238e05a6dfa8a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Chris,<div><br></div><div>Excellent write-up. I learne=
d a few new things while reading this (particularly how to overcome the heu=
ristics for address reuse and address types), so thank you for that.</div><=
div><br></div><div>I have a few thoughts about how what=C2=A0you wrote rela=
tes to=20

Succinct Atomic Swaps (SAS)[0]. Perhaps it&#39;s useful.</div><div><br></di=
v><div>&gt;For a much greater anonymity set we can use 2-party ECDSA to cre=
ate 2-of-2 multisignature addresses that look the same as regular single-si=
gnature addresses</div><div><br></div><div>This may perhaps be counter-intu=
itive, but SAS doesn&#39;t actually require multisig for one of the two out=
puts, so a single key will suffice. ECDSA is a signing algorithm that doesn=
&#39;t support single key multisig (at least not without 2p-ECDSA), but not=
ice how for the non-timelocked SAS output we never actually have to sign an=
ything together with the other party. We swap one of the two keys, and the =
final owner will create a signature completely on their own. No multisig re=
quired, which means we can simply use MuSig, even today without Schnorr.</d=
iv><div><br></div><div>Of course the other output will still have to be a 2=
-of-2, for which you rightly note 2p-ECDSA could be considered. It may also=
 be interesting to combine a swap with the opening of a Lightning channel. =
E.g. Alice and Bob want to open a channel with 1 BTC each, but Alice funds =
it in her entirety with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This=
 makes it difficult to tell Bob entered the Lightning Network, especially i=
f the channel is opened in a state that isn&#39;t perfectly balanced. And A=
lice will gain an uncorrelated single key output.</div><div><br></div><div>=
As a side note, we could use the same MuSig observation on 2-of-2 outputs t=
hat need multisig by turning the script into (A &amp; B) OR MuSig(A,B), whi=
ch would shave off quite a few bytes by allowing single sig spending once t=
he private key is handed over, but this would also make the output stick ou=
t like a sore thumb... Only useful if privacy is not a concern.</div><div><=
br></div><div>&gt;=3D=3D=3D Multi-transaction CoinSwaps to avoid amount cor=
relation =3D=3D=3D</div><div><br></div><div>This can apply cleanly to SAS, =
and can even be done without passing on any extra secrets by generating a s=
haredSecret (Diffie-Hellman key exchange).</div><div><br></div><div>Non-tim=
elocked:</div><div>CoinSwap AddressB =3D aliceSecret=C2=A0+ bobSecret=C2=A0=
</div><div>CoinSwap AddressC =3D aliceSecret=C2=A0+ bobSecret=C2=A0+ hash(s=
haredSecret,0)*G</div><div>CoinSwap AddressD=C2=A0

 =3D aliceSecret=C2=A0+ bobSecret + hash(sharedSecret,1)*G=C2=A0</div><div>=
<br></div><div>The above is MuSig compatible (single key outputs), there ar=
e no timelocks to worry about, and the addresses cannot be linked on-chain.=
</div><div><br></div><div>&gt;they would still need to watch the chain and =
respond in case a hash-time-locked contract transaction is broadcasted</div=
><div><br></div><div>Small detail, but it should be noted that this would r=
equire the atomic swap to be set up in a specific way with relative timeloc=
ks.</div><div><br></div><div>&gt;=3D=3D=3D PayJoin with CoinSwap =3D=3D=3D<=
/div><div><br></div><div>While it&#39;s probably clear how to do it on the =
timelocked side of SAS, I believe PayJoin can also be applied to the non-ti=
melocked side. This does require adding a transaction that undoes the PayJo=
in in case the swap gets aborted, which means MuSig can&#39;t be used. Ever=
ything else stays the same: only one tx if successful, and no timelock (=3D=
 instant settlement). I can explain it in detail, if it happens to catch yo=
ur interest.</div><div><br></div><div>Cheers,</div><div>Ruben</div><div><br=
></div><div><br></div><div>[0]=C2=A0

Succinct Atomic Swaps (SAS)=C2=A0=C2=A0<a href=3D"https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2020-May/017846.html" rel=3D"noreferrer" tar=
get=3D"_blank">https://lists.linuxfoundation.org/pipermail/<span class=3D"g=
mail-il">bitcoin</span>-<span class=3D"gmail-il">dev</span>/2020-May/017846=
.html</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, May 25, 2020 at 3:21 PM Chris Belcher via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">=3D=3D=3D Abstract =3D=3D=3D<br>
<br>
Imagine a future where a user Alice has bitcoins and wants to send them<br>
with maximal privacy, so she creates a special kind of transaction. For<br>
anyone looking at the blockchain her transaction appears completely<br>
normal with her coins seemingly going from address A to address B. But<br>
in reality her coins end up in address Z which is entirely unconnected<br>
to either A or B.<br>
<br>
Now imagine another user, Carol, who isn&#39;t too bothered by privacy and<=
br>
sends her bitcoin using a regular wallet which exists today. But because<br=
>
Carol&#39;s transaction looks exactly the same as Alice&#39;s, anybody anal=
yzing<br>
the blockchain must now deal with the possibility that Carol&#39;s<br>
transaction actually sent her coins to a totally unconnected address. So<br=
>
Carol&#39;s privacy is improved even though she didn&#39;t change her behav=
iour,<br>
and perhaps had never even heard of this software.<br>
<br>
In a world where advertisers, social media and other companies want to<br>
collect all of Alice&#39;s and Carol&#39;s data, such privacy improvement w=
ould<br>
be incredibly valuable. And also the doubt added to every transaction<br>
would greatly boost the fungibility of bitcoin and so make it a better<br>
form of money.<br>
<br>
This undetectable privacy can be developed today by implementing<br>
CoinSwap, although by itself that isn&#39;t enough. There must be many<br>
building blocks which together make a good system. The software could be<br=
>
standalone as a kind of bitcoin mixing app, but it could also be a<br>
library that existing wallets can implement allowing their users to send<br=
>
Bitcoin transactions with much greater privacy.<br>
<br>
=3D=3D CoinSwap =3D=3D<br>
<br>
Like CoinJoin, CoinSwap was invented in 2013 by Greg Maxwell[1]. Unlike<br>
CoinJoin it is relatively complicated to implement and so far has not<br>
been deployed. But the idea holds great promise, and fixes many of the<br>
problems of some kinds of CoinJoins. CoinSwap is the next step for<br>
on-chain bitcoin privacy.<br>
<br>
CoinSwap is a way of trading one coin for another coin in a<br>
non-custodial way. It is closely related to the idea of an atomic swap.<br>
Alice and Bob can trade coins with each other by first sending to a<br>
CoinSwap address and having those coins then sent to Bob:<br>
<br>
=C2=A0 =C2=A0 Alice&#39;s Address 1 ----&gt; CoinSwap Address 1 ----&gt; Bo=
b&#39;s Address 1<br>
<br>
An entirely separate set of transactions gives Bob&#39;s coins to Alice in<=
br>
return:<br>
<br>
=C2=A0 =C2=A0 Bob&#39;s Address 2 ----&gt; CoinSwap Address 2 ----&gt; Alic=
e&#39;s Address 2<br>
<br>
Where the symbol ----&gt; is a bitcoin transaction.<br>
<br>
Privacy is improved because an observer of the blockchain cannot link<br>
Alice&#39;s Address 1 to Alice&#39;s Address 2, as there is no transaction<=
br>
between them. Alice&#39;s Address 2 could either be an address in Alice&#39=
;s<br>
wallet, or the address of someone else she wants to transfer money to.<br>
CoinSwap therefore breaks the transaction graph heuristic, which is the<br>
assumption that if a transaction A -&gt; B is seen then the ownership of<br=
>
funds actually went from A to B.<br>
<br>
CoinSwap doesnt break any of bitcoin&#39;s assumptions or features like an<=
br>
auditable supply or pruning. It can be built on today&#39;s bitcoin without=
<br>
any new soft forks.<br>
<br>
CoinSwap can&#39;t improve privacy much on its own, so it requires other<br=
>
building block to create a truly private system.<br>
<br>
=3D=3D=3D ECDSA-2P =3D=3D=3D<br>
<br>
The original CoinSwap idea uses 2-of-2 multisig. We can get a slightly<br>
bigger anonymity set by using 2-of-3 multisigs with a fake third public<br>
key. For a much greater anonymity set we can use 2-party ECDSA to create<br=
>
2-of-2 multisignature addresses that look the same as regular<br>
single-signature addresses[2]. Even the old-style p2pkh addresses<br>
starting with 1 can be CoinSwap addresses.<br>
<br>
Because the transactions blend in with the rest of bitcoin, an<br>
application based on CoinSwap would provide much more privacy than the<br>
existing equal-output coinjoin apps (JoinMarket, Wasabi Wallet and<br>
Samourai Wallet&#39;s Whirlpool). CoinSwaps would also be cheaper for the<b=
r>
same amount of privacy, as CoinJoin users usually create multiple<br>
CoinJoins to get effective privacy, for example JoinMarket&#39;s tumbler<br=
>
script does between 7-12 coinjoins (which are bigger than regular<br>
transactions too) when run with default parameters.<br>
<br>
Schnorr signatures with Musig provide a much easier way to create<br>
invisible 2-of-2 multisig, but it is not as suitable for CoinSwap. This<br>
is because the anonymity set for ECDSA would be much greater. All<br>
addresses today are ECDSA, and none are schnorr. We&#39;d have to wait for<=
br>
schnorr to be added to bitcoin and then wait for users to adopt it. We<br>
see with segwit that even after nearly 3 years that segwit adoption is<br>
only about 60%, and segwit actually has a sizeable financial incentive<br>
for adoption via lower fees. Schnorr when used for single-sig doesn&#39;t<b=
r>
have such an incentive, as Schnorr single-sig costs the same size as<br>
today&#39;s p2wpkh, so we can expect adoption to be even slower. (Of course=
<br>
there is an incentive for multisig transactions, but most transactions<br>
are single-sig). As schnorr adoption increases this CoinSwap system<br>
could start to use it, but for a long time I suspect it will mostly be<br>
using ECDSA for a greater anonymity set.<br>
<br>
=3D=3D=3D Liquidity market =3D=3D=3D<br>
<br>
We can create a liquidity market for CoinSwap very similar to how<br>
JoinMarket works for CoinJoins. In our example above Alice would be a<br>
market taker and Bob would be a market maker. The taker Alice pays a fee<br=
>
to the maker Bob in return for choosing the amount of a CoinSwap and<br>
when it happens. This allows an excellent user experience because Alice<br>
can create CoinSwaps for any size she wants, at any time she wants.<br>
Right now in JoinMarket there is liquidity to create CoinJoins of sizes<br>
up to about 200 BTC, and we can expect a similar kind of thing with<br>
CoinSwap.<br>
<br>
<br>
=3D=3D=3D Multi-transaction CoinSwaps to avoid amount correlation =3D=3D=3D=
<br>
<br>
This CoinSwap is vulnerable to amount correlation:<br>
<br>
=C2=A0 =C2=A0 AliceA (15 BTC) ----&gt; CoinSwap AddressA ----&gt; BobA (15 =
BTC)<br>
=C2=A0 =C2=A0 BobB (15 BTC) ----&gt; CoinSwap AddressB ----&gt; AliceB (15 =
BTC)<br>
<br>
Where AliceA, AliceB are addresses belonging to Alice. BobA, BobB are<br>
addresses belonging to Bob. If an adversary starts tracking at address<br>
AliceA they could unmix this CoinSwap easily by searching the entire<br>
blockchain for other transactions with amounts close to 15 BTC, which<br>
would lead them to address AliceB. We can beat this amount correlation<br>
attack by creating multi-transaction CoinSwaps. For example:<br>
<br>
=C2=A0 =C2=A0 AliceA (15 BTC) ----&gt; CoinSwap AddressA ----&gt; BobA (15 =
BTC)<br>
<br>
=C2=A0 =C2=A0 BobB (7 BTC) ----&gt; CoinSwap AddressB ----&gt; AliceB (7 BT=
C)<br>
=C2=A0 =C2=A0 BobC (5 BTC) ----&gt; CoinSwap AddressC ----&gt; AliceC (5 BT=
C)<br>
=C2=A0 =C2=A0 BobD (3 BTC) ----&gt; CoinSwap AddressD ----&gt; AliceD (3 BT=
C)<br>
<br>
Now in the multi-transaction CoinSwap, the market taker Alice has given<br>
10 BTC and got back three transactions which add up to the same amount,<br>
but nowhere on the blockchain is there an output where Alice received<br>
exactly 15 BTC.<br>
<br>
=3D=3D=3D Routing CoinSwaps to avoid a single points of trust =3D=3D=3D<br>
<br>
In the original CoinSwap idea there are only two parties Alice and Bob,<br>
so when they CoinSwap Bob will know exactly where the Alice&#39;s coins<br>
went. This means Bob is a single point of failure in Alice&#39;s privacy,<b=
r>
and Alice must trust him not to spy on her.<br>
<br>
To spread out and decentralize the trust, we can create CoinSwaps where<br>
Alice&#39;s payment is routed through many Bobs.<br>
<br>
=C2=A0 =C2=A0 AliceA =3D=3D=3D=3D&gt; Bob =3D=3D=3D=3D&gt; Charlie =3D=3D=
=3D=3D&gt; Dennis =3D=3D=3D=3D&gt; AliceB<br>
<br>
Where the symbol =3D=3D=3D=3D&gt; means one CoinSwap. In this situation Ali=
ce will<br>
be a market taker in the liquidity market, and all the other entities<br>
(Bob, Charlie, Dennis) will be market makers. Only Alice will know the<br>
entire route, and the makers will only know the previous and next<br>
bitcoin addresses along the route.<br>
<br>
This could be made to work by Alice handling almost everything about the<br=
>
CoinSwap on the other maker&#39;s behalf. The makers wouldn&#39;t have TCP<=
br>
connections between each other, but only to Alice, and she would relay<br>
CoinSwap-relevant information between them. The other makers are not<br>
aware whether their incoming coins came from Alice herself or the<br>
previous maker in Alice&#39;s route.<br>
<br>
<br>
=3D=3D=3D Combining multi-transaction with routing =3D=3D=3D<br>
<br>
Routing and multi-transaction must be combined to get both benefits. If<br>
Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is<br=
>
easy with this configuration:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alice<br>
=C2=A0 =C2=A0 (6 BTC) (8 BTC) (1 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=
=A0 =C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob<br>
=C2=A0 =C2=A0 (5 BTC) (5 BTC) (5 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=
=A0 =C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Charlie<br>
=C2=A0 =C2=A0 (9 BTC) (5 BTC) (1 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=
=A0 =C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dennis<br>
=C2=A0 =C2=A0 (7 BTC) (4 BTC) (4 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=
=A0 =C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alice<br>
<br>
Where the downward arrow symbol is a single CoinSwap hash-time-locked<br>
contract. Each hop uses multiple transactions so no maker (Bob, Charlie,<br=
>
Dennis) is able to use amount correlation to find addresses not directly<br=
>
related to them, but at each hop the total value adds up to the same<br>
amount 15 BTC. And all 3 makers must collude in order to track the<br>
source and destination of the bitcoins.<br>
<br>
If Alice starts with only a single UTXO then the above configuration is<br>
still vulnerable to amount correlation. One of the later makers (e.g.<br>
Dennis) knows that the total coinswap amount is 15 BTC, and could search<br=
>
the blockchain to find Alice&#39;s single UTXO. In such a situation Alice<b=
r>
must use a branching configuration:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Alice<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0(15 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Bob<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0\<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;-----------=C2=A0 =C2=
=A0 =C2=A0 =C2=A0-----------&gt;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|<br>
=C2=A0 (2 BTC) (2 BTC) (2 BTC)=C2=A0 =C2=A0 =C2=A0 =C2=A0 (3 BTC) (3 BTC) (=
3 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Charlie=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dennis<br>
=C2=A0 (1 BTC) (2 BTC) (3 BTC)=C2=A0 =C2=A0 =C2=A0 =C2=A0(5 BTC) (3 BTC) (1=
 BTC)<br>
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=
=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =
=C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Edward=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fred<br>
=C2=A0 (4 BTC) (1 BTC) (1 BTC)=C2=A0 =C2=A0 =C2=A0 =C2=A0(4 BTC) (2 BTC) (1=
 BTC)<br>
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=
=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =
=C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alice=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alice<br>
<br>
In this diagram, Alice sends 15 BTC to Bob via CoinSwap who sends 6 BTC<br>
on to Charlie and the remaining 9 BTC to Dennis. Charlie and Dennis do a<br=
>
CoinSwap with Edward and Fred who forward the coins to Alice. None of<br>
the makers except Bob know the full 15 BTC amount and so can&#39;t search<b=
r>
the blockchain backwards for Alice&#39;s initial UTXO. Because of multiple<=
br>
transactions Bob cannot look forward to search for the amounts he sent 6<br=
>
BTC and 9 BTC. A minimum of 3 makers in this example need to collude to<br>
know the source and destination of the coins.<br>
<br>
Another configuration is branch merging, which Alice would find useful<br>
if she has two or more UTXOs for which there must not be evidence that<br>
they&#39;re owned by the same entity, and so they must not be spent togethe=
r<br>
in the same transaction.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alice=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alice<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (9 BTC)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(6 BTC)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Charlie<br>
=C2=A0 (4 BTC) (3 BTC) (2 BTC)=C2=A0 =C2=A0 =C2=A0 =C2=A0(1 BTC) (2 BTC) (3=
 BTC)<br>
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 \=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=
=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/=
=C2=A0 =C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=
=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/=
=C2=A0 =C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 \=C2=A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=
=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =
=C2=A0 =C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;-------&gt;-------\=C2=A0 =C2=A0 =C2=
=A0/-------&lt;-------&lt;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 \=C2=A0 =C2=A0/<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Alice<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0(15 BTC)<br>
<br>
In this diagram Alice sends the two UTXOs (9 BTC and 6 BTC) to two<br>
different makers, who forward it onto Alice. Because the two UTXOs have<br>
been transferred to different makers they will likely never be co-spent.<br=
>
<br>
These complex multi-transaction routed coinswaps are only for the<br>
highest threat models where the makers themselves are adversaries. In<br>
practice most users would probably choose to use just one or two hops.<br>
<br>
<br>
=3D=3D=3D Breaking change output and wallet fingerprinting heuristics =3D=
=3D=3D<br>
<br>
Equal-output CoinJoins easily leak change addresses (unless they are<br>
sweeps with no change). CoinSwap doesn&#39;t have this flaw which allows us=
<br>
to break some of the weaker change output heuristics[3].<br>
<br>
For example address reuse. If an output address has been reused it is<br>
very likely to be a payment output, not a change output. In a CoinSwap<br>
application we can break this heuristic by having makers randomly with<br>
some probability send their change to an address they&#39;ve used before.<b=
r>
That will make the heuristics think that the real change address is<br>
actually the payment address, and the real payment is actually the<br>
change, and could result in an analyzer of the blockchain grouping the<br>
payment address inside the maker&#39;s own wallet cluster.<br>
<br>
Another great heuristic to break is the script type heuristic. If the<br>
maker&#39;s input are all in p2sh-p2wpkh addresses, and their payment<br>
address is also of type p2sh-p2wpkh, then the maker could with some<br>
probability set the change address to a different type such as p2wpkh.<br>
This could trick a chain analyzer in a similar way.<br>
<br>
=3D=3D=3D Fidelity bonds =3D=3D=3D<br>
<br>
Anybody can enter the CoinSwap market as a maker, so there is a danger<br>
of sybil attacks. This is when an adversary deploys huge numbers of<br>
maker bots. If the taker Alice chooses maker bots which are all<br>
controlled by the same person then that person can deanonymize Alice&#39;s<=
br>
transaction by tracking the coins along the route.<br>
<br>
A solution to this is fidelity bonds. This is a mechanism where bitcoin<br>
value is deliberately sacrificed to make a cryptographic identity<br>
expensive to obtain. The sacrifice is done in a way that can be proven<br>
to a third party. One way to create a fidelity bond is to lock up<br>
bitcoins in a time-locked address. We can code the taker bots to behave<br>
in a way that creates market pressure for maker bot operators to publish<br=
>
fidelity bonds. These fidelity bonds can be created anonymously by<br>
anyone who owns bitcoin.<br>
<br>
Fidelity bonds are a genuine sacrifice which can&#39;t be faked, they can b=
e<br>
compared to proof-of-work which backs bitcoin mining. Then for a sybil<br>
attacker to be successful they would have to lock up a huge value in<br>
bitcoin for a long time. I&#39;ve previously analyzed fidelity bonds for<br=
>
JoinMarket[4], and using realistic numbers I calculate that such a<br>
system would require about 55000 BTC (around 500 million USD at today&#39;s=
<br>
price) to be locked up for 6 months in time-locked addresses. This is a<br>
huge amount and provides strong sybil resistance.<br>
<br>
=3D=3D=3D=3D Who goes first =3D=3D=3D=3D<br>
<br>
Fidelity bonds also solve the &quot;who goes first&quot; problem in CoinSwa=
p.<br>
<br>
This problem happens because either Alice or Bob must broadcast their<br>
funding transaction first, but if the other side halts the protocol then<br=
>
they can cause Alice or Bob&#39;s to waste time and miner fees as they&#39;=
re<br>
forced to use the contract transactions to get their money back. This is<br=
>
a DOS attack. If a malicious CoinSwapper could keep halting the protocol<br=
>
they could stop an honest user from doing a CoinSwap indefinitely.<br>
Fidelity bonds solve this by having the fidelity bond holder go second.<br>
If the fidelity bond holder halts the protocol then their fidelity bond<br>
can be avoid by the user in all later CoinSwaps. And the malicious<br>
CoinSwapper could pack the orderbook with their sybils without<br>
sacrificing a lot of value for fidelity bonds.<br>
<br>
As a concrete example, Alice is a taker and Bob is a maker. Bob<br>
publishes a fidelity bond. Alice &quot;goes first&quot; by sending her coin=
s into<br>
a 2-of-2 multisig between her and Bob. When Bob sees the transaction is<br>
confirmed he broadcasts his own transactions into another 2-of-2<br>
multisig. If Bob is actually malicious and halts the protocol then he<br>
will cost Alice some time and money, but Alice will refuse to ever<br>
CoinSwap with Bob&#39;s fidelity bond again.<br>
<br>
If DOS becomes a big problem even with fidelity bonds, then its possible<br=
>
to have Alice request a &quot;DOS proof&quot; from Bob before broadcasting,=
 which<br>
is a set of data containing transactions, merkle proofs and signatures<br>
which are a contract where Bob promises to broadcast his own transaction<br=
>
if Alice does so first. If Alice gets DOSed then she can share this DOS<br>
proof publicly. The proof will have enough information to convince<br>
anyone else that the DOS really happened, and it means that nobody else<br>
will ever CoinSwap with Bob&#39;s fidelity bond either (or at least assign<=
br>
some kind of ban score to lower the probability). I doubt it will come<br>
to this so I haven&#39;t expanded the idea much, but theres a longer writeu=
p<br>
in the reference[5].<br>
<br>
=3D=3D=3D Private key handover =3D=3D=3D<br>
<br>
The original proposal for CoinSwap involved four transactions. Two to<br>
pay into the multisig addresses and two to pay out. We can do better<br>
than this with private key handover[6]. This is an observation that once<br=
>
the CoinSwap preimage is revealed, Alice and Bob don&#39;t have to sign eac=
h<br>
other&#39;s multisig spend, instead they could hand over their private key<=
br>
to the other party. The other party will know both keys of the 2-of-2<br>
multisig and therefore have unilateral control of the coins. Although<br>
they would still need to watch the chain and respond in case a<br>
hash-time-locked contract transaction is broadcasted.<br>
<br>
As well as saving block space, it also improves privacy because the<br>
coins could stay unspent for a long time, potentially indefinitely.<br>
While in the original coinswap proposal an analyst of the chain would<br>
always see a funding transaction followed closely in time by a<br>
settlement transaction, and this could be used as a fingerprint.<br>
<br>
We can go even further than private key handover using a scheme called<br>
SAS: Succinct Atomic Swap[7]. This scheme uses adapter signatures[8] to<br>
create a similar outcome to CoinSwap-with-private-key-handover, but only<br=
>
one party in the CoinSwap must watch and respond to blockchain events<br>
until they spend the coin. The other party just gets unilateral control<br>
of their coins without needing to watch and respond.<br>
<br>
<br>
=3D=3D=3D PayJoin with CoinSwap =3D=3D=3D<br>
<br>
CoinSwap can be combined with CoinJoin. In original CoinSwap, Alice<br>
might pay into a CoinSwap address with a regular transaction spending<br>
multiple of her own inputs:<br>
<br>
=C2=A0 =C2=A0 AliceInputA (1 BTC) ----&gt; CoinSwap Address (3 BTC)<br>
=C2=A0 =C2=A0 AliceInputB (2 BTC)<br>
<br>
This leaks information that all of those inputs are owned by the same<br>
person. We can make this example transaction a CoinJoin by involving<br>
Bob&#39;s inputs too. CoinJoin requires interaction but because Alice and<b=
r>
Bob are already interacting to follow the CoinSwap protocol, so it&#39;s no=
t<br>
too hard to have them interact a bit more to do a CoinJoin too. The<br>
CoinJoin transaction which funds the CoinSwap address would look like this:=
<br>
<br>
=C2=A0 =C2=A0 AliceInputA (1 BTC) ----&gt; CoinSwap Address (7 BTC)<br>
=C2=A0 =C2=A0 AliceInputB (2 BTC)<br>
=C2=A0 =C2=A0 BobInputA=C2=A0 =C2=A0(4 BTC)<br>
<br>
Alice&#39;s and Bob&#39;s inputs are both spent in a same transaction, whic=
h<br>
breaks the common-input-ownership heuristic. This form of CoinJoin is<br>
most similar to the PayJoin protocol or CoinJoinXT protocol. As with the<br=
>
rest of this design, this protocol does not have any special patterns<br>
and so is indistinguishable from any regular bitcoin transaction.<br>
<br>
To make this work Bob the maker needs to provide two unrelated UTXOs,<br>
one that is CoinSwapped and the other CoinJoined.<br>
<br>
=3D=3D=3D=3D Using decoy UTXOs to protecting from leaks =3D=3D=3D=3D<br>
<br>
If Bob the maker was just handing out inputs for CoinJoins to any Alice<br>
who asked, then malicious Alice&#39;s could constantly poll Bob to learn hi=
s<br>
UTXO and then halt the protocol. Malicious Alice could learn all of<br>
Bob&#39;s UTXOs and easily unmix future CoinSwaps by watching their future<=
br>
spends.<br>
<br>
To defend against this attack we have Bob maintain a list of &quot;decoy<br=
>
UTXOs&quot;, which are UTXOs that Bob found by scanning recent blocks. Then=
<br>
when creating the CoinJoin, Bob doesn&#39;t just send his own input but<br>
sends perhaps 50 or 100 other inputs which don&#39;t belong to him. For the=
<br>
protocol to continue Alice must partially-sign many CoinJoin<br>
transactions; one for each of those inputs, and send them back to Bob.<br>
Then Bob can sign the transaction which contains his genuine input and<br>
broadcast it. If Alice is actually a malicious spy she won&#39;t learn Bob&=
#39;s<br>
input for sure but will only know 100 other inputs, the majority of<br>
which have nothing to do with Bob. By the time malicious Alice learns<br>
Bob&#39;s true UTXO its already too late because its been spent and Alice i=
s<br>
locked into the CoinSwap protocol, requiring time, miner fees and<br>
CoinSwap fees to get out.<br>
<br>
This method of decoy UTXOs has already been written about in the<br>
original PayJoin designs from 2018[9][10].<br>
<br>
=3D=3D=3D Creating a communication network using federated message boards =
=3D=3D=3D<br>
<br>
Right now JoinMarket uses public IRC networks for communication. This is<br=
>
subpar for a number of reasons, and we can do better.<br>
<br>
I propose that there be a small number of volunteer-operated HTTP<br>
servers run on Tor hidden services. Their URLs are included in the<br>
CoinSwap software by default. They can be called message board servers.<br>
Makers are also servers run on hidden services, and to advertise<br>
themselves they connect to these message board servers to post the<br>
makers own .onion address. To protect from spam, makers must provide a<br>
fidelity bond before being allowed to write to the HTTP server.<br>
<br>
Takers connect to all these HTTP message boards and download the list of<br=
>
all known maker .onion addresses. They connect to each maker&#39;s onion to=
<br>
obtain parameters like offered coinswap fee and maximum coinswap size.<br>
This is equivalent to downloading the orderbook on JoinMarket. Once<br>
takers have chosen which makers they&#39;ll do a CoinSwap with, they<br>
communicate with those maker again directly through their .onion address<br=
>
to transmit the data needed to create CoinSwaps.<br>
<br>
These HTTP message board servers can be run quite cheaply, which is<br>
required as they&#39;d be volunteer run. They shouldn&#39;t require much<br=
>
bandwidth or disk space, as they are well-protected from spam with the<br>
fidelity bond requirement. The system can also tolerate temporary<br>
downtimes so the servers don&#39;t need to be too reliable either. It&#39;s=
 easy<br>
to imagine the volunteers running them on a raspberry pi in their own<br>
home. These message board servers are similar in some ways to the DNS<br>
seeds used by Bitcoin Core to find its first peers on bitcoin&#39;s p2p<br>
network. If the volunteers ever lose interest or disappear, then the<br>
community of users could find new volunteer operators and add those URLs<br=
>
to the default list.<br>
<br>
In order to censor a maker, _all_ the message board servers would have<br>
to co-operate to censor him. If censorship is happening on a large scale<br=
>
(for example if the message board servers only display sybil makers run<br>
by themselves) then takers could also notice a drop in the total value<br>
of all fidelity bonds.<br>
<br>
<br>
=3D=3D How are CoinSwap and Lightning Network different? =3D=3D<br>
<br>
CoinSwap and Lightning Network have many similarities, so it&#39;s natural<=
br>
to ask why are they different, and why do we need a CoinSwap system at<br>
all if we already have Lightning?<br>
<br>
=3D=3D=3D CoinSwap can be adopted unilaterally and is on-chain =3D=3D=3D<br=
>
<br>
Today we see some centralized exchange not supporting so-called<br>
``privacy altcoins&#39;&#39; because of regulatory compliance concerns. We =
also<br>
see some exchanges frowning upon or blocking CoinJoin transaction they<br>
detect[11]. (There is some debate over whether the exchanges really<br>
blocked transactions because they were CoinJoin, but the principle<br>
remains that equal-output CoinJoins are inherently visible as such).<br>
It&#39;s possible that those exchanges will never adopt Lightning because o=
f<br>
its privacy features.<br>
<br>
Such a refusal would simply not be possible with CoinSwap, because it is<br=
>
fundamentally an on-chain technology. CoinSwap users pay to bitcoin<br>
addresses, not Lightning invoices. Anybody who accepts bitcoin today<br>
will accept CoinSwap. And because CoinSwap transactions can be made<br>
indistinguishable from regular transactions, it would be very difficult<br>
to even determine whether they got paid via a CoinSwap or not. So<br>
CoinSwap is not a replacement for Lightning, instead it is a replacement<br=
>
for on-chain privacy technology such as equal-output CoinJoins which are<br=
>
implemented today in JoinMarket, Wasabi Wallet and Samourai Wallet.<br>
Ideally this design, if implemented, would be possible to include into<br>
the many already-existing bitcoin wallets, and so the CoinSwaps would be<br=
>
accessible to everyone.<br>
<br>
This feature of CoinSwap will in turn help Lightning Network, because<br>
those censoring exchanges won&#39;t be able to stop transactions with<br>
undetectable privacy no matter what they do. When they realize this<br>
they&#39;ll likely just implement Lightning Network anyway regardless of th=
e<br>
privacy.<br>
<br>
Bitcoin needs on-chain privacy as well, otherwise the bad privacy can<br>
leak into layer-2 solutions.<br>
<br>
=3D=3D=3D Different ways of solving liquidity =3D=3D=3D<br>
<br>
Lightning Network cannot support large payment amounts. Liquidity in<br>
payment channels on the Lightning network is a scarce resource. Nodes<br>
which relay lightning payments always take care that a payment does not<br>
exhaust their liquidity. Users of Lightning today must often be aware of<br=
>
inbound liquidity, outbound liquidity and channel rebalancing. There<br>
even exist services today which sell Lightning liquidity.<br>
<br>
This CoinSwap design solves its liquidity problem in a completely<br>
different way. Because of the liquidity market similar to JoinMarket,<br>
all the required liquidity is always available. There are never any<br>
concerns about exhausting channel capacity or a route not being found,<br>
because such liquidity is simply purchased from the liquidity market<br>
right before it is used.<br>
<br>
It is still early days for Lightning, and liquidity has been a known<br>
issue since the start. Many people are confident that the liquidity<br>
issue will be improved. Yet it seems hard to imagine that Lightning<br>
Network will ever reliably route payments of 200 BTC to any node in the<br>
network (and it doesn&#39;t have to to be successful), yet on JoinMarket<br=
>
today as I write these words there are offers to create CoinJoins with<br>
amounts up to around 200 BTC. We can expect similar large amounts to be<br>
sendable in CoinSwap. The liquidity market as a solution is known to<br>
work and has been working for years.<br>
<br>
=3D=3D=3D Sybil resistance =3D=3D=3D<br>
<br>
CoinSwap can support fidelity bonds and so can be made much more<br>
resistant to sybil attacks. We saw in the earlier section that realistic<br=
>
numbers from JoinMarket imply a sybil attacker would have to lock up<br>
hundreds of millions of USD worth of bitcoin to successfully deanonymize<br=
>
users.<br>
<br>
It&#39;s difficult to compare this to the cost of a sybil attack in<br>
Lightning network as such attacks are hard to analyze. For example, the<br>
attacker needs to convince users to route payments through the<br>
attacker&#39;s own nodes, and maybe they could do this, but putting numbers=
<br>
on it is hard. Even so it is very likely that the true cost is much less<br=
>
than 500 million USD locked up for months because Lightning nodes can be<br=
>
set up for not more than the cost of hardware and payment channel<br>
capacity, while CoinSwap makers would require expensive fidelity bond<br>
sacrifices.<br>
<br>
As this CoinSwap design would cost much more sybil attack, its privacy<br>
would be much greater in this respect.<br>
<br>
<br>
=3D=3D How are CoinSwap, PayJoin and PaySwap different? =3D=3D<br>
<br>
PayJoin can also be indistinguishable from regular bitcoin transaction,<br>
so why don&#39;t we all just that and not go further?<br>
<br>
The answer is the threat models. PayJoin works by having the customer<br>
and merchant together co-operate to increase both their privacy. It<br>
works if the adversary of both of them is a passive observer of the<br>
blockchain.<br>
<br>
PayJoin doesnt help a customer at all if the user&#39;s adversary is the<br=
>
merchant. This situation happens all the time today, for example<br>
exchanges spying on their customers. CoinSwap can help in this<br>
situation, as it doesn&#39;t assume or require that the second party is you=
r<br>
friend. The same argument applies to PaySwap.<br>
<br>
Obviously PayJoin and PaySwap are still very useful, but they operate<br>
under different threat models.<br>
<br>
<br>
=3D=3D Conclusion =3D=3D<br>
<br>
CoinSwap is a promising privacy protocol because it breaks the<br>
transaction graph heuristic, but it cant work on its own. In order to<br>
create a truly private system of sending transactions which would<br>
improve bitcoin&#39;s fungibility, CoinSwap must be combined with a couple<=
br>
of other building blocks:<br>
<br>
* ECDSA-2P<br>
* Liquidity market<br>
* Routed CoinSwaps<br>
* Multi-transaction CoinSwaps<br>
* Breaking change output heuristics<br>
* Fidelity bonds<br>
* PayJoin with CoinSwap<br>
* Federated message boards protected from spam with fidelity bonds<br>
<br>
CoinSwap transactions could be made to look just like any other regular<br>
bitcoin transaction, with no distinguishing fingerprint. This would make<br=
>
them invisible.<br>
<br>
I intend to create this CoinSwap software. It will be almost completely<br>
decentralized and available for all to use for free. The design is<br>
published here for review. If you want to help support development I<br>
accept donations at <a href=3D"https://bitcoinprivacy.me/coinswap-donations=
" rel=3D"noreferrer" target=3D"_blank">https://bitcoinprivacy.me/coinswap-d=
onations</a><br>
<br>
<br>
=3D=3D References =3D=3D<br>
<br>
- [1] &quot;CoinSwap: Transaction graph disjoint trustless trading&quot;<br=
>
<a href=3D"https://bitcointalk.org/index.php?topic=3D321228.0" rel=3D"noref=
errer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D321228.0=
</a><br>
<br>
- [2]<br>
<a href=3D"http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scri=
ptless-ecdsa/" rel=3D"noreferrer" target=3D"_blank">http://diyhpl.us/wiki/t=
ranscripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</a><br>
<br>
- [3] <a href=3D"https://en.bitcoin.it/wiki/Privacy#Change_address_detectio=
n" rel=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/Privacy#=
Change_address_detection</a><br>
<br>
- [4] &quot;Design for improving JoinMarket&#39;s resistance to sybil attac=
ks<br>
using fidelity bonds&quot;<br>
<a href=3D"https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dc=
d6b5af/" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/chris=
-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/</a><br>
<br>
- [5] <a href=3D"https://github.com/AdamISZ/CoinSwapCS/issues/50" rel=3D"no=
referrer" target=3D"_blank">https://github.com/AdamISZ/CoinSwapCS/issues/50=
</a><br>
<br>
- [6] <a href=3D"https://github.com/AdamISZ/CoinSwapCS/issues/53" rel=3D"no=
referrer" target=3D"_blank">https://github.com/AdamISZ/CoinSwapCS/issues/53=
</a><br>
<br>
- [7]<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May=
/017846.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2020-May/017846.html</a><br>
<br>
- [8]<br>
<a href=3D"https://github.com/ElementsProject/scriptless-scripts/blob/maste=
r/md/atomic-swap.md" rel=3D"noreferrer" target=3D"_blank">https://github.co=
m/ElementsProject/scriptless-scripts/blob/master/md/atomic-swap.md</a><br>
<br>
- [9]<br>
<a href=3D"https://blockstream.com/2018/08/08/en-improving-privacy-using-pa=
y-to-endpoint/" rel=3D"noreferrer" target=3D"_blank">https://blockstream.co=
m/2018/08/08/en-improving-privacy-using-pay-to-endpoint/</a><br>
<br>
- [10] <a href=3D"https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6=
" rel=3D"noreferrer" target=3D"_blank">https://medium.com/@nopara73/pay-to-=
endpoint-56eb05d3cac6</a><br>
<br>
- [11]<br>
<a href=3D"https://cointelegraph.com/news/binance-returns-frozen-btc-after-=
user-promises-not-to-use-coinjoin" rel=3D"noreferrer" target=3D"_blank">htt=
ps://cointelegraph.com/news/binance-returns-frozen-btc-after-user-promises-=
not-to-use-coinjoin</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000007e238e05a6dfa8a0--