4

Which parts of a transaction need to have what value in order for it to be stored and broadcast by the IRI?

I know that there are some bundle level conditions like

  • valid signature
  • sum of all values is 0
  • ... ?

and some transaction level conditions like

  • POW was done
  • ... ?

I've also heard something about timestamps needing to be within a certain range. True?


What other conditions are there?
Is there another level i.e. what happens to transactions that have trunk/branch transactions that don't exist (yet)?
Where can I find these checks in the IRI's source code?
I know this is a long shot but is there any documentation on it?

  • If there are no levels, how is "valid signature" and "sum of all values in bundle is 0" checked? (You didn't mention it in your answer, otherwise very nice answer - thanks) – Zauz Jul 7 '18 at 10:09
  • 1
    See also iota.stackexchange.com/questions/40/… for validations that happen after the transaction is accepted (and that validate the bundle). Note that these validations do not prevent the transaction from being transported by the network, but they prevent it from being chosen as a tip (and therefore confirmed). – mihi Jul 8 '18 at 11:45
  • @mihi Thanks! That's exactly what i was missing. Now everything makes sense again :+1: – Zauz Jul 8 '18 at 12:35
2

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:

  1. The Hash calculates properly.

  2. The transaction is dated no older than the last Snapshot and no newer than 2 hours into the future.

  3. The attachments must also be dated correctly (same as #2).

  4. 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.

  • Regarding concerns raised in last paragraphs: local modifiers in the tangle is suggesting an approach to mitigate the effect of precomputed side-tangle attack. (in 2 words: the idea is to take into account the appearance timestamp to penalize transactions with suspicious timestamp/attachment-timestamp in the random walk) – ben75 Jul 7 '18 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.