HIT scribbles

standard rules:
  1. # unique input scripts == # unique output scripts
  2. all output scripts unique
  3. at least one pair of outputs has equal value

alternate rules (replace standard rule 1):
  1A. # unique inputs > 1
  1B. # of unique input scripts > # unique output scripts / 2

tx 01 (standard form):
  inputs:
    0: spend from 1address1 (1 BTC)
    1: spend from 1address1 (2 BTC)
    2: spend from 1address2 (3 BTC)
  outputs:
    0: lock to 1address3 (3 BTC)
    1: lock to 1address4 (3 BTC)

tx 02 (alternate form):
  inputs:
    0: spend from 1address1 (1 BTC)
    1: spend from 1address1 (2 BTC)
    2: spend from 1address2 (3 BTC)
  outputs:
    0: lock to 1address3 (3 BTC)
    1: lock to 1address4 (1 BTC)
    2: lock to 1address5 (1 BTC)
    3: lock to 1address6 (1 BTC)

tx 03 (alternate form):
  inputs:
    0: spend from 1address1 (1 BTC)
    1: spend from 1address1 (2 BTC)
    2: spend from 1address2 (4 BTC)
  outputs:
    0: lock to 1address3 (3 BTC) # could be input (0,1) or 2
    1: lock to 1address4 (3 BTC) # could be input (0,1) or 2
    2: lock to 1address5 (1 BTC) # from input 2

tx 04 (standard form):
  inputs:
    0: spend from 1address1 (1 BTC)
    1: spend from 1address1 (2 BTC)
    2: spend from 1address2 (4 BTC)
    3: spend from 1address3 (4 BTC)
  outputs:
    0: lock to 1address4 (3 BTC) # from input (0,1)
    1: lock to 1address5 (4 BTC) # from input 2 or 3
    2: lock to 1address6 (4 BTC) # from input 2 or 3

Side-effects for CoinJoin?

Suppose Alice and Bob want to CoinJoin to create 1 BTC output each. Alice has two UTXOs available: 3 BTC in address A, 11 BTC in address C. Bob has two UTXOs available: 6 BTC in address B, 30 BTC in address D.

Their outputs will be: 1 BTC (desired spend), 1 BTC (despired spend), x BTC (Alice's change), y BTC (Bob's change).

In order to comply with the BIP and create a standard HIT so that their number of unique input scripts equals the unique number of output scripts (4), they must use all of their UTXOs. The tx looks like:

tx 05 (standard form):
  inputs:
    0: spend from address A (3 BTC)
    1: spend from address B (6 BTC)
    2: spend from address C (11 BTC)
    3: spend from address D (30 BTC)
  outputs:
    0: lock to address Q (1 BTC)
    1: lock to address R (13 BTC)
    2: lock to address S (1 BTC)
    3: lock to address T (35 BTC)

For a passive blockchain observer who notices this is BIP compliant, they will notice that there are only two ways to group this due to sudoku analysis:
{(A+C = Q+R),(B+D = S+T)}
{(A+B+C+D = Q+R+S+T)}

In other words, it's either a non-CoinJoin consisting of one party, or a 2-party CoinJoin that links A with C, B with D, Q with R, S with T, A with R, C with R, B with T, and D with T.

This seems to violate my intuition that the BIP should do no harm with respect to CoinJoin, since the transaction could have easily been instead:

tx 06 (non-compliant):
  inputs:
    0: spend from address A (3 BTC)
    1: spend from address B (6 BTC)
  outputs:
    0: lock to Q (1 BTC)
    1: lock to R (2 BTC)
    2: lock to S (1 BTC)
    3: lock to T (5 BTC)
    
Which only links A with R and B with T.