In the IRI software, the Node class controls broadcast, replies, etc., and uses weighted queues to control the priority (order) of those operations.


Given that Milestones are typically the same Minimum-Weight-Magnitude (MWM) as the network specification at any given point in time, if someone SPAMMED many higher MWM weighted transactions:

Would it be possible to interfere with the diffusion of Milestone transactions by continually suppressing them to the bottom of the queues?

Would it be possible to even have them kicked-off altogether as the queues might need to be trimmed to size?

Would it be possible to interfere with the diffusion of Milestone transactions by continually suppressing them to the bottom of the queues?

This might be possible. Increasing the Minimum-Weight-Magnitude (MWM) of a transaction suppresses the queue position of Milestones in Node, and it also suppresses the gossiping of every other lower MWM weighted spam or value-carrying transaction.

However, due to an overewhelming P_SELECT_MILESTONE probability and the constant and ongoing inventorying of tips and cataloging of missing Milestones, the system greatly prefers to request a missing Milestone before all other things. See 'The Catch` below. That being said, is it possible?

How Does Internet IO Speed Play A Role?

This is exacerbated by internet connection speed dynamics. For example, if the user's node is on a home internet connection, where the download speed is often 10 times the upload speed, the rate at which the node can receive and process incoming packets will be far greater than the rate at which it can broadcast.


public void broadcast(final TransactionViewModel transactionViewModel) {
    if (broadcastQueue.size() > BROADCAST_QUEUE_SIZE) {

The result is that packets to broadcast will queue up and process slowly. As the higher weighted MWM packets arrive, they will eventually take over the queue because overfilling results in the dropping of the lower MWM ones first.

Effect on Other Essential Transaction Processing Mechanisms

The exact same thing happens in the replyQueue here and recieveQueue here.

This also means that the transactions to process can be bumped and then they can possibly be prevented from ever being stored in the local database.

The transactions to process runs on a dedicated thread. So the processing of them is likely to be very fast, however it the database is locked due to other API calls, it is possible that processing can fall behind and the queues can fill up.

The Catch

See Pertaining to the required sequence, how can the requested transaction hash be the same as the received transaction hash? , the

As discovered down the rabbit hole of getting that question answered, there is an elaborate system to prefer the broadcast of Milestones when they are detected and found to be missing from the system.

Putting It All Together

Since the attacker knows that the network is prejudiced against lower weighted transactions, they will strategically increase the MWM of their attack to ensure that it takes over the places in queues where ordinary users and IoT devices transactions are held pending processing and broadcast. Not only can they prevent the proper functioning of the network, they can also give their hashpower a strategic advantage.

The attacker can also rely on the amplification of the network to their advantage. Since every node has exactly 7 neighbors, the upload speed of the attacker is now magnified 7 times after the first gossip generation. So even if the attacker is on a slow upload, their packets can be rushed to market by the rest of the network.


Assuming that the network nodes are standard IOTA Foundation nodes, and as such favors Milestone retrieval and broadcast above all other things, the attacker would have to ensure that:

  1. As few as possible of their Transactions reference recent and Milestones

  2. They generate enough spam transactions to ensure that other packets (Milestones and Transactions that reference Milestones) are kept out and to a minimum.

Given that (1) P_SELECT_MILESTONE is only 70%, and that (2) the user bandwidth favors reception over broadcasts, and that (3) the network already consists more evenly of transactions that don't reference a close Milestone, I think it is PLAUSIBLE that this attack still works.

  • This covers the "push" part of the networking, what about the "pull" one? Catching up nodes still get very old milestones from somewhere despite of these milestones not sitting in the neighbors' queues. – Come-from-Beyond Jul 30 at 6:40
  • For sure. This is just one aspect. Wouldn't the push mechanism still be the preferred and most efficient route instead of requests and replies that also need an extra packet sent? Milestones have a timeliness to them and an urgency that comes into play. – Austin Powers Jul 30 at 7:49
  • 1
    If a single transaction with high MWM references a recent milestone then the milestone will be pulled pretty quickly. Or not? – Come-from-Beyond Jul 30 at 15:42
  • Is that a question? – Austin Powers Jul 30 at 15:44
  • 1
    I didn't mean P_SELECT_MILESTONE, but I probably should just provide my own answer when I find time for that. – Come-from-Beyond Jul 31 at 7:18

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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