Bitcoin Forum
June 08, 2024, 01:53:29 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: CoinShuffle: Practical Decentralized Coin Mixing for Bitcoin  (Read 23731 times)
giszmo
Legendary
*
Offline Offline

Activity: 1862
Merit: 1105


WalletScrutiny.com


View Profile WWW
December 07, 2015, 04:07:53 PM
 #61

I feel like JoinMarket might be a dead end precisely due to what CoinShuffle claims to solve.
That is remarkably inexplicable to me.  JM is very actively developed by a community of developers. It was created with basically no anti-DOS mechanisms, though the original CJ post (technically the "appendix" post I made right below it) went over several different anti-DOS mechanisms, because it's perfectly reasonable to get something working before making it strong-- especially since JM's main motivation is gumming up automated analysis more than itself providing strong privacy.

But it's quite straight-forward to add in strong anti-DOS and better privacy, on top of a working and vibrant system; doubly so in that the coinshuffle description provides no special structural immunity to those dos attacks: the same anti-dos mechanisms are needed.  You shouldn't let that fact that a single person in the JM space is advocating one anti-dos method that would harm casual usage as at all indicative of ... well, anything.

Hi gmaxwell,

you and the joinmarket team helped me a lot to get this far with my joinmarket proxy and I feel bad for "betraying" you by saying negative things about JM maybe blind to CS having the same problems but as far as I understand it, JM does not aim to avoid the taker from learning the matching, which is at best a short cut to achieve some degree of mixing and at worst makes the whole endeavor of mixing pointless, as interested parties will inevitably outbid others just to get a glimpse at the matching. And they can do this under the radar, as knowing some UTXOs will help them to know a lot of the mixing without constantly probing every maker actively.

As far as I understand, in CS there is no obvious way to learn any matching as long as there are fair players at all. It allows you to single out the DOS players and that leaves the disruptors to spying, where they can only decrease the privacy probabilistically, to the point of learning one user's matching if they totally eclipse attack him. But as all would pay their share of the fee and makers can't earn from it, this would force attackers to provide activity that others would take for legit activity and use this great tool, which in turn would make the attacker fail to single out all honest players all the time.

In JM with its asymmetric structure with makers not actually caring about their privacy and having an incentive to share data among them, I also see the incentives aligned against anonymity.

ɃɃWalletScrutiny.comIs your wallet secure?(Methodology)
WalletScrutiny checks if wallet builds are reproducible, a precondition for code audits to be of value.
ɃɃ
nopara73
Member
**
Offline Offline

Activity: 99
Merit: 326


View Profile
January 16, 2020, 09:11:11 PM
Merited by ABCbits (1)
 #62

I wrote a simulation of the P2P shuffling process of CoinShuffle. If someone is looking at this idea who's familiar with .NET, it can help in understanding it: https://github.com/nopara73/CoinShuffleSimulation2

Creator of Wasabi Wallet: An open-source, non-custodial, privacy focused Bitcoin wallet - https://wasabiwallet.io
tromp
Legendary
*
Offline Offline

Activity: 984
Merit: 1091


View Profile
February 07, 2021, 09:23:19 AM
Last edit: June 28, 2022, 08:32:07 PM by tromp
Merited by mably (10), oryhp (5), ABCbits (3)
 #63

A comparison with other approaches
Mixcoin
Zerocoin / Zerocash / Anoncoin
CoinSwap

Mimblewimble allows for a very simple coin shuffling protocol [1] with the following properties:

* Users submit self-spends throughout the day. No interaction needed for shuffling.
* Shuffling is performed at the end of the day by a set of mixnodes that cannot steal any coins.
* Invalid self-spends are automatically filtered out. No need to abort or restart the shuffling.
* As long as at least one mixnode is honest, then no one learns the input output links.
* The size of the shuffle is limited only by blocksize and could easily be over a thousand.
* Each shuffle only grows the chainsize by a small constant (~100 byte), thanks to MW cut-through.

Widespread use of the protocol would leave the transaction graph mostly obscured.
We welcome review of the proposal.

[1] https://forum.grin.mw/t/mimblewimble-coinswap-proposal
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!