SpreadcoinTalk

Spreadcoin => Main Development => Topic started by: MyFarm on February 20, 2015, 10:13:33 pm

Title: Features for a new version (round 3)
Post by: MyFarm on February 20, 2015, 10:13:33 pm
Someone correct me if I'm wrong, but based upon what I'm seeing at github, Mr. Spread left us with the sped up version of the election process.

Would anyone like to compile the builds, tweak it for round 3, and let's test it?

I have a theory on what Mr. Spread has done and if I am correct, what he left us is going to work beautifully. 
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 20, 2015, 10:24:24 pm
https://github.com/spreadcoin-project/spreadcoin/blob/mn-test/src/masternodes.h   -   the current testnet paramaters are all in here - 10 votes per block, MN reward % etc.

I have no idea if just tweaking these is enough, but I suspect it wont be that easy. I don't speak C++. Maybe elbandi or gjhiggins could help out?

Basically we need an experienced dev. If I had the skillset I would take Spread and, well, royally annoy georgem for a start...  ;D
Title: Re: Masternodes Testing, Round 3
Post by: MyFarm on February 20, 2015, 10:27:24 pm
Actually, I was mistaken.  I was looking at elbandi's patch.  I'm an idiot.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 20, 2015, 10:33:21 pm
Someone correct me if I'm wrong, but based upon what I'm seeing at github, Mr. Spread left us with the sped up version of the election process.

Would anyone like to compile the builds, tweak it for round 3, and let's test it?

I have a theory on what Mr. Spread has done and if I am correct, what he left us is going to work beautifully.

I like that.  8)

Please, if somebody thinks he's up to it, I will certainly help test it, and give my feedback.

BTW, I am working on my own fork, based on the feedback I have given in the last 2 weeks.
(slowly increasing max amount of MNs (total coins / 2880), plus a more random vote distribution that is not tied to the amount of SPR in your MN)


I would absolutely love it if we just keep on testing and tweaking different forks, this way we will all get more familiar with the internal workings of spreadcoin.

I feel we have a handful of very enthusiastic and almost ready programmers among us.



Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 20, 2015, 10:34:57 pm
https://github.com/spreadcoin-project/spreadcoin/blob/mn-test/src/masternodes.h   -   the current testnet paramaters are all in here - 10 votes per block, MN reward % etc.

I have no idea if just tweaking these is enough, but I suspect it wont be that easy. I don't speak C++. Maybe elbandi or gjhiggins could help out?

Basically we need an experienced dev. If I had the skillset I would take Spread and, well, royally annoy georgem for a start...  ;D

Please look into it, and try to figure it out!  :)
If there ever was a chance to get into coin programming, here it is, right in front of you.

And you have a willing community ready to help you with the testing.

Maybe that's what we need... the most decentralized way of doing things.

 8)
Title: Re: Masternodes Testing, Round 3
Post by: elbandi on February 21, 2015, 12:34:50 pm
The main goal for round3 test is to find the good value for masternodes (vote, election, etc).

For this we need to test a few times with different value to find the good values.
But while the community "build" the testnet, it is very slow. (1-1.5 week for 1440 nodes).

So we need a better solution, like: my masternode eat ~100M memory with 7 mnstart line. so if 10 mnstart line eat 100M

memory, 1440 "masternodes" running in 144 daemon requred ~14-16G total memory .

docker.io is a good technology to start separate processes in one system. so we can easily test the values on a "small"

environment. And this small environment has some advantage: easy and fast to setup the 1440 nodes, easy to reset the blockchain and test other mn values.
Title: Re: Masternodes Testing, Round 3
Post by: njs811 on February 21, 2015, 05:56:29 pm
HOLY SHIT this might be the most decentralized coin in existence. The code is all there. Perhaps we should make a closed forum specifically to teach each other what we know. Collectively we may have more than enough.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 06:04:53 pm
HOLY SHIT this might be the most decentralized coin in existence. The code is all there. Perhaps we should make a closed forum specifically to teach each other what we know. Collectively we may have more than enough.

Cool idea, but why closed?

I say spread the knowledge.  8)
Title: Re: Masternodes Testing, Round 3
Post by: njs811 on February 21, 2015, 06:10:31 pm
Only to discourage fud. Almost like a developers corner
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 21, 2015, 06:29:27 pm
The main goal for round3 test is to find the good value for masternodes (vote, election, etc).

For this we need to test a few times with different value to find the good values.
But while the community "build" the testnet, it is very slow. (1-1.5 week for 1440 nodes).

So we need a better solution, like: my masternode eat ~100M memory with 7 mnstart line. so if 10 mnstart line eat 100M

memory, 1440 "masternodes" running in 144 daemon requred ~14-16G total memory .

docker.io is a good technology to start separate processes in one system. so we can easily test the values on a "small"

environment. And this small environment has some advantage: easy and fast to setup the 1440 nodes, easy to reset the blockchain and test other mn values.

If you know how to do this then go for it! There's no real show stopper with the voting paramaters as they are, it's just slow. If more votes per block speed the process up that's all we really need at this point.

