Assume the same address could initiate a stop command in a future block to not have his old MN clutter up the payments by never responding. However, I don't see any incentive for people to do this, so there needs to be some mechanism where the block finder can insert the stop message on behalf of the masternode. You might think the lingering nodes wouldn't be an issue, but something absolutely has to be able to issue a "stop" command in case the 1,000 DRK move. Unless you could possibly modify the protocol to have nodes reject any tx formed out of the 1,000 DRK input without a "masternode stop" command included in a prior block? If you allow for removal after X number of missed pings, you have the (tiny) vector of the block finder being able to remove a masternode if he found the right blocks, but I don't know of any incentive to do this.
Well, no, I think you're over-complicating things here. There are really kind of 2 lists: one for "valid" MNs and the other for "active" MNs. By creating an initialization transaction and putting it into the blockchain, a MN declares itself as "valid". It remains "valid" for as long as the 1000 DRK does not move. This means that it is *capable* of being nominated and receiving payment, *if* it proves itself to be "active". Upon nomination by block n, it has to ping back in or before block n+2. This proves it as being "active" and eligible for receiving payment in block n+3.
A MN maintains its "active" status as long as it keeps responding to all nominations with pings in a timely manner. If a MN does not respond in time to a nomination, it will be marked un-"active" until the next time that it responds to a nomination. That "activating" ping will bring it back to the "active" list, but it will not be eligible for payment in that block because it was non-"active" for the previous nomination. And again, all of this information will be 100% determinable in the blockchain.
Yes, I believe you are correct. It just wasn't appealing to my OCD I guess
(that it appears the initialization commands could be left "hanging" with no closure as it were; the closure would just be nodes not seeing it as valid anymore, which should be fine).
Elegant and simple. Good talk.