Structural traits of a transaction
The construction details Forensia reads off a Bitcoin transaction, stated exactly as the checks are implemented.
#Plain languageIn plain terms
Different wallet programs build transactions in slightly different ways. They set optional fields differently and order things differently. Those habits leave marks.
Forensia lists construction details it can read from a transaction. These do not identify a person or a wallet product. Missing fields are reported as unknown, not filled in from an address or a guess.
#How it worksHow it works
Four kinds of detail (version, lock time, replace-by-fee signalling, and the order of outputs and inputs) are read directly from the transaction and reported as a list of traits.
#Technical detailThe exact rules
| Trait | Rule as implemented |
|---|---|
| Version | Reported only when the field is a signed 32-bit integer; otherwise unknown. |
| Lock time | Zero means no lock time. Nonzero lock time is disabled when every input sequence is final. A height-based lock time is flagged as a possible anti-fee-sniping pattern only when an input enables it and confirmation height minus lock time is between 0 and 100 blocks. Intent is not established. Unconfirmed transactions do not receive this heuristic. |
| Replace-by-fee | Any valid unsigned 32-bit sequence below 0xfffffffe establishes explicit signalling. Absence is reported only when every sequence is present and valid; otherwise unknown. Coinbase is not assessed. |
| Output order | With at least two outputs, compare exact integer satoshi amounts, then script bytes for equal amounts. Every amount and script must be present and valid. An empty script is a valid byte array; a missing script is unknown. |
| Input order | With at least two non-coinbase inputs, compare previous transaction IDs in display-order hex, then numeric output index for matching IDs. Missing or invalid outpoints mean unknown. Addresses are not sorting keys. |
Lock time is a field that stops a transaction being included before a given block. Some wallets set it to the current height to discourage a specific mining attack; that habit is what the anti-fee-sniping label refers to.
Open Transaction construction details to see the fields and any unknown checks. The same explanation, source reference and limitations appear in the Markdown report. Ordering labels describe the retrieved sequence only, not the wallet's signing rules or adoption of a standard.
The finding keeps the identifier finding:bitcoin-wallet-fingerprint, class observed, with methodology bitcoin:wallet-structure-traits version 2.0.0. It is produced for new transaction lookups only. Previously saved captures retain their original findings and methodology; run a fresh lookup to use the updated checks.
#LimitsWhat it does not tell you
These checks describe fields, not identity, intention or node policy:
- Explicit signalling does not guarantee replacement. Unconfirmed ancestor signalling and current node replacement policies are not checked.
- Matching BIP69 order can occur by chance; it does not identify wallet software or validate the transaction's signatures.
- Lock time near confirmation is a heuristic, not proof of anti-fee-sniping intent. Timestamp-based, disabled, unknown-activation and future-height cases do not receive that label.
- A transaction can be built by hand to imitate any combination of traits.