Me neither. In fact I had a lenghty disagreement with Mr.Spread about exactly this point. Shortly before he left us.  

I think the way servicenodes will work is with a 2-Step procedure:

1) is a servicenode even within the "spread" and allowed to run?
(This will be limited by the maximum amount of possible service nodes (Total coins 2880 = Spread),
and if a servicenode is even willing to pay the minimum collateral necessary to secure a seat.
Minimum collateral is derived by a completely free market price discovery.)

2) After your servicenode secures a seat, does it provide the services it is supposed to provide with a reasonable quality (availability, throughput, not necessarily performance)?
If yes, good, if not, the system kicks the service node out.

Now, 1) is more important than 2), and regarding the competitive nature of the game 1) is necessary for 2) to even apply.

It is expected that people who run a servicenode will want to improve their server because it will then improve the quality of the services, which in turn attracts investors in the first place.
It is not necessary to let the protocol reward people who have access to the best server hardware (with the best performance) and hereby exclude other people who have only access to average server hardware.
(which doesn't have best performance, but still a reasonable amount of availability and data throughput)

No, it is only necessary to punish and exclude the free loaders. (people who deliberately try to game the system by installing servicenodes that get payed while providing nothing)
I think availability and throughput is more easily assessable than "performance".
What I mean with that, if a servicenode is highly available but rather slow, it should stay in the race and help contribute to the service network,
it can't be that only very fast low ping servers are allowed to play this game, because this game is not merely about speed.
There are other factors.

This really depends on the specific nature of a service.
Some need more speed, other more harddisk space, others more availability, etc...

So: no, there will never be a node score that is partially based on how many coins you have on your account.
There will be scores alright, but like some kind of policing mechanism the score is only here to strictly control if the service nodes are playing by the rules or not.
Scores are not here to reward those who offer a better service.

So to go back to the 2-Step procedure:

1) Competitive Pricing mechanism (how much are you willing to pay?) ---> Completely freely moving parameter.
2) Strict policing to exclude free loaders (are you playing by the rules or not?) ---> Strict boolean value of true or false

2) doesn't need to influence the competitive nature of 1)
2) is just a switch, while 1) is a spread.

And most importantly only 1) is tied to the amount of coins you have in your servicenode.
2) doesn't give a sh*t if you have 10000 SPR or only 100 SPR in your wallet.
It will judge you no matter what.


EDIT: An example:

Suppose we have a service application codenamed "Spread the Search" which acts as a decentralized search engine.

Now, to decide if a servicenode plays by the rule we could introduce a general rule like:
"is the servicenode crawling and indexing atleast 10000 websites a day?"

If no, the servicenode is kicked out.

If yes, the servicenode is not getting additional rewards if it crawls 20000 websites a day, because this is not necessary.
No, it will simply have passed the test, no need to reward the "overachievers", because it can be expected that people will want to improve their server hardware ANYWAY,
because it will improve the service overall and therefor attract more investors.

maybe so - as far as volume is concerned - but cryptsy has one main thing that bittrex doesnt ...

and that is the autosell autotrade ability ...

#crysx

That's good!


Was thinking long term, it might not be possible to maintain that position when the going gets rough.

By that I mean higher transaction volume but also security threats. We've seen the damage that can be done verbally, SPR never had to defend it's network against attacks of all kinds. If that ever happens (and I hope not, but let's be realistic), I would expect the ServiceNodes to be first in the line of fire. My concern is that at some time in the future, it might be necessary to harden the network on all possible levels, starting with the Service Nodes. Who's to say that there could be vulnerabilities with Instant Transactions (high value transactions being approved without enough coverage by the lower nodes and no reversal possible in case of fraudulent transactions) and the system gets exploited through the weakest links?

Food for though but as I said, these are longer term concerns, I'd like to see how it plays out in the immediate future after Service Node launch.

 

you are absolutely correct ...

we mine there occasionally when spr is short ( or donating as is the case at the moment ) ...

private pool for complete trust with miners ...

and a damn good pool i must add also ...

#crysx

Could somebody explain this to me like I am a 7 year old?  What is the problem with pre-determining that a person needs a set number of SPR to run a service node?  Lets look at it another way, given that Dash has had a 1 yr head start in effect, has their 1000DRK requirement taught us anything that we need to learn from?

On another note, I can't wait for testing to begin again.  

The 1000DASH requirement was to prevent people setting up farms of nodes and compromising the network.

It is a good deterrent, in that regard.

Perhaps there should be a relative value, but that gets complicated.

The 1000DASH also gives price stability. People hoard coins to create masternodes, which means you don't get coins dumped on the markets everyday.

Cutting the rewards to miners also reduces the mine-to-sell emissions. Miners are rewarded because the coins they do get have higher values. The ecosystem works well with miners relying on servicenodes to provide a good service, so the miners grumble but they need nodes to keep the price high.

If you are going to lower the entry price, I would think about the above. I would also think about making nodes difficult to manage so that it would become a matter of practicality to manage more than 100, 200, or 600 hundred.  But take into account that there are people now who provide node management services.

I'm not asserting a position, just looking for points for discussion.

Thanks, much appreciated.  

I need to think about this some more.   I don't understand how having a variable "entry requirement" prevents those with more money than us from buying more SPR thus reducing available supply and driving up price.  Either approach seems to lead down the same road.  

I'm not suggesting that is a bad thing, its just that I'm trying to figure out in my mind how to draw up a table showing the pros and cons of both methods.  Servicenodes/masternodes both take coins out of circulation and both reduce supply to a certain extent.

BINGO.  I get it.  I really am thick sometimes.  I'd delete the above but I thought I might as well show my (lack of) thought process.

I was about to ask what if SPR rose to $20?  In essence it wouldn't matter by using the SPR approach.

I'm finding it hard to stop thinking like a one time darkcoin baby-whale.  If somebody told me that my lets say 50 masternodes could be happily providing a good service but then the threshold to be selected for payment changed so that my masternodes would need 1007DRK I would be freaked.

I apologise for taking ages to get my head around this.  I am a disciple of the DRKside.

Exactly, only that Servicenodes are more flexible.

1) You are allowed to even take 20000 SPR out of circulation with SPR, not just 1000 (as with DASH).
(but the more people do that, the less SPR are left, so the remaining people can run a servicenode with much fewer SPR than they could before.)

2) On the other side of the spectrum you will always see people who will succesfully run a servicenode with just 100 SPR...

That's why we call this coin SPREADcoin ...  

I'm trying to get my head around this auction to get a servicenode concept, or more specifically, how it will work in practice.  

I have a servicenode, but someone can jump in my place and kick me off the network?


I am looking, honest

Only if you are the weakest link. And this can only ever be 1 specific servicenode at any give time, no matter if we have 500 or 5000 servicenodes active.

Depending on how we implement service nodes, there might only be a kicking happening every block time, so every minute, if ever.
A kicking always requires a newcomer, yes.
If there are no newcomers trying to "register" a servicenode, there will be no kicking.

And your Node can easily be reactivated (maybe with a certain time penalty, depends again how we implement this)
if you are just willing to add enough SPR to your wallet so that you are again "well within the spread"...

"well within the spread"... I like the sound of that...