Add CashShuffle support

[abrkn]

Add optional CashShuffle support when sending transactions.

The lack of fungibility/privacy in Bitcoin Cash introduces a number of problems:

• Some centralized exchanges will suspend user accounts if deposits are (indirectly) coming from DarkNet Market places, gambling websites, etc.
• It's trivial to perform clustering to identify the real life identity, transaction history, and balance of a wallet from a single transaction. (Chainalysis, WalletExplorer)

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.

• CashShuffle Documentation
• Reference implementation (Electron Cash plugin)

If you can't help with coding, please consider adding $5 to the bounty. Everything helps.

[magmahindenburg]

We would love to add CashShuffle. For this to happen we need a JavaScript implementation that works with the Bitcore libraries.

[jli225]

Blockchain info ever implemented similar service years ago. Glad to see that Bitcoin com makes it again. People deserve more privacy. Although I dislike most DNM, I firmly believe that Government and its agents have infringed people's privacy too much.

[stefment]

@magmahindenburg is CashShuffle safe?

[PedroR82]

The Bountysource thingy accepts Paypal and Bitcoin. Could you enable a Bitcoin Cash address for this? I would send something in the range of 50$ to that address if so...

[PedroR82]

Or even better, get the bountysource team to add Bitcoin Cash there.

[lvella]

@PedroR82 There is an open issue about that (and a corresponding bounty): https://github.com/bountysource/core/issues/1136 https://www.bountysource.com/issues/49027183-add-bitcoin-cash-support-to-bountysource

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.

[patsul12]

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?

[abrkn]

There is already an open issue to add Bitcoin Cash (BCH) to BountySource: https://github.com/bountysource/core/issues/1136

[vedant1811]

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

[bookmoons]

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.

• @bookmoons/bitcore-ecies-cash
• @bookmoons/bitcore-message-cash

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.

• Support text form of @see tag. erikrose/sphinx-js#70
• Allow Markdown in descriptions. erikrose/sphinx-js#69
• A new autointerface directive
• A new automodule directive

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.

[bookmoons]

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:

Performs ECIES encryption with the bitcore-ecies 1.0.3 default configuration.

Wire delimiting. The reference code delimits messages on the wire with the Unicode character U+23CE Return Symbol in UTF-8. That comes out to the 3 byte sequence e2 8f 8e. I don't think there's any guarantee that byte sequence will not appear in messages. I'm really concerned this will cause broken messages. Proposed fix: write the message byte length preceding each message, as recommended in the protobuf docs.

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 Atom instances that are somehow serialized. Proposed fix: define a serialization and store the full list in the single packet.message.str field. I have this specified and implemented as delimited with ampersand &. That's a character not in either the Base64 representation used for ciphertexts or the CashAddr format used for addresses. Being in a single packet the entire list will be signed when the packet is signed.

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: [ ...encryptionKeys, ...outputList ].join(''), where encryption keys are little endian hex strings in order 2-N, output list is CashAddr strings in order observed in the final message that broadcasted it.

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 message.signatures that enables clean transfer of multiple signatures. This is used in phase 5 where the transaction is signed and everyone exchanges their signatures.

[bookmoons]

Copay calls itself a network interface but it doesn't seem to provide things like checking available funds of an address.

Was thinking of the Bitcore Wallet Service here. It's called the network interface but it doesn't seem to provide everything.

Copay depends on Bitcore Wallet Service (BWS) for blockchain information, networking and Copayer synchronization.

[bookmoons]

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.

[christroutner]

@bookmoons The BITBOX project is also interested in adding CashShuffle support. I've opened an issue to explore, and I welcome your input: https://github.com/Bitcoin-com/bitbox-javascript-sdk/issues/26

We have an SDK for low-level transactions as well as high-level HD wallets. Here are some example apps using BITBOX: https://github.com/Bitcoin-com/bitbox-javascript-sdk/tree/master/examples

Introduction to the SDK: https://developer.bitcoin.com/bitbox

Our API documentation: https://developer.bitcoin.com/bitbox/docs/getting-started

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

[bookmoons]

@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.

[autun12]

is anyone still working on this

[autun12]

If no one is working on it I would like to.

[abrkn]

The wallet has been deprecated in favor of another. The bounty is closed.