one. The tracking of premined vests should not be difficult. They all have a chain of hashes linking them together. Standard double entry ledger blockchain systems have a root, an initial creation of the token, and every spend has a chain that branches into a tree. From a calculation perspective it is easy to just count them for the rewards pool, but to make sure they are removed from the eventual places they end up in their terminals, the whole tree has to be built.
five. Yes, you have a point about how this changes the vote scores, but this only happens when the witness activates and deactivates, and only affects the ranking. It's just another event that triggers a vote rank recalculation, just like any vote change, so it's not a big change. If a witness goes offline, its non-witness vote pattern is returned, same as if it was manually changed. It enforces the impossibility of direct collusion via the use of vote withdrawal as a blackmail method.
six. The timeline on on quorums is naturally created by the reward scheme, and 1 week is plenty of time for people to structure their votes. It could perhaps be simpler to implement it as a special post type, where first a specific user account (like @calibr.ae or something similar) automatically makes a regular post at a given date and time, and each comment contains a proposal from a user. The post that gets the highest reward then becomes the mandated next HF proposal, the dev team implements it, and the witnesses update, or not, to the relevant tag, rebuild, restart, replay, and if over 13 switch, it becomes consensus, and any nodes in the top 19 are pushed out of the top 19 until they update.
These proposals don't all need to be implemented, but I think the sanitizing and self-vote rules must be in the fork. I'm pretty much not going to budge on those two issues because they are such simple examples of nPD.
As for rewarding RPC, for service, this requires a proof of service protocol. It may add a little overhead, as I think it would require intermediaries who act as witnesses in the transaction, and there has to be rules about what constitutes a payable service, and what is spam. I have already done a lot of work towards elaborating a protocol for this.
I understand the basis of your fork is moral, and respect that.
I'd be interested in what you've done on proof of service and spam identification.
It sounds clever. I still haven't quiet got my head around the architectures/flows of these decentralised cryptographic systems. It's quite a leap from the data analysis work I usually do!
I feel like I need to read some books or watch some tutorials/lectures on it to be honest. Any suggestions?
Well, you, and a few other very smart people ;)
I see what you're saying about the models corresponding to legal processes though - good point. I probably need to familiarise myself with some cryptocurrency systems source code too when I've time.
I'm sure your sacrifice will pay off one way or another! I've only ever worked in C++ to do computer vision work when the Python bindings weren't fast enough... not pleasant!