If future development by the community occurs though I'd really like to abandon the dynamic pricing. Imagine there were only 1440 mining slots, and the richest miners with the most hash could come along and kick out the smaller miners...

Dynamic pricing was a terrible idea from the start. Call it 1000 SPR and have done with it. Simpler code and the small guys don't get screwed.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 06:38:33 pm
The main goal for round3 test is to find the good value for masternodes (vote, election, etc).

For this we need to test a few times with different value to find the good values.
But while the community "build" the testnet, it is very slow. (1-1.5 week for 1440 nodes).

So we need a better solution, like: my masternode eat ~100M memory with 7 mnstart line. so if 10 mnstart line eat 100M

memory, 1440 "masternodes" running in 144 daemon requred ~14-16G total memory .

docker.io is a good technology to start separate processes in one system. so we can easily test the values on a "small"

environment. And this small environment has some advantage: easy and fast to setup the 1440 nodes, easy to reset the blockchain and test other mn values.

If you know how to do this then go for it! There's no real show stopper with the voting paramaters as they are, it's just slow. If more votes per block speed the process up that's all we really need at this point.

If future development by the community occurs though I'd really like to abandon the dynamic pricing. Imagine there were only 1440 mining slots, and the richest miners with the most hash could come along and kick out the smaller miners...

Dynamic pricing was a terrible idea from the start. Call it 1000 SPR and have done with it. Simpler code and the small guys don't get screwed.

I disagree but I will not stop you or elbandi from creating a fork with fix 1000 SPR requirement, and I will even help you with the testing.
In return, I ask only that you will help me test my own fork in a few days, when it's ready.

Deal?

We could even test the forks simultaneously by agreeing to use different ports and data folders, so they can run side by side.

Everybody, spreadcoin is far from dead, and I want to invite everybody here to just continue following his dream.

Is this a crisis or rather an opportunity?  8)
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 06:42:34 pm
Also,

We all agree that the testing phase we are in now, will have to be extended considerably because we will not be ready in a few days or weeks as originally planned,
but probably in a few months.


That's why I say: Yes, go on, test your fork, adjust your parameters, and let's see what happens.
I will prepare my own fork.

We shall then compare results and let the community vote which way to continue.  8)
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 21, 2015, 06:43:39 pm
georgem, have you given some honest thought to the sentence I bolded? There's no difference between letting the richest MN ops kick out the poorer ones, and letting the richest miners kick out the poorer ones. None. But if anyone suggested that only the richest 1440 miners could mine the coin there would be outrage.

What advantage to the network does rigging the setup to favour the rich and exclude the poor bring?
Title: Re: Masternodes Testing, Round 3
Post by: njs811 on February 21, 2015, 06:46:15 pm
I think voting will take to much time. This is basically a new coin with a firm foundation. Are there any decisions we could make together? Ww can debate and go forward with one mindset
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 06:48:37 pm
georgem, have you given some honest thought to the sentence I bolded? There's no difference between letting the richest MN ops kick out the poorer ones, and letting the richest miners kick out the poorer ones. None.

What advantage to the network does rigging the setup to favour the rich and exclude the poor bring?

Yes, you keep coming back with this.
I think this has been debunked 1 month ago.
The rich can't control the market if the protocol makes it easy for newcomers to enter the competition.

Mr. Spread has completely disabled the competition by giving high tSPR amount MNs voting privileges.

That is a farce. And I want to prove it to you. But not with words.
Stay tuned.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 06:52:22 pm
I think voting will take to much time. This is basically a new coin with a firm foundation. Are there any decisions we could make together? Ww can debate and go forward with one mindset

At the moment we should try and build a developer team, that understands how to read and write c++ code, how to install and run seed nodes, create genesis blocks, do the testing, build wallets and deamons for all systems, etc..

I am willing to give everybody a chance.
But we can't rush things from here on. We need to keep the testing rounds going.

Everybody is invited to show that he can create and manage his own fork and gather testers around him.

Let's do this a dozen times, and then we talk about voting and which way spreadcoin shall move.
Not now!
Title: Re: Masternodes Testing, Round 3
Post by: elbandi on February 21, 2015, 08:17:23 pm
Dynamic pricing was a terrible idea from the start. Call it 1000 SPR and have done with it. Simpler code and the small guys don't get screwed.
There is a problem with unlimited masternode: someone can create 1000-10000 masternode, and attach (slow down) the vote process...
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 08:27:35 pm
I propose to have a limited amount of MNs that slowly grows over time:

------------------------------------------------------------------------------------------------

I've been thinking about Strumpet's concern about the rich owning masternodes.  What is everyone's thought on increasing the cap to 2880 from 1440?  In my opinion that would solve the issue.

Originally Mr. Spread only wanted to use a max of 1000 MNs.

1440 max MNs was based around an idea I had that this way every MN would on average receive 1 payment a day.

I believe that having twice that (2880) will not solve the problem you describe (the problem of "how will newcomers be able to afford a masternode later in time"),
but only postpone the problem so it will come back and bite us later.

I always advocated for a flexible amount of MNs.

