Quote from: daemonfox on July 29, 2017, 02:15:39 AM

The previous thread lock seems questionable but alas this is the "host" so, their house.

GL with this thread lol!

Not that I am anywhere near qualified enough to code such a thing... but wouldn't the node requirements and the entire network benefit from a more flexible set of parameters that helped match coin totals and actual process power to those coin allocations?

Follow me here... all the 42 coin node requirement does is allow for a SPAM net of nodes with the MOST MINIMAL resources available to hook in and completely flood it with barely on par performance. I do not know the entire ins and outs of the node proposal... but it would seem to me if it is any nodes chance at any time to calc and submit encrypted transactions, then mostly the high I/O nodes will win out every time, so very quickly all your SPAM net nodes can't profit and die. Now that leaves more expensive hardware based nodes, which likely also means they are being run by those with means to supply enough ZEN to create their own army of high I/O nodes. That creates an environment where your everyday community member can't compete and you end up with a small set of nodes to prop up your growing network. Even if you kept a running order of which node gets to calc the next set of encrypted transactions... that is additional P2P overhead required to do so and still allows a small subset to own node income. It just seems counterproductive to the desired end goal.

Maybe I have no fucking clue what I am saying, but I had an idea to share and if it has merit, please run with it.

Nodes should have SEVERAL coin value thresholds. These thresholds should also be pinned to some sort of benchmark for the encryption of transactions by nodes which will score that nodes I/O throughput . Set ranges for the benchmark scores and allow a HIGHER coin amount on those higher tiered I/O nodes to give them higher priority in the processing order, but only give them the priority of the actual coin amount held. Couple that with a check to see what that node last did over 24 hours or X blocks before allowing it to do so again.

This would add a POS weight type design to this, giving all nodes equal chance I believe... tracking only their last known weight or w/e the measurement would be.

Example:

NODE 1 has say, 500 points on the benchmark which only allows it to participate at level 1, 42 coins minimum and no further coins will give it weight.
NODE 2 has say, 1000 points on the benchmark which allows it to participate at level 2, 42 coins minimum and 84 coins max and it has twice the weight potential but no further weight for more coins.
NODE 3 has say, 10000 points which allows it to participate at level 5, 42 coins minimum and 210 coins maximum allowing it to have five times a level 1 nodes weight potential.

In my mind this performs two very important things:

1. Less BS tiny nodes with par performance fighting and causing a huge, possibly laggy network of tracked nodes to accomplish the network goals.
2. Invites REAL hardware backed players to build quality nodes instead of quantity, fostering a positive environment that offers those who want to invest, a safe and scalable way to do so within a node.

While I know more nodes sounds better... that was for old coin algo design. I do not see a flood of cheap nodes benefiting this project in the long run. So give some bigger hardware players room to scale while guaranteeing the smaller players can still earn.

It is a delicate balance so I will not pretend any of what you are doing is easy. The above is just one of those AHA moments I thought worth sharing.

Thanks for giving this some thought! Avoiding having a bunch of cheap nodes that don't help the network is definitely part of the design. We are having active discussion on this thread at the ZenCash forum:
https://forum.zensystem.io/t/secure-node-tracking-and-payment-system-software-development-project-discussion/126/63

And if you are on the ZenCash slack you can see or participate in the testing of the node tracking software in the #developers and #securenodes thread.s