| Boolean heuristic | Yes | No |
|---|---|---|
| tx_extra includes encrypted PID | A | B |
| tx_extra includes unencrypted PID | C | D |
| tx_extra includes unknown field | E | F |
| unlock_time > 0 | G | H |
| decoy selection matches core algo | I | J |
| fee selection matches core algo | K | L |
| current bulletproofs format | M | N |
| … | … | … |
Notes:
F0 = ADFHIKM.F0 fingerprint does not necessarily indicate use of core software (since other wallets should mimic F0). However the appearance of a non-F0 signature does indicate the use of non-core software.length(unique({fingerprints})) provides a lower bound on the number of different types of software in use.F0 changes during some network upgrades, and is thus a function of version/time/block height.D) which returns only characteristics where the transaction deviates from the core software during that era, or returns 0 if the signature matches the core software. So in the current era (F0 = ADFHIKM) a transaction that is constructed normally except for a non-zero lock time would have a difference fingerprint D = 000G00 = GADFG3IKM indicating that the unlock time was 8 blocks. In 2020 common unlock times include 0 (core software), 1, 3, 4, and 12. Depending on the nature of your analysis it may make sense to keep the ADFG3IK transactions separate from the ADFG12IKM transactions.