A limit yes, but a flexible one, that increases slowly over time.
This way it gets to act like a limit (that creates competition thru scarcity, and enables price discovery), but it will also have the flexibility to adjust for a large growth of SPR price and what an MN will cost.

I advocate for tying the max amount of MNs to the coinsupply:

Max MN = (total coinsupply)/ 1000.

or maybe divide them even further.

Max MN = (total coinsupply)/ 1440.

or

Max MN = (total coinsupply)/ 2880.

So today (with 1.865 Million coins) this would mean 1865 possible MNs, or 1294, or 647 possible MNs. (total coinsupply divided by 1000, 1440 and 2880)

This is not a fix limit, but a moving target, so let's look how this will change over time:

In 6 Months it will probably be 5000 MNs (or 3472, or 1736 MNs)....

We follow Bitcoins increase in coinsupply curve more or less.

So in about 6 years, we will have 13.85 Million coins.
How many MNs should we have in 6 years?
Based on my three suggestions, it would be 13850, or 9618, or 4809 MNs.

And what does that mean for eternity?
We will have 21000, or 14584 or 7292 MNs.
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 21, 2015, 08:30:23 pm
Dynamic pricing was a terrible idea from the start. Call it 1000 SPR and have done with it. Simpler code and the small guys don't get screwed.
There is a problem with unlimited masternode: someone can create 1000-10000 masternode, and attach (slow down) the vote process...

Not if there's a fixed collateral cost. Voting should remain, but only to kick MNs that are not providing service. If it turns out that in a years time, 5000 MNs is getting unwieldy, we can address that then. Increase the collateral required, speed/simplify MN comms, there are various ways of tackling the issue if it ever becomes a problem.

edit: Maybe +ve votes are required to make the payments-like-clockwork work, I don't know.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 08:33:07 pm
And you know what's the best thing about a rule like

Max MN = (total coinsupply)/ 2880.

?

That every test round starts with a coin supply of zero, since we start a new blockchain.
So we get to reach the max amount of MNs instantly, and get to test it immediately.

 8)

If we can generate 10k tSPR a day (without increasing the block reward by 10 as we did in test round 2)... then at the end of the first testing day there will only be 10000/2880 = max 3 MNs allowed.
This means competition kicks in immediately and stays active forever.

After 3 days the max will grow to 10 etc...

I believe that this is how it is supposed to be.

And I will show you.  8)
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 21, 2015, 08:58:18 pm
And you know what's the best thing about a rule like

Max MN = (total coinsupply)/ 2880.

?

That every test round starts with a coin supply of zero, since we start a new blockchain.
So we get to reach the max amount of MNs instantly, and get to test it immediately.

 8)

If we can generate 10k tSPR a day (without increasing the block reward by 10 as we did in test round 2)... then at the end of the first testing day there will only be 10000/2880 = max 3 MNs allowed.
This means competition kicks in immediately and stays active forever.

After 3 days the max will grow to 10 etc...

I believe that this is how it is supposed to be.

And I will show you.  8)

And how exactly are you determining MN 'fitness' without reference to the amount of collateral securing it?

The only other metric available for voting is latency, and the byzantine nature of global network routing makes ping pretty variable, and each MN is going to have a different latency to each voting node...
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 09:09:03 pm
And how exactly are you determining MN 'fitness' without reference to the amount of collateral securing it?

The only metric available for voting is latency, and the byzantine nature of global network routing makes ping pretty variable.

I don't know yet, this will be based on the services MNs provide. Since our MNs don't really provide a service yet, this is not so important ATM.

All I know is that taking the amount of collateral is the worst way of determining fitness. It's not even a solution to the problem.

It's like deciding which person gets to vote in a democracy based on their yearly income.

So not only is it not a solution, it only adds fuel to the fire.
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 21, 2015, 09:11:50 pm
And how exactly are you determining MN 'fitness' without reference to the amount of collateral securing it?

The only metric available for voting is latency, and the byzantine nature of global network routing makes ping pretty variable.

I don't know yet, this will be based on the services MNs provide. Since our MNs don't really provide a service yet, this is not so important ATM.

All I know is that taking the amount of collateral is the worst way of determining fitness. It's not even a solution to the problem.

It's like deciding which person gets to vote in a democracy based on their yearly income.

So not only is it not a solution, it only adds fuel to the fire.

Those who invest and risk more should accrue higher rewards, without excluding those with less who also wish to participate. A fixed collateral cost achieves all of this.

Evan Duffield got that absolutely right.

Masternodes are not a democracy. Mining is not a democracy. Network consensus != democracy.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 09:20:48 pm
Those who invest and risk more should accrue higher rewards, without excluding those with less who also wish to participate. A fixed collateral cost achieves all of this.

Evan Duffield got that absolutely right.

How is an MN with more money "risking" more than an MN with less money?

There is no risk involved at all. Where exactly do you see the risk?

I see it completely differently:

MNs can be secured with a high amount of SPR so that they move away from the weakest link. That's how they lower their risk of being kicked out.

MNs that don't move away from the weakest link are actually the MNs that are risking something. Don't you see?

