Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - njs811

Pages: [1] 2 3 4 5 6
1
I voted 2c as in, yeah I'm fairly certain we'll at least hit that at some point given my positive outlook on successful servicenode implementation and liquidity drying up as staunch supporters like myself continuously buy fairly large amounts fairly cheaply.

The problem is without continuous updates, transparency, or at least a somewhat tentative road map from the development team, investor confidence will begin to waver.  We're not the only coin looking at masternodes anymore.  In fact, it's looking like bitcredits and crave may have them out far sooner than our next round of testnet.  However, I think if we can roll out servicenodes with instant transactions in the next few months, the sky is the limit and would give the development team a tremendous amount breathing room and time to look at other implementations for service nodes as the dynamic masternodes and ease of set up would be more than enough incentive to bring in a slew of new investors.  Especially considering how inexpensive it'll likely be to run a service node, at least initially, compared to the alternatives.

It seems like the development team is concerned with making the project perfect before implementing servicenodes. I say we should put them out then work on bugs. DRK has been doing that for the longest time and look how they are doing.

2
I think the poll could be improved by including a time frame.

3
Main Development / Re: Moneysupply Calculator
« on: March 28, 2015, 05:58:57 am »
Ok, fixed reward halvings to be every 2 000 000 blocks instead of 2 102 400.

I am also trying to understand this line in main.cpp;

nSubsidy -= nSubsidy*(nHeight % g_RewardHalvingPeriod)/(2*g_RewardHalvingPeriod);

What does -= mean?  Does it mean nSubsidy=nSubsidy-*(blah blah blah?

Also, what does the % do?

Is this the same as:

nSubsidy=nSubsidy-((g_RewardHalvingPeriod/2)/g_RewardHalvingPeriod)

I am trying to reduce nSubsidy for each block in my calculator.


What does this whole thing mean;

Code: [Select]
int halvings = nHeight / g_RewardHalvingPeriod;
nSubsidy = (halvings >= 64)? 0 : (nSubsidy >> halvings);
nSubsidy -= nSubsidy*(nHeight % g_RewardHalvingPeriod)/(2*g_RewardHalvingPeriod);
a -= b means a = a - b.
% is the modulo operation.
>> is a right bit shift, it multiples number to the left to the negative power of two of the number to the right.
Ah ok, The modulo operation is the remainder when dividing the left number by the right number, right?
I'll fix my calculator with that modulo operation.
I also need to reprogram the graph rendering. It'll be done in the next few days. But its not like anyone cares anyway. :/

You are doing good work. Thank-you.

4
Main Development / Re: Implementing ServiceNodes
« on: March 26, 2015, 05:36:39 am »
That's really not easy, mate. It may take years to learn how to code c++. I guess it will be much easier to crowdfund and hire a dev.

I'm not looking to take over spread coin. We have perfectly capable devs in control as of right now. I just want to learn more and need a place to do it.

5
Main Development / Implementing ServiceNodes
« on: March 26, 2015, 02:21:01 am »
I apologize in advance if any of you are annoyed at my lack of knowledge.  As I mentioned on Bitcointalk I went through a C++ tutorial and I am highly interested in how the coin world works.  So I am looking for suggestions from everyone so that I can further my understanding of how Spreadcoin works.  I would also like it if someone were to explain the steps we would need to take to implement ServiceNodes. My goal is to one day be a decent dev and I know that I have a long way to go. I would greatly appreciate any input from the community to help my journey. 

6
Main Development / Re: New members of the SpreadCoin development team
« on: March 17, 2015, 01:30:22 am »
hmm, guys!  i see this masternode name is a big bikeshed...  :D

Names can make or break a product. While it may seem like a bike-shed it could play an essential role in how the coin develops.

7
Main Development / Re: New members of the SpreadCoin development team
« on: March 17, 2015, 12:58:28 am »
The problem I have with servicenodes is that it does not tell us what it us. The new comer will have to be taught what it is. If we say servernodes that at least gives the general public a vague idea. We have to give this coin the most user-friendly image we can. That is what attracts people.

But isn't the name servicenode EXACTLY telling anyone what it does and what its task is?
It does that even better than the word servernode: a servicenode is here to provide services.

Emphasis on services.

But in the end, the difference between server and service is miniscule, it's the difference between a noun and a verb:
Fisher ---> Fishing
Baker ---> Baking
Server ---> Service

I certainly see your point and I am not set against the name.  Personally I would choose between servicenode or servernode. So if one gets picked over the other I wont dump and throw a fit.  My biggest interest right now would be a time table that we could establish and release to the public.   I do not want to push development (God knows that always ends badly).  In order for SPR to see good growth we need to have slight cost inflation over an extended period of time.  My biggest fear is that we will get everyone excited about ServiceNodes and then they hear nothing about it for three months.  If that is the case then the price will be, at best, stagnation. We will see people trying to invest, then dumping after a short period of time.  As a best guess, what is the latest we could see full blown ServiceNodes?

8
Main Development / Re: New members of the SpreadCoin development team
« on: March 16, 2015, 08:13:11 pm »
There are far more effective ways of recruiting community engagement than a beauty contest without criteria.

Feel free to encourage community engagement in whatever way you think might succeed.

I'm not quite sure where we are on this. Is it broadly accepted that labelling is a usability issue and that documentation is not an answer?

Exactly, that's why I went with the most generic labeling I could think of.
Since our "masternodes" don't really do anything at the moment, we should address them as "servernodes" or "servicenodes",
atleast for now!
Just to leave the door open for what those nodes are going to be in the future.

Maybe a name like "servicenode" is automatically also the best name for the future.

Listen, all this serves only the purpose of making us stop using the word "masternodes".
That's basically the only reason I made the poll, to raise awareness of this problem. (darkcoin/dash trademarking etc)

The problem I have with servicenodes is that it does not tell us what it us. The new comer will have to be taught what it is. If we say servernodes that at least gives the general public a vague idea. We have to give this coin the most user-friendly image we can. That is what attracts people.

9
Perhaps the word "nodes" is too close. What about spreadservers?

Well, nobody owns the word "nodes", so why bother.

Just thinking of ways to distinguish ourselves.

10
Main Development / Re: New members of the SpreadCoin development team
« on: March 16, 2015, 05:32:37 pm »
What mistakes are you seeing?

Would take too long to explain in detail, my background and experience gives me a view that's radically different from most. With all due respect to georgem's initiative in setting up a poll, all such informal exercises conducted on bulletin boards are simply ill-founded and produce results which are indistinguishable from a purely random choice. The people being polled are an unrepresentative sample of the user population and the poll results will be inevitably skewed by that factor. Finding acceptable and properly meaningful labels for technological features is not a trivial matter and is far too important to usability to be abandoned to a skewed plebiscite.

Now we've got a bunch of people who think the feature is going to be called "spreadnodes" which is a bit of a disaster for usability because it gives the user no help whatsoever in creating a shallow but functionally adequate model of the underpinning tech.

There was never a question in the first place: there is no branding programme in process, so there are no branding issues to consider, it is a usability issue plain and simple and so the answer is “service node”. Anyone who wants to launch an informed challenge to the analysis is perfectly free to do so and I would welcome the chance to refine our notions.

I think I'd challenge the consensus with: “Great, you’ve collectively chosen ‘spreadnode’. Now your task is to write the user documentation for this feature in such a way that new users can trivially comprehend the notion. It’s a shame that you didn't choose ‘servicenode’, that would have made the documentation task so much easier.”

Cheers

Graham

In the documentation, we could just firsthandedly mention that "spreadnodes" are just code-name for "servicenodes"  8)

