path: root/70/f9af64a4728630848934db606ea645dd00a363

Return-Path: <belcher@riseup.net>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 607B1C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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" <lee.chiffre@secmail.pro>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
 <5b77933071fa02e900183d8d5e24d866.squirrel@giyzk7o6dcunb2ry.onion>
From: Chris Belcher <belcher@riseup.net>
Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata=
 xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92
 f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl
 YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR
 FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE
 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7
 ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz
 WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu
 sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht
 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi
 Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj
 aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV
 CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX
 TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA
 btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A
 HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm
 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF
 LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA
 wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7
 OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb
 jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl
 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2
 k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr
 ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r
 KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf
 xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM
 KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6
 q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC
 z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW
 dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI
 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc
 /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA
 DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN
 IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93
 qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0
 +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON
 xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA
 aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ
 uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK
 MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc
 d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN
 HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM
 1aSoTg==
Message-ID: <aa5174d1-08d9-fc32-4c83-7d43c9f47531@riseup.net>
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 <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: 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.