Because they run the risk of being kicked any moment, it's THEM who should make the higher profit, not the lazy top MNs that don't risk anything.


In free economics, there is the rule, that the people who risk the most should also potentially make the highest profit.
And the people who risk only a little or nothing, are the ones that should make only a very small profit or none at all.

That's good economics, and that's why evan duffield is wrong.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 21, 2015, 09:22:53 pm
It's like deciding which person gets to vote in a democracy based on their yearly income.
Masternodes are not a democracy. Mining is not a democracy. Network consensus != democracy.

You are right. Democracy is the wrong word here.

I prefer anarchy.

51% is a good thing in democracy, but a bad thing in crypto.

So yes, call it anarchy. I love it!

But even in an anarchy (or free market without government regulation) you get to vote, by deciding where you want to invest your money.

That's the best voting that exists: deciding with your money: Do you like a service or product? Buy it. If not, don't buy it, and if nobody buys the service/product it's like a voting process that tells the company that they are incapable and will go bankrupt.

In democracy the voting process is basically useless, because you just get to vote for what puppet politician will get to rule over you. lol
Title: Re: Masternodes Testing, Round 3
Post by: SJRulez83 on February 22, 2015, 12:24:26 pm
I think voting will take to much time. This is basically a new coin with a firm foundation. Are there any decisions we could make together? Ww can debate and go forward with one mindset

At the moment we should try and build a developer team, that understands how to read and write c++ code, how to install and run seed nodes, create genesis blocks, do the testing, build wallets and deamons for all systems, etc..

I am willing to give everybody a chance.
But we can't rush things from here on. We need to keep the testing rounds going.

Everybody is invited to show that he can create and manage his own fork and gather testers around him.

Let's do this a dozen times, and then we talk about voting and which way spreadcoin shall move.
Not now!

You can count me in for any dev work.
Title: Re: Masternodes Testing, Round 3
Post by: pokeytex on February 22, 2015, 01:10:59 pm
I am not a programmer but you can count on me for testing purposes.
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 22, 2015, 03:19:25 pm
Thanks for offering your help, guys.
Title: Re: Masternodes Testing, Round 3
Post by: gjhiggins on February 22, 2015, 09:11:38 pm
Everybody is invited to show that he can create and manage his own fork and gather testers around him.

Dunno about gathering testers around but I have some exploratory cpuminer1.2.* branches on:

https://github.com/gjhiggins/spreadcoin

Cheers

Graham
Title: Re: Masternodes Testing, Round 3
Post by: njs811 on February 23, 2015, 09:03:15 pm
Can we get a third test going? Even if the changes are small and the program simple.  I think it would be beneficial if the public could see that we are moving forward.
Title: Re: Masternodes Testing, Round 3
Post by: elbandi on February 23, 2015, 09:35:33 pm
my idea for testing:

1. prepare a basic testnet blockchain:
  - mine huge coin in first blocks
  - generate 2000 address
  - send random coins (150-5000) to that addresses
  - query the mnsecret for addresses
2. distribute this mnstart=foo string
  - everyone can run 5-10 node in the wallet daemon (less memory than qt)
3. make some monitor program (we dont know anything about election)
  - query the mnlist in every 1-10 seconds, put the data into a database
  - make this until we have 1440 mn
  - examine the stored data: how fast is chaning the score for a low/high price node, etc, etc
4. add/remove some node
  - monitor the mnlist
  - examine the data


i know it's seem a bit complicated, but this called engineering: we need test+datas to see how this works. Without concrete test, we just guessing and hoping!
Title: Re: Masternodes Testing, Round 3
Post by: georgem on February 23, 2015, 09:46:02 pm
my idea for testing:

1. prepare a basic testnet blockchain:
  - mine huge coin in first blocks
  - generate 2000 address
  - send random coins (150-5000) to that addresses
  - query the mnsecret for addresses
2. distribute this mnstart=foo string
  - everyone can run 5-10 node in the wallet daemon (less memory than qt)
3. make some monitor program (we dont know anything about election)
  - query the mnlist in every 1-10 seconds, put the data into a database
  - make this until we have 1440 mn
  - examine the stored data: how fast is chaning the score for a low/high price node, etc, etc
4. add/remove some node
  - monitor the mnlist
  - examine the data


i know it's seem a bit complicated, but this called engineering: we need test+datas to see how this works. Without concrete test, we just guessing and hoping!

Sounds like you have a plan. Sounds great.

One big question mark I have had during the last test round 2 is which masternodes receive which votes.
I know that a maximum of 10 votes is being saved in every block in the blockchain somewhere.
We would need to examine the blockchain and/or create a new RPC command called "latestvotes" or "getvotes" or something so that it will allow us to get this information.

Basically, we need information about who received which votes in the last block, or else we will not be able to guage if our future tests were successful or not.
Title: Re: Features for a new version (round 3)
Post by: georgem on February 23, 2015, 09:58:49 pm
I renamed this thread from

Masternodes Testing, Round 3

to

Features for a new version (round 3)

...

so that people don't mistake it with the next thread that we will start once we are ready with round 3.
Title: Re: Masternodes Testing, Round 3
Post by: SJRulez83 on February 23, 2015, 11:44:15 pm
my idea for testing:

