In IRI version 1.5.2, is the prevention of lazy tip selection a further entrenchment of the Coordinator?

Question

For background, please read:

https://blog.iota.org/coming-soon-iri-1-5-2-52114ca67a70

Under the hood, while doing validation, IRI will now remember the most recent milestone referenced by each transaction. This piece of information allows the walker to know right away when a transaction references the main tangle too far back in history to be acceptable. In other words, the walker can more easily detect lazy tips and skip them without further consideration, while additionally marking every tip it visits so that it won’t try to validate them again next time.

This places additional importance on milestone transactions within the IOTA ecosystem since not only are all valid transactions already required to extend from a miletone, but they are now required to reference a most recently known milestone.

This seems like a step backwards and a further centralization of the IOTA system on Coordinator issued checkpoints.

This also seems like a bad idea from a network latency perspective because any transactions that are relayed some time after the most recent milestone will necessarily need to be reattached. That creates additional unwanted load on the tangle because reattachment causes additional tips and tangle resolutions that are considered bad.

How is this justified when the direction of the network is to eventually eliminate the Coordinator?

Answer 1

I didn't check the code of IRI 1.5.2 in details, but as far as I understand, it seems that the changes in this version are really going in the same direction as the strategy of local modifiers in the tangle exposed in this paper .

The idea of "Local Modifiers in the Tangle" is to penalize lazy tips based mainly on the timestamp of reception of the transaction (purely local). This approach consider a coo-less Tangle.

From my understanding, IRI 1.5.2 is an implementation of the same idea, but in the current coo-tangle context (and this implementation relies on milestones instead of local modifiers ... but the idea and the expected effects are very similar)

any transactions that are relayed some time after the most recent milestone will necessarily need to be reattached

I didn't check the code, but the acceptable depth for referenced milestone is probably more than one (maybe a new configuration parameter ?)