Which parts of a transaction need to have what value in order for it to be stored and broadcast by the IRI?
In the IRI, packets are received in the UDPReceiver and then forwarded to the Node for processing. There is also a TCPReceiver (seldom used) and the packets follow the same process.
If the packet comes from a recognized sender (neighbor), the packet is processed.
If the packet is not a duplicate as determined by its presence in the recentSeenBytes, the packet is loaded into a TransactionViewModel for inspection, validation, storage and caching. If the packet is a duplicate, then it is ignored.
You can find the relevant code by looking for preProcessReceivedData in the IRI Node.java file and follow the process when you find this line:
TransactionValidator.runValidation(receivedTransactionViewModel, transactionValidator.getMinWeightMagnitude());
Transactions are checked to make sure:
The Hash calculates properly.
The transaction is dated no older than the last Snapshot and no
newer than 2 hours into the future.
The attachments must also be dated correctly (same as #2).
The transaction must meet the Minimum Weight Magnitude hard-coded in
the IRI node software.
It is then cached in receiveQueue and then stored in the local tangle database here as part of the gossip run-up routine.
If it has not been previously stored, the senders IP is also logged along with the arrival time.
It is then added to the broadcastQueue and to make sure the rest of the network is notified about the transactions existence, the broadcaster thread picks it up and sends it to all the neighbors.
Are all validated transactions provided as tips to other users in the 'getTips' statement?
Yes. First, all received transactions as validated above are added to the tips. These are known as non-solid tips.
When the API getTips statement is called, they are added to the tips provided here.
Rationale
The reason for these checks is first, to make sure it conforms to the proof of work anti-spam measure of the network (the Hash and Minimum Weight Magnitude checks), and second, to make sure that a reasonable bound is established to consider a transaction too old or too new to be gossiped.
Those checks are generally thwarted by the fact that POW can be pre-computed, computed very easily via FPGA (or other), and furthermore because the time on each transaction is self-reported.
At the stage of receiving a transaction, because the node is not aware of missing transactions that it has not been notified of, a received transaction can be fictitious and that fact cannot be determined upon receipt.
It is only with passing time that it will fall away as evicted because it can not be confirmed to reference a network Milestone transaction and is displaced by other received transactions. Regardless, it still consumes space in the local database and will make its rounds throughout the network.
The Milestone is absolutely essential because even if a transaction has tips that refer to many tips (long chain of transactions giving the appearance of validity), the reality is that an attacker can also construct this chain of transactions and then submit it to the network. The ultimate truth to the validity of a transaction is whether or not it references a Coordinator issued Milestone transaction.