1. prepare a basic testnet blockchain:
  - mine huge coin in first blocks
  - generate 2000 address
  - send random coins (150-5000) to that addresses
  - query the mnsecret for addresses
2. distribute this mnstart=foo string
  - everyone can run 5-10 node in the wallet daemon (less memory than qt)
3. make some monitor program (we dont know anything about election)
  - query the mnlist in every 1-10 seconds, put the data into a database
  - make this until we have 1440 mn
  - examine the stored data: how fast is chaning the score for a low/high price node, etc, etc
4. add/remove some node
  - monitor the mnlist
  - examine the data


i know it's seem a bit complicated, but this called engineering: we need test+datas to see how this works. Without concrete test, we just guessing and hoping!

I can provider a server free of charge I needed with dedicatd ip and remote access, if you let me know what you need on it i.e. windows, Linux, database etc I can get it setup within 24 hrs
Title: Re: Masternodes Testing, Round 3
Post by: Strumpet! on February 23, 2015, 11:48:48 pm
my idea for testing:

1. prepare a basic testnet blockchain:
  - mine huge coin in first blocks
  - generate 2000 address
  - send random coins (150-5000) to that addresses
  - query the mnsecret for addresses
2. distribute this mnstart=foo string
  - everyone can run 5-10 node in the wallet daemon (less memory than qt)
3. make some monitor program (we dont know anything about election)
  - query the mnlist in every 1-10 seconds, put the data into a database
  - make this until we have 1440 mn
  - examine the stored data: how fast is chaning the score for a low/high price node, etc, etc
4. add/remove some node
  - monitor the mnlist
  - examine the data


i know it's seem a bit complicated, but this called engineering: we need test+datas to see how this works. Without concrete test, we just guessing and hoping!

I don't think we need to reverse engineer the code to find out how it works - it's already there on github for those who can understand it.

I like the general idea though.

What would make this really easy would be an RPC call to yield the output string that at the moment has to be laboriously CTRL+C'd from the QT client.

I've already written a simple script to take a bunch of those outputs and stick mnstart=foo lines in the .conf file. If spreadcoind could give you the output, the whole process could be automated and would only take minutes...

1. Generate (for example) 15 wallets, each with 100 masternode-qualifying collateral amounts.
2. Batch produce the spreadcoin.conf for each wallet.
3. Send wallet + corresponding spreadcoin.conf to each of the 15 testers.

edit:
If someone can make a 'getmnoutputs' RPC call, they could also presumably automate the rest too. So a user just has to run './spreadcoind generateserverconf' and the daemon could spit out a spreadcoin.conf by itself. It's fifteen lines of code in my clumsy python, I'm sure it's not that hard to incorporate this into the wallet itself, to make running Spread MNs even easier for the user...?

We should be aiming to make all this stuff 1-click simple for users. :)
Title: Re: Features for a new version (round 3)
Post by: elbandi on February 24, 2015, 03:59:38 pm
here is a sqldump from current masternode status:

https://www.dropbox.com/s/pjbbxcsx3xku0y0/mn.sql.gz?dl=0

Feel free to make some query and get some interesting things :)
Title: Re: Features for a new version (round 3)
Post by: njs811 on February 24, 2015, 08:45:30 pm
Is anyone currently working on round three?
Title: Re: Features for a new version (round 3)
Post by: georgem on February 24, 2015, 09:11:50 pm
Is anyone currently working on round three?

Yes, I am.
Title: Re: Features for a new version (round 3)
Post by: elbandi on February 24, 2015, 09:53:51 pm
new test request:
if someone run the masternode from qt, than the output is locked, cannot spend.
if someone run masternode in daemon with mnstart= paramter, the qt wallet dont lock the coins. (thats ok, wallet dont know daemon is running somewhere).
but what's happening, if the masternode coins are sended to other place? is the daemon still running as elected? or what?

(this can be tested on R2 too, not requre the R3)
Title: Re: Features for a new version (round 3)
Post by: SJRulez83 on February 25, 2015, 12:59:50 am
new test request:
if someone run the masternode from qt, than the output is locked, cannot spend.
if someone run masternode in daemon with mnstart= paramter, the qt wallet dont lock the coins. (thats ok, wallet dont know daemon is running somewhere).
but what's happening, if the masternode coins are sended to other place? is the daemon still running as elected? or what?

(this can be tested on R2 too, not requre the R3)

Ill test it the morning and let you know, while at it another thing to test....

I cloned a vm and forgot to delete the wallet DAT on the vm, both now mine to the same wallet and to be fair any mined coins show in both at the same time. Maybe with testing if cloned wallet allows twice as many mn's for same amount of coins
Title: Re: Features for a new version (round 3)
Post by: gjhiggins on February 26, 2015, 05:06:51 pm
new test request:
if someone run the masternode from qt, than the output is locked, cannot spend.
if someone run masternode in daemon with mnstart= paramter, the qt wallet dont lock the coins. (thats ok, wallet dont know daemon is running somewhere).
but what's happening, if the masternode coins are sended to other place? is the daemon still running as elected? or what?
(this can be tested on R2 too, not requre the R3)

