RE: Proposed changes in the Calibrae fork
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.
I did a lot of work on Proof of Service mechanisms this back when I was doing Dawn... Mainly it functions by a chain of signatures from each party in the process, eg, client signs query, intermediary signs witness, provider signs certificate, produces result, signs, sends back via intermediary, who signs witness, and back. every party in the circuit gets a payment for doing this, so when the client gets the certificate, they ack and then send a service cert to the witnesses who then calculate the relevant reward for each party in the loop.
The part that does the antispamming function has to do with diminishing rewards when the client and server are known, by the ledger, to have business dealings. The intermediary also must not have dealings with either side aside from intermediation. If they do, the rewards are reduced in accordance with the amount of dealings between them. This prevents collusion, as at least one mechanism for implementing this.
It just reminds me of how bleeding stupid it is to let witnesses vote for each other. This clearly is collusion, no matter how honestly each witness deals, it's still collusion.
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?
I haven't the faintest idea. I just dreamed it up. Maybe what I need to suggest is you do a bit of study of law. Most of these models are directly cognate to legal procedures. Notaries, witnesses, representative/proxies, etc etc. I did a lot of study of especially the laws of bills and titles, and it's all exactly the same stuff here in crypto-land. The crypto part really is just signatures, sealing, and, sometimes, confidentiality, in digital form.
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.
It's not a simple subject, there is a lot to learn, even just basics to do with getting the build environments working. I'm sitting here at the moment, goddamned if I am setting environment variables to tell the stupid cmake where to find it's precious c++ compiler, and turns out it's only respecting me if I make soft links from the right version to the stupid default old school
ccandc++shakes head
C++ compilers really are retarded. I am gonna do the masochist thing for a good cause here, but I tell ya, once Calibrae is online, other people with more experience and C++ love can work on it, while I build a proper system in Go.
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!