As with anything these are my thoughts and don't reflect the entire foundation. Just answers off the top of my head to some of these issues.
Good input, thanks. A few quick responses:
<
The goal for me would be for a delegate to break even at a minimum...Right now I think the network would run a baseline cloud server that would run roughly $5-$10 per month.... >
Agree. Prior to DPoS going live, I would urge you guys to put out a PDF that discusses in checklist detail how to establish a plain vanilla Crypti node at your preferred cloud server vendor and the estimated cost of doing so. Even if you don't enforce a uniform hardware / software node setup policy, you should at least document your ideal baseline that potential Delegates could copy if they wish.
<
... My goal isn't to make delegates rich or have someone start from 0 XCR and become a Cryptillionaire by running a delegate.... >
Totally agree. Being a Crypti delegate should be seen as a public service gig, not a boondoggle.
<
...So DDoS issues from spam I don't think are the issue. The real issue is just over-bloating the BC... >
Agree. Blockchain bloat / pruning is the key factor needed for long-term survival of a cryptocoin and (I think) nobody has demonstrated this yet. Being the first to do so would give Crypti a HUGE boost.
<...avoid adding a zero block to the blockchain if there is no transaction activity for a given time, this reducing blockchain bloat...
I have discussed this in depth with Boris and he does not believe it is safe to implement a feature like this....right now we have very important core features to implement that I think are a higher priority. >
I certainly am not going to second guess Boris and I understand you've got priorities way beyond implementing this right now. However, as an outsider, it just seems like a DPoS system is ideal for this method of reducing blockchain bloat. A rogue Delegate can create a rogue block at any time. Surely it is somehow up to the oversight and agreement of the majority of the remaining Delegates to prevent a rogue block from causing a fork. I don't see how a DPoS system can successfully prevent a rogue block from causing a fork during nominal continuous link forging ever 30 seconds and yet not prevent a rogue block from causing a fork if a "no block during dead time" algorithm were added to the current system and agreed to by all Delegates. Looks like the logic would be cut-and-paste identical. But I'm no programmer and I guess that's another topic for another day.
<....temporarily halt forging when the blockchain hits a certain length and forge a new Genesis block that is cryptographically signed as valid by a large majority of Delegates...
This is also tricky but is something we have been looking into for quite some time.>
Just don't let this admittedly hard feature fall thru the cracks while you deal with the much more important issues right now. Ultimately this is one of the most important things Crypti could implement and would be a revolution in the cryptocoin world.