Show Posts
76
TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)
« on: November 26, 2019, 01:43:13 PM »So in the spirit of my last bitcointalk post, I feel God wants me to focus in on giving the users the ability to : instantiate a treasure trove item, and see the list of treasure trove videos that have been archived (with high scalability). I have a plan to offer very high scalability even with our feeble network. Basically I plan on making a cloudflare account, and through some type of abstraction we will give the ability to archive a copy of a youtube Christian video (with permission) into a cloudflare servers mp4 storage "stream" version, so we can host the cloudflare version through DSQL. This would theoretically stay live even if google or youtube goes down - since the idea with cloudflare is to be part of the backbone of the net. More on this later.
But first, the highest priority. I feel like Satan has been running rampant through this project trying to paralyze us. I saw all these issues over the last few days, with sancs going into new start required, with gobject propagation appearing to be on the feeble side, with the bad sanc list increasing in prod (now fixed), and just in general, things I feel should not be happening in prod.
This leads me to the state we are in- we must have a solid future version that is fork free permanently, that has perfect GSC blocks, perfect gobject propagation, and none of these sanctuary expired issues, or instantsend problems etc.
So, I feel we really must slow down and fix this right now, as production support and maintenance stops new development (and gives us a black eye) etc.
In light of this Im going to stop everything to take a look again at gobject propagation, superblock heights, and how we make the calls.
What I really would like to see, is the ability for our nodes to recover by themselves onto the chain with the most work.
Im questioning whether this dirty block index rule is doing more harm than good.
My goal is to add some code to testnet that can theoretically handle a situation for example, a mandatory upgrade, where the node can auto-recover after the supermajority upgrades (in contrast to sitting on a private chain, due to having a bad block in memory).
I do support slowing down. When I upgraded all my sancs and clients were on the same testnet chain.
Today two were not running when I checked and the others were on different hashes for the same block but all sancs still appeared to be enabled on the masternode list. It should noted that previous versions could be left unattended for days.
Maybe its my VPS machines, I cannot tell, but stability has be altered since the last upgrade, whether it is due to the temporal instability in network, I cannot conclude either as there is no way I can discern the state of the network beyond the servers I control.
In addition the masternode list currently is in contrast to the non DIP3 sanc situation where the state of the network could be quickly and rather accurately discerned from the masternode list.