A simple yet effective answer.

11
Perhaps the word "nodes" is too close. What about spreadservers?

12
Main Development / Re: New members of the SpreadCoin development team
« on: March 16, 2015, 05:07:21 am »
Just look at the price of DRK. Wouldn't it be a fantastic accomplishment if we could reach that level? Yet they still deal with FUD on a daily basis.  It stinks to sift through, but we are a strong community with a good coin. We need people to know that we can take whatever punch is thrown at us.

//And I am in support of the name Servernodes. It's self-explanatory to the everyday user. Instead of instantx what about quickspread?

Maybe we can abandon this whole instantx algorithm and make our servicenodes/servernodes (can't yet decide what sounds better, lol) do something completely different?

I definitely second that idea. If we continue with instantx it will seem like we are following DASH.  InstantX is a neat idea, but it's such a small idea in comparison to the possibilities.

13
Main Development / Re: New members of the SpreadCoin development team
« on: March 16, 2015, 01:57:35 am »
Just look at the price of DRK. Wouldn't it be a fantastic accomplishment if we could reach that level? Yet they still deal with FUD on a daily basis.  It stinks to sift through, but we are a strong community with a good coin. We need people to know that we can take whatever punch is thrown at us.

//And I am in support of the name Servernodes. It's self-explanatory to the everyday user. Instead of instantx what about quickspread?

14
Main Development / Re: New members of the SpreadCoin development team
« on: March 15, 2015, 08:03:04 pm »
In addition, I could try to arrange for a PR storm once MNs are ready to be pushed to the main network.
a PR storm would shoot the price up drastically. I look forward to this day.

The trouble is, there's no evidence to suggest this will be the case. A PR storm will need to promote qualities of the coin - where are you going to start: “no pools”? Can't use that. “Instantx”? Can't use that either, DASH intends to trademark the term. “Masternodes”? ditto. No, the appropriate time for a PR release is when there are solid, currently-exclusive tech advances for people to talk about and riff off; PR material is for use by others and they need the story explaining to them in words of not more than two syllables.

I'm ambivalent about continuing my engagement with Spreadcoin, I'm seeing the same mistakes being made and I'm beginning to wonder whether it's worth the effort.

Cheers

Graham

What mistakes are you seeing?

15
Main Development / Re: Mr. Spread
« on: March 15, 2015, 02:05:58 pm »
Who is launching the new ANN tomorrow?
I will.

It's way too early for an ANN, there's nothing substantial to communicate as nothing has been decided or organised.

Cheers

Graham

It's not about having anything substantial. Mr. Spread had complete rights over the last ANN. Which means we can't change anything.  The community needs to see that we have new developers and are moving forward. To me that is substantial. 

Pages: [1] 2 3 4 5 6