A simple attack vector: split the chain, let the "original" chain have whatever round-trip delays it has.
Create a second, "fake" chain with slightly longer delay "values" written into the blocks (since you control the software of all the nodes of the fake chain, you can simply overwrite the values of round-trip delay).
After a while, you'll have a fake chain available that's got blocks with longer delay times, but you have it earlier than the original chain.
You can then simply replace the original chain at the exact point in time when your fake chain is "plausible".
Haven't really thought this through, so far, but I guess it's a viable attack vector to consider.
I think you have misunderstood the paper. Don't worry i will explain.
Only changing the delay value in the block does not make it valid because nodes have to send the block with same round-trip delay(or latency) to other nodes.
Suppose an attacker forks the chain at block "X" and some blocks have been added after block "X". Attacker chances will be very low because even if attacker sends the blocks with highest round trip delays possible he will not be able to catch the main chain as the blocks are kept adding on the main chain.
That's why you'd have to create a "split" in the first place.
You have two separate networks, the fake one
will accept my fake blocks, since it runs entirely on my nodes, with my software.
The consensus mechanism will then merge the fake network and the real network once they come into contact again, applying the consensus rules, which will result in the longer chain (in that case the fake chain) being accepted as the real chain, thus orphaning the original real chain.
