Bitcoin : Establishing CashShuffle protocol details
Great work CashShuffle team getting this working.
I’m building a JavaScript implementation [cashshufflejs](https://github.com/bookmoons/cashshufflejs) ([docs](https://bookmoons.github.io/cashshufflejs/), [diagrams](https://github.com/bookmoons/cashshufflejs/wiki/Protocol)). If it’s possible I’d like to talk to the devs about some technical details so we can ensure compatibility.
**Address format.** There are different address formats. If clients use different formats they’ll get different results at certain steps, eg when hashing the output list. I propose we standardize on using the [CashAddr](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md) format for all work involving addresses.
**Wire delimiting.** The current code delimits messages on the wire with the Unicode character [`U+23CE Return Symbol`](https://codepoints.net/U+23CE) in UTF-8. That comes out to the 3 byte sequence `e2 8f 8e`. I don’t think there’s any guarantee this byte sequence will not appear in messages. I’m concerned this will cause broken messages. Proposed change: write the message byte length preceding each message, as [recommended in the protobuf docs](https://developers.google.com/protocol-buffers/docs/techniques#streaming).
**Output list serialization.** The protocol produces a list of output addresses, transferred first encrypted and eventually in plaintext once shuffling is done. The current code packages into multiple packets and seems not to sign the full list. I’m concerned this a security hole. One possible approach here is to define a serialization and store the full list in the single `packet.message.str` field. Proposed format: items delimited with ampersand `&`. That’s a character not in either the Base64 representation used for ciphertexts or the CashAddr format used for addresses.
**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 all hashes are identical. The current code serializes these lists with the Python [str()](https://docs.python.org/3/library/stdtypes.html#str) function. The Python docs call this an “informal” representation of the object. It doesn’t seem to have a specified format. I don’t think it’s guaranteed to stay the same. I think we need to define a precise format for this value, and hopefully choose something that is easy to achieve in any language. Proposed format: encryption keys in ascending order 2-N, output addresses in order observed in final broadcast message, all concatenated with no delimiter. In JavaScript that’s: `[ …encryptionKeys, …outputList ].join(”)`.
For anyone interested it’s possible to run a test session with cashshufflejs. It runs a real session through a local mock server (without submitting to the BCH network). Real output addresses, real signatures, etc.
git clone https://github.com/bookmoons/cashshufflejs.git
cd cashshufflejs
npm install
npm run demo:session
You’ll get something like:
John: Shuffling with 3 participants
Mary: Shuffling with 3 participants
Marduk: Shuffling with 3 participants
John: Broadcasted encryption public key
Mary: Broadcasted encryption public key
Marduk: Broadcasted encryption public key
Marduk: Gathered participant encryption keys
Marduk: Phase 1 Announce complete
Marduk: Generated output address
John: Gathered participant encryption keys
Mary: Gathered participant encryption keys
Marduk: Phase 2 Shuffle complete
John: Phase 1 Announce complete
Mary: Phase 1 Announce complete
John: Generated output address
Mary: Generated output address
John: Sent encrypted output list
John: Phase 2 Shuffle complete
..
Bitcoin
Bitcoin is a distributed, worldwide, decentralized digital money. Bitcoins are issued and managed without any central authority.
FindCrypto scans the web for the latest Bitcoin news, so you can find all the latest and breaking news in one convenient location.
Author: bookmoons
Score: 44
Don’t forget to share the post if you love it !
