Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 607B1C016F for ; Wed, 10 Jun 2020 11:15:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4E56A8609F for ; Wed, 10 Jun 2020 11:15:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMv-ub+B9trz for ; Wed, 10 Jun 2020 11:15:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by whitealder.osuosl.org (Postfix) with ESMTPS id 774F58609C for ; Wed, 10 Jun 2020 11:15:25 +0000 (UTC) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 49hkt23KBmzFgsF; Wed, 10 Jun 2020 04:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1591787725; bh=voynChQqUJijw/qcaiKbN2rqxFbBZYIr0EOJy9bGQFI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mex1zCnC0IygEM4oSNJZkOpJvrKXxXY5/FNxeZQivOrB1KgTPRGqHCvSLFZtitkCa lGOcSJxcBrFR7IkCTQJtxubdzyIOnBjCiTc9xtXd50YZALod6mRRtLVYr2B7txhB1K d7gOmbBK/6uxC5qmVZNV8ocekWZRZdYFFdfwKbTA= X-Riseup-User-ID: 198C5C764080EBCF30DD1ED1671EF8F15C192F74615371FE854B20199C0D6CBC Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 49hkt12J7Pz8tfk; Wed, 10 Jun 2020 04:15:05 -0700 (PDT) To: "Mr. Lee Chiffre" , Bitcoin Protocol Discussion References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> <5b77933071fa02e900183d8d5e24d866.squirrel@giyzk7o6dcunb2ry.onion> From: Chris Belcher Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92 f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7 ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7 OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2 k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6 q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93 qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0 +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM 1aSoTg== Message-ID: Date: Wed, 10 Jun 2020 12:15:03 +0100 MIME-Version: 1.0 In-Reply-To: <5b77933071fa02e900183d8d5e24d866.squirrel@giyzk7o6dcunb2ry.onion> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 11:15:26 -0000 Hello Lee, Thanks for the review. On 10/06/2020 01:43, Mr. Lee Chiffre wrote: > >> >> === 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 >> > > > > > > > Great work Chris and you have my respects for your contributions to > Bitcoin. A concern I have with bitcoin is scalability and privacy. Both > are important. The reasons people bash on Monero is also the same issue > Bitcoin has. The very large transaction size to achieve acceptable privacy > on a distributed financial network. Im not shilling Monero here. I am only > saying that bitcoin transactions with similar privacy properties are at > least equally as large as Monero transactions. Coinjoin on Monero can be > compared to ring signatures in Monero from the view of using decoys to > help conceal the source. From this proposal is this to say that > transactions will be at least 12 times larger in size to achieve the > property of privacy that bitcoin is currently missing? > > Another thing to consider is that if coinswaps cannot be sent as a payment > then a coinswap needs to take place after every transaction to keep the > privacy and unlinkability from your other bitcoin transactions. > > I always thought that CoinSwap would be and is a very much needed thing > that needs developed. The ability to swap coins with other people in a > trustless way and way that is not linkable to the public blockchain. But > how can this be scalable at all with the multiple branches and layers? > This is a good idea in theory but my concern would be the scalability > issues this creates. > > Do you have any comments on this? > Thank you > You are right to be concerned about scalability. Here's a few of my thoughts on this: An issue with Monero (or any cryptocurrency based on the ring signature input signing scheme) isn't just that transactions are bigger in bytes. Monero full nodes can't know when a TXO has been spent, so pruning is impossible in Monero and the list of TXOs perpetually grows, this is unlike in bitcoin where full nodes know if a UTXO has been spent and so can delete it in pruning. The storage space needed for Bitcoin's UTXO set sometimes actually gets smaller. Note that Monero software actually has a feature called "pruning" so sometimes the terminology gets confused when people say "wait, Monero _does_ have pruning". But this pruning doesn't do the same thing as Bitcoin's pruning, the disk space still grows as O(TXOcount) which is much faster compared to Bitcoin's O(UTXOcount). And when designing this CoinSwap system I've been careful to make sure it doesn't break pruning (or other resources saving features, for example CoinSwap can be made to work with the blocksonly feature of Bitcoin Core). So bitcoin-with-CoinSwap's scalability isnt anywhere near as bad as Monero's. You're right to talk about decoys. Decoys are not a good way to obtain privacy because they can be broken by repeated interactions.. I really like this talk about why decoys are not a good solution to privacy in many cases: talk: https://www.youtube.com/watch?v=YgtF7psIKWg&feature=youtu.be&t=3701 transcript: https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/how-much-privacy-is-enough Equal-output CoinJoins also work with decoys. Like in JoinMarket you could analyze those CoinJoins to say that the inputs and outputs of the makers in a CoinJoin are actually just decoys. Fixed-denomination CoinJoins like in Wasabi or Samourai also use much more block space because of the reduced divisibility, for example Wasabi coinjoins can only be done with about 0.1 BTC, so if you want to mix 1 BTC then you have to do 10 such CoinJoins, costing 10 times the block space. CoinSwap doesn't work by adding decoys, it improves privacy in the same way as Lightning: by moving information off-chain. You could perhaps analyze CoinSwap as using decoys if you say that the decoys are almost every other bitcoin transaction happening on the blockchain, and that can be almost as big as you want. One full block has about 3000 outputs, so if you wait a day between the CoinSwap funding and spending transactions then that's 144*3000 = 432000 decoys (this calculation is simplified, but it's a good starting point). If CoinJoin or Monero transactions had that many decoys they would be hundreds of MB each. Because CoinSwap transactions can look exactly the same as regular transactions, they would improve the privacy of users even if they don't use CoinSwap. So on twitter sometimes I see people talking about "making every spend a CoinJoin". The suggestion would be very costly in block space, and isn't necessary for CoinSwap. I think perhaps 5% of transactions being CoinSwaps or PayJoin-with-CoinSwap (as long as they were spread roughly equally across the economy) would be enough to destroy the transaction graph heuristic and common-input-ownership heuristic. Then anyone analyzing the blockchain couldn't be sure when they see coins going from address A to B that the ownership actually went from A to B, or that if they see multiple inputs they don't know whether those inputs are actually owned by the same entity. Also, CoinSwaps could be used as payment. For example take this 1-hop CoinSwap where Alice owns 10 BTC and wants to deposit 5 BTC into her exchange account. (3 BTC) --> (5 BTC) --> Exchange Alice (1 BTC) --> Bob (4 BTC) --> Alice change1 (6 BTC) --> (1 BTC) --> Alice change2 So on the last hop Alice sends 5 BTC as payment to the exchange (to deposit) and the remaining outputs go back to Alice as change. The exchange can't see Alice's UTXOs that she just spent, and also can't see Alice's change outputs. Additionally, even in the example you use where 12 times as much block space is used as normal, this is still cheaper than Equal-Output Coinjoins. For example with JoinMarket a single CoinJoin is approximately 12 times bigger than a regular bitcoin transaction, and to get good privacy using JoinMarket's tumbler algorithm the user typically creates 7-15 of those CoinJoins. And even then those CoinJoins are very obvious and don't improve the privacy of people who don't use them, meaning we have to advocate the expensive and impractical slogan "make every spend a CoinJoin". And they also don't provide as much privacy as CoinSwap would, because their anonymity set is smaller than CoinSwap's. Finally, we know that blockchains don't scale, and so its widely expected that most day-to-day bitcoin transactions will happen off-chain on something like Lightning network, which also brings us privacy. CoinSwap then is mostly useful for the situations where on-chain transfers are still needed, and also because good on-chain privacy is necessary for Lightning to really be private, because otherwise the on-chain channel UTXOs can be tracked.