WireTransaction.<init> - corda

corda / net.corda.core.transactions / WireTransaction / <init>

# <init>

`WireTransaction(componentGroups: List<ComponentGroup>)`
`WireTransaction(inputs: List<StateRef>, attachments: List<SecureHash>, outputs: List<TransactionState<ContractState>>, commands: List<Command<*>>, notary: Party?, timeWindow: TimeWindow?, privacySalt: PrivacySalt = PrivacySalt())` `WireTransaction(componentGroups: List<ComponentGroup>, privacySalt: PrivacySalt = PrivacySalt())`

Old version of WireTransaction constructor for ABI compatibility.

`WireTransaction(componentGroups: List<ComponentGroup>, privacySalt: PrivacySalt, digestService: DigestService)`

A transaction ready for serialisation, without any signatures attached. A WireTransaction is usually wrapped by a SignedTransaction that carries the signatures over this payload. The identity of the transaction is the Merkle tree root of its components (see MerkleTree).

For privacy purposes, each part of a transaction should be accompanied by a nonce. To avoid storing a random number (nonce) per component, an initial privacySalt is the sole value utilised, so that all component nonces are deterministically computed.

A few notes about backwards compatibility: A wire transaction can be backwards compatible, in the sense that if an old client receives a componentGroups with more elements than expected, it will normally deserialise the required objects and omit any checks in the optional new fields. Moreover, because the Merkle tree is constructed from the received list of ComponentGroup, which internally deals with bytes, any client can compute the Merkle tree and on the same time relay a WireTransaction object even if she is unable to read some of the "optional" component types. We stress that practically, a new type of WireTransaction should only be considered compatible if and only if the following rules apply: