From: Chris Belcher <belcher@riseup.net>
To: "Mr. Lee Chiffre" <lee.chiffre@secmail.pro>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Date: Wed, 10 Jun 2020 12:15:03 +0100 [thread overview]
Message-ID: <aa5174d1-08d9-fc32-4c83-7d43c9f47531@riseup.net> (raw)
In-Reply-To: <5b77933071fa02e900183d8d5e24d866.squirrel@giyzk7o6dcunb2ry.onion>
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.
next prev parent reply other threads:[~2020-06-10 11:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 13:21 [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility Chris Belcher
2020-05-30 16:00 ` Ruben Somsen
2020-05-31 2:30 ` ZmnSCPxj
2020-05-31 21:19 ` Ruben Somsen
2020-06-01 2:34 ` ZmnSCPxj
2020-06-01 10:19 ` Ruben Somsen
2020-06-02 22:24 ` Chris Belcher
2020-06-03 4:53 ` ZmnSCPxj
2020-06-03 14:50 ` ZmnSCPxj
2020-06-04 16:37 ` ZmnSCPxj
2020-06-05 22:39 ` Chris Belcher
2020-06-06 1:40 ` ZmnSCPxj
2020-06-06 3:59 ` ZmnSCPxj
2020-06-06 4:25 ` ZmnSCPxj
2020-06-10 10:15 ` Chris Belcher
2020-06-10 10:58 ` ZmnSCPxj
2020-06-10 11:19 ` Chris Belcher
2020-06-10 0:43 ` Mr. Lee Chiffre
2020-06-10 0:46 ` Mr. Lee Chiffre
2020-06-10 7:09 ` ZmnSCPxj
2020-06-10 11:15 ` Chris Belcher [this message]
2020-06-19 15:33 ` Jonas Nick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa5174d1-08d9-fc32-4c83-7d43c9f47531@riseup.net \
--to=belcher@riseup.net \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lee.chiffre@secmail.pro \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox