Transaction type identification

[andrewkozlik]

Update 3/5/23

'Joint transaction' to be used when not in CJ account https://github.com/trezor/trezor-suite/issues/7851#issuecomment-1476111263

Problem summary

When Trezor or the Trezor's seed is used in another application to conduct unusual transactions, Suite may display the account history somewhat inaccurately. For example some wallets might support spending from multiple accounts simultaneously in a single transaction. Recently we had a user who reported seeing a coinjoin transaction in their account history, but the transaction was quite obviously not a coinjoin, but some other sort of joint transaction, possibly a spend from multiple of the user's accounts. This issue proposes new logic for identifying transaction types as best we can.

Proposal

Terminology:

• "This account" refers to the account whose transaction history we are showing.
• "My accounts" refers to all of the accounts controlled by the user across all the devices and passphrases that the user has in Suite. Alternatively, it could be restricted to mean only accounts on the same device across all passphrases that the user has in Suite or restricted even further to mean only accounts on the same device and passphrase.

Assume that we have a transaction that appears in this account's transaction history, i.e. one of the inputs or outputs corresponds to an address derived from the account's XPUB. The transaction should be labeled as specified below. Sometimes I propose several different labels that are open for discussion and depending on what label we choose, the logic may simplify a little bit.

• If all inputs are from this account, then:

  • If all outputs are to this account, then "Sent {symbol} to myself".
  • If all outputs are to my accounts and at least one is not to this account, then "Sent {symbol}" or "Sent {symbol} to myself".
  • If at least one output is not to my account, then "Sent {symbol}".

• If all inputs are from my accounts and at least one input is not from this account, then:

  • If this account's balance increases, then "Received {symbol}" or "Received {symbol} from myself".
  • If this account's balance does not increase, then:
  • If all outputs are to my accounts, then "Sent {symbol}" or "Sent {symbol} to myself".
  • If at least one output is not to my account, then "Sent {symbol}" or "Sent {symbol} from multiple accounts" or "Sent {symbol} in a joint transaction".

• If at least one input is from my account and at least one input is not from my account, then:

  • If this account's balance increases, then "Received {symbol}" or "Received {symbol} in a payjoin" or "Received {symbol} in a joint transaction".
  • If this account's balance does not increase, then:
  • If the coinjoin heuristic is satisfied, then "Coinjoin transaction".
  • If the coinjoin heuristic is not satisfied, then "Sent {symbol} in a joint transaction".

• If no inputs are from my accounts, then "Received {symbol}".

Coinjoin heuristic

I see several ways to identify that a joint transaction is a coinjoin.

1. Wasabi uses this heuristic to identify Wasabi Wallet 2.0 coinjoins i.e. basically counting inputs and checking that 80% or more of the output denominations are standard denominations as defined here. This might be a problem on testnet, because the number of inputs rarely reaches 50. Ideally we should also add a heuristic for Wasabi Wallet 1.0 coinjoins, Samourai whirlpool coinjoins, and Joinmarket coinjoins.
2. Checking that the user is not paying more than their proportion of the mining fee + coordination fee + rounding tolerance. Again, we would have to look at the fee policies of WW2, WW1, whirlpool and Joinmarket and take the maximum.
3. Checking that at least, say, 50% of outputs have the same value as another output in the same transaction.
4. Checking that there are at least, say, 5 outputs.
5. Checking that this account is a SLIP-25 account. This is a very rough heuristic, because for example Wasabi Wallet uses the BIP-84 P2WPKH account for mixing, so if somebody imported their seed into WW, they would see the coinjoins in Suite as "Sent BTC in a joint transaction".

I like the idea of identifying coinjoins by checking that conditions 3 and 4 are both satisfied. It's easy to implement. The condition should be satisfied by all coinjoins (WW, Samourai, Joinmarket) under normal conditions and even by small coinjoins on testnet. Even if the transaction has only 5 outputs, the condition requires at least 3 equal-valued outputs to be present or at least two pairs of equal-valued outputs to be present. A non-coinjoin transaction is unlikely to satisfy this. Of course, there can easily be a transaction where someone pays five people the same amount, e.g. prize money for a 5-member team, but let's not forget that there is also the condition "at least one input is not from my account" before the coinjoin heuristic is applied.

See also

• Recent discussion on Slack here.
• Older notion page.
• Older discussions on Slack here and here.

[Hannsek]

I like it too! However, I am not sure with some of the wording. Especially "payjoin". But I don't have any other proposal right now…

[sime]

Alternative workaround, when non coinjoin account label all transactions as Joint transaction.

[sime]

Updated description to go with 'Joint transaction'.