-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CashShuffle support #34
Comments
We would love to add CashShuffle. |
Blockchain info ever implemented similar service years ago. |
@magmahindenburg is CashShuffle safe? |
The Bountysource thingy accepts Paypal and Bitcoin. |
Or even better, get the bountysource team to add Bitcoin Cash there. |
@PedroR82 There is an open issue about that (and a corresponding bounty): Unfortunately, according what BountySource admin said to me via IRC, they have no plans merging such a feature in the short term. Maybe we should develop our own BountySource where bounties are kept directly in cryptocurrency. |
I'd be happy to do some work on this, or help out someone who is already doing so. I'm assuming this would be a standalone javascript implementation of the CashShuffle protocol that is then integrated into this wallet? |
There is already an open issue to add Bitcoin Cash (BCH) to BountySource: bountysource/core#1136 |
Anyone working on this? Has been silent for a long time even with an open bounty. If not, I can get started in this direction |
Hi guys. Would really love to make this happen. I've been reading through the CashShuffle and CoinShuffle and ECIES material. I have some code toward it here: cashshufflejs. I'm favoring correctness and code clarity over performance for the initial release. Bug reports and code review welcome. It doesn't talk to the BCH network yet but it's possible to run the tests: $ git clone https://github.com/bookmoons/cashshufflejs.git
$ cd cashshufflejs
$ npm install
$ npm test It uses a couple new modules that are just the extant bitcore modules modified to use bitcore-lib-cash instead of bitcore-lib. CashShuffle is an extension to CoinShuffle. The core of the CoinShuffle session is implemented. The blame phase is pending. Bits around it are pending, eg joining a pool, retries after ejecting a bad participant. The session looks like this. There are diagrams of the phases on the wiki. There are docs up here: cashshufflejs docs. The interfaces are defined carefully. The original CashShuffle docs are a little haphazard. Hoping to make things more lucid and precise. For example: the message encryption interface. The docs use some custom extensions to sphinx-js. Some pieces need polishing (longer than necessary paths are displayed, typedefs are rendered as functions). But I think the important details are visible. I'm working on submitting those changes for inclusion. Would like to get the docs up on ReadTheDocs.
A question for whoever knows: what is the right way to interface with the BCH network? Copay calls itself a network interface but it doesn't seem to provide things like checking available funds of an address. |
There are things I find disquieting in the reference implementation. I'd like to propose some breaking changes and ask anyone interested for comment. A shuffling server was actually shut down due to concerns about the code. So I think we may have an opportunity to get some changes in before significant usage starts. ECIES configuration. ECIES is a very general scheme with many possible configurations. There doesn't seem to be a JavaScript library that provides the full range. We're targeting bitcore compatbility, so I went with the bitcore-ecies module modified for Bitcoin Cash. I propose we choose the default configuration of this module. I've specified it that way in the docs:
Wire delimiting. The reference code delimits messages on the wire with the Unicode character Output list serialization. The protocol produces a list of output addresses, transferred first encrypted and eventually in plaintext once shuffling is done. The reference code does a strange thing here of packaging into multiple packets and seems not to sign the full list. I'm concerned this is a security hole. The reference code is based on the CoinShuffle implementation ShufflePuff. I think this is an attempt to mimic the ShufflePuff approach of using multiple Hash function input. Phase 4 runs an equivocation check. At this point the output list is known. Everyone hashes it (along with encryption public keys 2-N) and confirms that all hashes are identical. The reference code serializes these lists with the Python str() function. This doesn't seem like a safe way to serialize. The docs say it gives the “informal” or nicely printable string representation of object. I'm not sure this format is even specified anywhere, or identical across Python versions. I think we need to define a precise format for this input. Proposed format: Multiple inputs per user. The reference code (and ShufflePuff) require exactly 1 UTXO per shuffle participant. I want to suggest we lift this limitation and allow multiple. I'm not sure if there are issues with this that motivated ShufflePuff to avoid it. But it seems like a pain to force users to do a staging transaction before they can shuffle. Related to this, a suggested new repeated field in the protocol |
Was thinking of the Bitcore Wallet Service here. It's called the network interface but it doesn't seem to provide everything.
|
Some discussion of this happening on Reddit: Establishing CashShuffle protocol details The plugin project is more active than I realized, so I'm dropping some of these in favor of conformance with the current code. |
@bookmoons The BITBOX project is also interested in adding CashShuffle support. I've opened an issue to explore, and I welcome your input: We have an SDK for low-level transactions as well as high-level HD wallets. Here are some example apps using BITBOX: Introduction to the SDK: Our API documentation: I welcome you to join our Discord channel so that we can discuss how we could implement a cash shuffle with your library using our SDK: https://discord.gg/m5h28ND |
@christroutner Very interesting, thanks for pinging me. I'm dug into another project for a little while here, then I'll be getting back to this. Will look things over when I get my head back into it. |
is anyone still working on this |
If no one is working on it I would like to. |
The wallet has been deprecated in favor of another. The bounty is closed. |
Add optional CashShuffle support when sending transactions.
The lack of fungibility/privacy in Bitcoin Cash introduces a number of problems:
To get around these issues, users are fleeing to digital currencies with improved privacy such as Monero, Zcash, Zcoin, Dash, and more.
Bitcoin Cash is A Peer-to-Peer Electronic Cash System. Fungibility is an attribute of cash and thus a requirement.
If you can't help with coding, please consider adding $5 to the bounty. Everything helps.
The text was updated successfully, but these errors were encountered: