Introducing Group Tokens for Bitcoin Cash - Part 3/N - CoinJoin

For a very short description of what Group tokens are, have a look here. I can't repeat the same text here due to read.cash rules.

The notation is simple, stuff in [] describes a transaction output:

[BCH satoshi amount, Group ID, Group amount or authority flags]

CoinJoin is another kind of atomic transaction. Instead of transferring value between different owners, like with atomic swaps, it transfers value between different storages of multiple owners and at the same time so it will obfuscate which storage belongs to whom.

Simplest such transaction is with two parties. Suppose Alice and Bob both received an amount of Token T from Eve. Now they don't want Eve to know who will spend it first. They will then cooperate to construct a following transaction:

CoinJoin Transaction
    In
        [   546, Token T, 50000000] // Token T signed by Alice
        [   546, Token T, 50000000] // Token T signed by Bob
        [ 10000] // BCH for fee payment, signed by Alice
        [ 20000] // BCH for fee payment, signed by Bob
    Out
        [   546, Token T, 50000000] // Token T to Alice's new address
        [   546, Token T, 50000000] // Token T to Bob's new address
        [  9500] // BCH change to Alice's new address
        [ 19500] // BCH change to Bob's new address
    Fee    1000

This creates an anonymity set of two for every one of those outputs. Should an output later be spent, Eve will have no way of knowing whether it's Alice or Bob who's spending it, she could only be certain that it was one of them.

Alice and Bob could use the opportunity to split their token amounts into smaller denominations, and then each of those outputs would have an anonymity set of two. Of course, using any 2 together would link them to the same owner.

CoinJoin Transaction With Splitting Outputs
    In
        [   546, Token T, 50000000] // Token T signed by Alice
        [   546, Token T, 50000000] // Token T signed by Bob
        [ 10000] // BCH for fee payment, signed by Alice
        [ 20000] // BCH for fee payment, signed by Bob
    Out
        [   546, Token T, 25000000] // Token T to Alice's new address
        [   546, Token T, 25000000] // Token T to Alice's new address
        [   546, Token T, 25000000] // Token T to Bob's new address
        [   546, Token T, 25000000] // Token T to Bob's new address
        [  8954] // BCH change to Alice's new address
        [ 18954] // BCH change to Bob's new address
    Fee    1000

Notice that they both had to use a little BCH to provide the dust limit amount for those new token outputs.

When mixing tokens, we still need some BCH to pay for the fees and new outputs creation. Another way is to pre-charge the tokens with some BCH amount before creating a CoinJoin transaction, and agree to have that amount always be proportional to the token amount for any given round. Then, the CoinJoin transaction could look like this:

CoinJoin Transaction With Splitting Outputs and using only token outputs
    In
        [ 10000, Token T, 50000000] // BCH & Token T signed by Alice
        [ 10000, Token T, 50000000] // BCH & Token T signed by Bob
    Out
        [  4750, Token T, 25000000] // BCH & Token T to Alice's new address
        [  4750, Token T, 25000000] // BCH & Token T to Alice's new address
        [  4750, Token T, 25000000] // BCH & Token T to Bob's new address
        [  4750, Token T, 25000000] // BCH & Token T to Bob's new address
    Fee    1000

This way, CoinJoin wouldn't differ much from how it's done with BCH. We imagine that both CashShuffle and CashFusion servers could be extended to support tokens, with some added complexity.

Other posts in the series

Introducing Group Tokens for Bitcoin Cash - Part 1/N - Stablecoin Example

Introducing Group Tokens for Bitcoin Cash - Part 2/N - Atomic Swap Examples

Introducing Group Tokens for Bitcoin Cash - Part 3/N - CoinJoin (this)

Introducing Group Tokens for Bitcoin Cash - Part 4/N - Non-fungible Tokens (NFTs)