I have a local GUI wallet and a remote headless node (260SPR), both appearing as mnodes. I sent 250 SPR from the headless node to the GUI wallet address. The headless node reported mnmy = [] and after a few moments, it disappeared from the list of nmodes.

Works as expected.

You can use the RPC console to bypass the GUI lock.

Cheers

Graham
Title: Re: Features for a new version (round 3)
Post by: elbandi on February 26, 2015, 05:25:33 pm
Thx, but i didnt man so.

Local wallet has 1234 tSPR, export the mnsecret, add that to the daemon's nmstart. wait unit the daemon elected. than send the coins from local wallet to somewhere else. (and do not touch the daemon).

what will the daemon do now, thats the question.
Title: Re: Features for a new version (round 3)
Post by: elbandi on February 26, 2015, 06:06:26 pm
i prepared a blockchain: 2000 addresses with random coins
here is a list about the exported masternode secret:
https://docs.google.com/spreadsheets/d/10Wp7MahlOcU7eyFOMDF6Vbe85MQ5kvl8kxKRfR86wgo/edit?usp=sharing
Could you pls start some daemons with ~10 secret keys (per daemons)?
you can run the daemon near round2, it doesnt bother r2 test
Title: Re: Features for a new version (round 3)
Post by: jjjordan on February 26, 2015, 06:19:49 pm
Does anybody still need MNs for round 2? Or tSPR?
I will be shutting my wallet down incl MNs and will be purging it.
Title: Re: Features for a new version (round 3)
Post by: minerpage on February 26, 2015, 06:33:27 pm
i prepared a blockchain: 2000 addresses with random coins
here is a list about the exported masternode secret:
https://docs.google.com/spreadsheets/d/10Wp7MahlOcU7eyFOMDF6Vbe85MQ5kvl8kxKRfR86wgo/edit?usp=sharing
Could you pls start some daemons with ~10 secret keys (per daemons)?
you can run the daemon near round2, it doesnt bother r2 test

Will test as soon as I get it compiled...
Title: Re: Features for a new version (round 3)
Post by: def15 on February 28, 2015, 09:18:18 am
Is georgem still working on a test version?
Title: Re: Features for a new version (round 3)
Post by: georgem on February 28, 2015, 04:55:54 pm
Is georgem still working on a test version?

Yes I am. But it takes longer than I anticipated, I don't want to make any mistakes.
Stay tuned.

Meanwhile elbandi has created an automated test environment and needs masternode testers.
http://spreadcointalk.org/index.php?topic=133.msg2556#msg2556
Please ask him directly.
Title: Re: Features for a new version (round 3)
Post by: jjjordan on March 02, 2015, 03:21:29 pm
Let's say the 3rd test version is released and it ends, then probably a new mainnet will be on its way.
Will the new mainnet/fork/whateveritscalled will use all current coins or will the mining start from 0?
I am asking to basically find out if it's worth mining/buing now or should I wait until the new mainnet is out?

If the mining starts from 0 then it is an entirely new coin... maybe different name?
Title: Re: Features for a new version (round 3)
Post by: minerpage on March 02, 2015, 04:53:44 pm
Let's say the 3rd test version is released and it ends, then probably a new mainnet will be on its way.
Will the new mainnet/fork/whateveritscalled will use all current coins or will the mining start from 0?
I am asking to basically find out if it's worth mining/buing now or should I wait until the new mainnet is out?

If the mining starts from 0 then it is an entirely new coin... maybe different name?

I haven't heard about plans for restarting the chain so I guess the current coins will stay after Test 03 is released
Title: Re: Features for a new version (round 3)
Post by: jjjordan on March 02, 2015, 05:04:01 pm
Let's say the 3rd test version is released and it ends, then probably a new mainnet will be on its way.
Will the new mainnet/fork/whateveritscalled will use all current coins or will the mining start from 0?
I am asking to basically find out if it's worth mining/buing now or should I wait until the new mainnet is out?

If the mining starts from 0 then it is an entirely new coin... maybe different name?

I haven't heard about plans for restarting the chain so I guess the current coins will stay after Test 03 is released

I am guessing the same thing, but your post doesn't put more light on the matter. Devs  must state what the plan is.
Title: Re: Features for a new version (round 3)
Post by: georgem on March 02, 2015, 07:22:26 pm
Let's say the 3rd test version is released and it ends, then probably a new mainnet will be on its way.
Will the new mainnet/fork/whateveritscalled will use all current coins or will the mining start from 0?
I am asking to basically find out if it's worth mining/buing now or should I wait until the new mainnet is out?

If the mining starts from 0 then it is an entirely new coin... maybe different name?

How some people can already talk about an upcoming main net version while we are in this grave situation totally baffles me.

No, we will never start a new blockchain for main net. We will always make a fork that builds on the official spreadcoin blockchain that already exists.
That's how it is supposed to be, and everything else would be insane, like shooting yourself in the foot.

