In the Original white paper of the IOTA there is no mention of the Milestone. In reality however, the IRI code is so tangled (pun intended) with the use of Milestones, that I was not able to run an isolated node, without having to add Milestones.
What are the (theoretical) steps to change the IRI codebase in order to remove the need for a Milestone?
From my understanding, today milestones impact the IRI at (at least) 3 (more or less critical) points :
Milestones indicate fully confirmed transactions. Without milestone the validity of a transaction must be evaluated by the proportion of tips approving it. (but this point is just impacting clients interested by the confirmation state of a transaction, and IMO is not critical regarding internals of the IRI itself)
Milestones indexes is the way to measure the sync-status of a fullnode. If your latest-solid-milestone is too old : your fullnode will be seen as "out-of-sync" by it's neighbors and they may decide to disconnect your fullnode.
Milestones are "checkpoints" where the random walk for the tip-selection can start. This is (IMO) the critical point. If you ignore completely milestones you must find another way to peek a starting point for the random walk. It is critical because the starting point of the random walk will have an impact on the convergence of the tangle. (and if the tangle don't converge, the confirmation ratio of tx will remains low... so point 1 will not work).
If I had to implement an IRI fork ignoring milestones, I would start with this kind of approach :
For point 1 : nothing special to do. (or probably just tweaking the getInclusionStates API)
For point 2 : keeping an eye on official milestones just to publish my latest milestone and latest solid milestone (and not being seen as bad node by neighbors).
For point 3 : Implementing a new concept/object called PrivateMilestone as a replacement for Milestone in the tip-selection algorithm. A PrivateMilestone would be a transaction issued by your node at regular interval. Where to attach a PrivateMilestone is of course critical.
IMO a PrivateMilestone should at least indirectly approve your previous PrivateMilestone and you should by some way ensure that your PrivateMilestones are seen as valid transaction by your neighbors (and in the end by the whole network).
("How to react when your PrivateMilestone are seen as inconsistent by the network ?" is also a critical question)
(the first PrivateMilestone should of course approve the latest official Milestone)
Another idea to choose transactions to attach a PrivateMilestone to can be to ask for "tipsToApprove" to your neighbors and building a small tree of zero value transactions on top of all of them and finally your private milestone approving the top of the tree + your previous PrivateMilestone. This strategy may improve your chances to have your PrivateMilestone approved by the network.
As you can see, my idea here is "be your own coordinator". Is it going to work ? Probably not if your neighbors run the current version of the IRI. My feeling is that some additions should be done to the official API to be able to react efficiently when the network don't approve your PrivateMilestone.
See the website FAQ regarding the purpose of the Coordinator. Milestones were mentioned in the white paper, they were called 'checkpoints'.
