From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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 07:09:04 +0000 [thread overview]
Message-ID: <V-w3Jx5ssSZ1Ch5GEiJJjI12U1qmnlyCsET6JjsDAkl2yC6iJ7DK52mshe0F7wOAjK8vrbSeqRijC3QFRyl1FuGe41xcmYfgC6s7e7H_AQg=@protonmail.com> (raw)
In-Reply-To: <5b77933071fa02e900183d8d5e24d866.squirrel@giyzk7o6dcunb2ry.onion>
Good morning Mr. Lee,
> > === 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?
CoinSwap lets you buy privacy at whatever rate is manageable for you.
You can buy a simple non-routed non-multitransaction CoinSwap, for example, instead of larger sections like the above, depending on your privacy needs.
Even doing a non-routed non-multitransaction CoinSwap would help fungibility of those doing more complex setups, because the tiny CoinSwaps you make are made of "the same things" that the more complex CoinSwaps are made of.
>
> 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
Overall, multiple mixing techniques cover a wide range of cost and privacy.
* PayJoins are cheap and almost free (you are coordinating with only one other participant who is strongly incentivized to cooperate with you, and making a single overall tx) but buys you only a small dollop of privacy (transaction can be misinterpreted by chain analysis, but probabilistic analysis can be "reasonably accurate" for a few transactions).
* Equal-valued CoinJoins are slightly more expensive than PayJoins but give a good amount of privacy (you are coordinating with multiple participants, and probably paying coordination/participation fees, but *which* output is yours will give probabilistic analysis a run for its money, although it is obvious that you *did* participate in a CoinJoin).
* CoinSwaps are a good bit more expensive than equal-valud CoinJoins but give a significant amount of privacy for their cost (you are coordinating with multiple participants and paying coordination/participation fees *and* you run the risk of getting your funds timelocked in case of network communications problems or active hacking attempts, but it is hard for chain analysis to even *realize* that a CoinSwap even occurred, i.e. it is steganographic).
Chris argues that CoinSwap gives better privacy:cost ratios than equal-valued CoinJoins, you can wait and see if he gives more supporting arguments regarding this, but overall the various mixing tech exists to give choice on how much privacy you buy.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-06-10 7:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 13:21 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 [this message]
2020-06-10 11:15 ` Chris Belcher
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='V-w3Jx5ssSZ1Ch5GEiJJjI12U1qmnlyCsET6JjsDAkl2yC6iJ7DK52mshe0F7wOAjK8vrbSeqRijC3QFRyl1FuGe41xcmYfgC6s7e7H_AQg=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lee.chiffre@secmail$(echo .)pro \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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