Also, after the 3rd test is successful we are going to need a few additional testrounds based on the bugs we find in round 3.
Title: Re: Features for a new version (round 3)
Post by: georgem on March 02, 2015, 07:23:41 pm
Let's say the 3rd test version is released and it ends, then probably a new mainnet will be on its way.
Will the new mainnet/fork/whateveritscalled will use all current coins or will the mining start from 0?
I am asking to basically find out if it's worth mining/buing now or should I wait until the new mainnet is out?

If the mining starts from 0 then it is an entirely new coin... maybe different name?

I haven't heard about plans for restarting the chain so I guess the current coins will stay after Test 03 is released

Ofcourse. The moment we restart the chain is the moment spreadcoin is dead.
Nobody wants spreadcoin to die.
Title: Re: Features for a new version (round 3)
Post by: jjjordan on March 02, 2015, 07:27:29 pm
Gotcha. Thanks for the info.
Sorry for not being very familiar...
Title: Re: Features for a new version (round 3)
Post by: georgem on March 02, 2015, 07:31:29 pm
Gotcha. Thanks for the info.
Sorry for not being very familiar...

No problem, don't apologize. At the moment there are so many more important things we have to fix, before we can even start to guess when a new main net version might be applicable.

We need more then just another test round just because for us new devs it will take that many more test rounds just so we get near the same level of knowledge that Mr. Spread had.
Title: Re: Features for a new version (round 3)
Post by: njs811 on March 03, 2015, 02:07:20 am
Gotcha. Thanks for the info.
Sorry for not being very familiar...

No problem, don't apologize. At the moment there are so many more important things we have to fix, before we can even start to guess when a new main net version might be applicable.

We need more then just another test round just because for us new devs it will take that many more test rounds just so we get near the same level of knowledge that Mr. Spread had.

Is there an ETA on the next test? I know it would help the community out a ton if they could see the project moving forward. Also I only know a small amount of C++ (But I am learning more every day) Could you please explain to me how these blockchains work? What did you mean when you said that restarting the blockchain would mean an entirely new coin? How do you go about restarting it? I would love to be able to copy/paste a crap coin for testing purposes. I am incredibly interested in all of this and I am not entirely sure where to start.
Title: Re: Features for a new version (round 3)
Post by: georgem on March 03, 2015, 02:31:11 am
Gotcha. Thanks for the info.
Sorry for not being very familiar...

No problem, don't apologize. At the moment there are so many more important things we have to fix, before we can even start to guess when a new main net version might be applicable.

We need more then just another test round just because for us new devs it will take that many more test rounds just so we get near the same level of knowledge that Mr. Spread had.

Is there an ETA on the next test? I know it would help the community out a ton if they could see the project moving forward. Also I only know a small amount of C++ (But I am learning more every day) Could you please explain to me how these blockchains work? What did you mean when you said that restarting the blockchain would mean an entirely new coin? How do you go about restarting it? I would love to be able to copy/paste a crap coin for testing purposes. I am incredibly interested in all of this and I am not entirely sure where to start.

C++ is not that hard to learn, and additionally you must know how libraries like Boost etc work.

But the real problem is understanding how a coin works.

Every coin has its own blockchain that grows over time, representing an uninterrupted coherent history of all transactions that happened during the time from the beginning of when the coin was created until NOW.
If we were to abandon the blockchain we already have and restart a new one, it would mean that we are not spreadcoin anymore but something else, since the old spreadcoin blockchain would still exist out there. If we start a new blockchain on main net it means that all SPR you now have will be lost. You can't create a new blockchain and keep your old coins.

Sure, you can do a fork and keep your old coins if you (and the majority of the community) agree to switch to the new valid fork,
but you can't start a blockchain from scratch and call it a fork (A fork that starts from zero is not really a fork, but a new coin).

I recommend you read Andreas Antonopoulos book "Mastering Bitcoin":

http://www.amazon.de/Mastering-Bitcoin-Unlocking-Digital-Cryptocurrencies/dp/1449374042
Title: Re: Features for a new version (round 3)
Post by: georgem on March 03, 2015, 02:32:27 am
Is there an ETA on the next test?

No ETA possible at the moment.
This will change once the new devs here have enough knowledge to proceed.
Title: Re: Features for a new version (round 3)
Post by: duboisi on March 04, 2015, 11:58:37 am
Do you guys still need Round2 test (wallets, masternodes, mining) to continue running?
Title: Re: Features for a new version (round 3)
Post by: gjhiggins on March 04, 2015, 12:54:42 pm
Do you guys still need Round2 test (wallets, masternodes, mining) to continue running?

Mr Spread disappeared during the test so that's why there was no announcement  that round 2 was complete but (aiui) the objective of testing the mnode election/payment system with a mnode population of > 2000 was achieved and, afaict, was considered successful and yielded valuable information to inform the next stage of testing.

(Now “all” I have to do is put some detail into that statement.)

