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's useful.</div><div><br></di= v><div>>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't actually require multisig for one of the two out= puts, 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 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'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 & 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>>=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>>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>>=3D=3D=3D PayJoin with CoinSwap =3D=3D=3D<= /div><div><br></div><div>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-ti= melocked side. This does require adding a transaction that undoes the PayJo= in in case the swap gets aborted, which means MuSig can'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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev= @lists.linuxfoundation.org</a>> 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't too bothered by privacy and<= br> sends her bitcoin using a regular wallet which exists today. But because<br= > Carol's transaction looks exactly the same as Alice's, anybody anal= yzing<br> the blockchain must now deal with the possibility that Carol's<br> transaction actually sent her coins to a totally unconnected address. So<br= > Carol's privacy is improved even though she didn'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's and Carol'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'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's Address 1 ----> CoinSwap Address 1 ----> Bo= b's Address 1<br> <br> An entirely separate set of transactions gives Bob's coins to Alice in<= br> return:<br> <br> =C2=A0 =C2=A0 Bob's Address 2 ----> CoinSwap Address 2 ----> Alic= e's Address 2<br> <br> Where the symbol ----> is a bitcoin transaction.<br> <br> Privacy is improved because an observer of the blockchain cannot link<br> Alice's Address 1 to Alice's Address 2, as there is no transaction<= br> between them. Alice's Address 2 could either be an address in Alice'= ;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 -> B is seen then the ownership of<br= > funds actually went from A to B.<br> <br> CoinSwap doesnt break any of bitcoin's assumptions or features like an<= br> auditable supply or pruning. It can be built on today's bitcoin without= <br> any new soft forks.<br> <br> CoinSwap can'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'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'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'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't<b= r> have such an incentive, as Schnorr single-sig costs the same size as<br> today'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) ----> CoinSwap AddressA ----> BobA (15 = BTC)<br> =C2=A0 =C2=A0 BobB (15 BTC) ----> CoinSwap AddressB ----> 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) ----> CoinSwap AddressA ----> BobA (15 = BTC)<br> <br> =C2=A0 =C2=A0 BobB (7 BTC) ----> CoinSwap AddressB ----> AliceB (7 BT= C)<br> =C2=A0 =C2=A0 BobC (5 BTC) ----> CoinSwap AddressC ----> AliceC (5 BT= C)<br> =C2=A0 =C2=A0 BobD (3 BTC) ----> CoinSwap AddressD ----> 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's coins<br> went. This means Bob is a single point of failure in Alice'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's payment is routed through many Bobs.<br> <br> =C2=A0 =C2=A0 AliceA =3D=3D=3D=3D> Bob =3D=3D=3D=3D> Charlie =3D=3D= =3D=3D> Dennis =3D=3D=3D=3D> AliceB<br> <br> Where the symbol =3D=3D=3D=3D> 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's behalf. The makers wouldn'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'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'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<-----------=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 (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't search<b= r> the blockchain backwards for Alice'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'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>------->-------\=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/<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'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'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's own wallet cluster.<br> <br> Another great heuristic to break is the script type heuristic. If the<br> maker'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'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'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'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'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 "who goes first" 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's to waste time and miner fees as they'= 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 "goes first" 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'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 "DOS proof" 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'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'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't have to sign eac= h<br> other'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) ----> 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's inputs too. CoinJoin requires interaction but because Alice and<b= r> Bob are already interacting to follow the CoinSwap protocol, so it'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) ----> 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's and Bob'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's could constantly poll Bob to learn hi= s<br> UTXO and then halt the protocol. Malicious Alice could learn all of<br> Bob'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 "decoy<br= > UTXOs", which are UTXOs that Bob found by scanning recent blocks. Then= <br> when creating the CoinJoin, Bob doesn't just send his own input but<br> sends perhaps 50 or 100 other inputs which don'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'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'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'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'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'd be volunteer run. They shouldn'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't need to be too reliable either. It'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'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'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'' 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'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't be able to stop transactions with<br> undetectable privacy no matter what they do. When they realize this<br> they'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'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'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'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'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'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'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'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] "CoinSwap: Transaction graph disjoint trustless trading"<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] "Design for improving JoinMarket's resistance to sybil attac= ks<br> using fidelity bonds"<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--