If you're running a masternode, feel free to shut it down and stop any mining activity. However, IMO, there should always be a testnet in operation, just in principle, so I'll ensure that our server keeps the testnet alive. (I'm taking my cue from georgem here “I guess as long as there are participants running their wallets... test round 2 is still on.” http://spreadcointalk.org/index.php?topic=93.msg2538#msg2538)

I'd be hugely appreciative if those who had convos with Mr Spread about the test and have info about implementation, deployment or objectives that isn't also in black'n'white on bct or here, could briefly summarise the missing info and post it here.

For my part, I'll attempt to write up the results of stage 2 for public consumption.

Cheers

Graham
Title: Re: Features for a new version (round 3)
Post by: georgem on March 04, 2015, 01:45:57 pm
Do you guys still need Round2 test (wallets, masternodes, mining) to continue running?

Mr Spread disappeared during the test so that's why there was no announcement  that round 2 was complete but (aiui) the objective of testing the mnode election/payment system with a mnode population of > 2000 was achieved and, afaict, was considered successful and yielded valuable information to inform the next stage of testing.

(Now “all” I have to do is put some detail into that statement.)

If you're running a masternode, feel free to shut it down and stop any mining activity. However, IMO, there should always be a testnet in operation, just in principle, so I'll ensure that our server keeps the testnet alive. (I'm taking my cue from georgem here “I guess as long as there are participants running their wallets... test round 2 is still on.” http://spreadcointalk.org/index.php?topic=93.msg2538#msg2538)

I'd be hugely appreciative if those who had convos with Mr Spread about the test and have info about implementation, deployment or objectives that isn't also in black'n'white on bct or here, could briefly summarise the missing info and post it here.

I believe we are going to need two testnets.

One that is constantly running and is close to mainnet (and even uses a copy of the same blockchain as mainnet itself).
This is where we solve mainnet bugs or test an imminent fork to see if it would be succesful.

Additionally we will need one testnet that is for completely new experimental features that is activated only when needed.
It could run on a different port so that it doesn't collide with mainnet and testnet 1.

For my part, I'll attempt to write up the results of stage 2 for public consumption.

Cheers

Graham

Please do so.
Title: Re: Features for a new version (round 3)
Post by: gjhiggins on March 04, 2015, 03:28:29 pm
This is where we solve mainnet bugs or test an imminent fork to see if it would be succesful.

And, perhaps more importantly, where users can familiarise themselves with the operation of masternodes (et al)  without having to buy coins just to find out whether the feature works as advertised (something that so far has kept me away from exploring the features offered by 2nd gen coins.)

+1 on having two testnets.

Cheers

Graham
Title: Re: Features for a new version (round 3)
Post by: georgem on March 04, 2015, 09:12:56 pm
This is where we solve mainnet bugs or test an imminent fork to see if it would be succesful.

And, perhaps more importantly, where users can familiarise themselves with the operation of masternodes (et al)  without having to buy coins just to find out whether the feature works as advertised (something that so far has kept me away from exploring the features offered by 2nd gen coins.)

+1 on having two testnets.

Cheers

Graham

Excellent point. That's why we had so much fun in test round 1 + 2...
Title: Re: Features for a new version (round 3)
Post by: njs811 on March 12, 2015, 06:42:15 pm
Would it be possible to create a pool on masternodes? The coin could be mined within itself.  :o
Title: Re: Features for a new version (round 3)
Post by: njs811 on March 14, 2015, 01:49:23 pm
Updates anyone?
Title: Re: Features for a new version (round 3)
Post by: georgem on March 14, 2015, 02:39:30 pm
Updates anyone?

I am working on building new wallets and daemons for win, mac and linux. (32 and 64 bit)

I will have them ready in 24 hours.
Title: Re: Features for a new version (round 3)
Post by: njs811 on March 14, 2015, 02:44:21 pm
Updates anyone?

I am working on building new wallets and daemons for win, mac and linux. (32 and 64 bit)

I will have them ready in 24 hours.

What will be the difference between the new and old wallets?
Title: Re: Features for a new version (round 3)
Post by: georgem on March 14, 2015, 02:46:29 pm
Updates anyone?

I am working on building new wallets and daemons for win, mac and linux. (32 and 64 bit)

I will have them ready in 24 hours.

What will be the difference between the new and old wallets?

Nothing.

We simply need new wallets because we didn't manage to save all the old wallets from Mr.Spreads dead website.

I am compiling new wallets for all systems as we speak.
But they will first simply be the old ones (spreadcoin-master branch)

PS: Also, what kind of dev would I be if I can't build (qt) wallets and daemons for all systems. So stay tuned.
Title: Re: Features for a new version (round 3)
Post by: chrysophylax on March 15, 2015, 02:59:50 am
Updates anyone?

I am working on building new wallets and daemons for win, mac and linux. (32 and 64 bit)

I will have them ready in 24 hours.

What will be the difference between the new and old wallets?

Nothing.

We simply need new wallets because we didn't manage to save all the old wallets from Mr.Spreads dead website.

I am compiling new wallets for all systems as we speak.
But they will first simply be the old ones (spreadcoin-master branch)

PS: Also, what kind of dev would I be if I can't build (qt) wallets and daemons for all systems. So stay tuned.

id be interested to see if the sourcecode compiles properly in linux ( fedora 19 x64 ) ...

where is the source? ...

#crysx