Author Topic: Features for a new version (round 3) (Read 6277 times)

georgem · « **Reply #15 on:** February 21, 2015, 06:52:22 pm »

Quote from: 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

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!

elbandi · « **Reply #16 on:** February 21, 2015, 08:17:23 pm »

Quote from: Strumpet! on February 21, 2015, 06:29:27 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...

georgem · « **Reply #17 on:** February 21, 2015, 08:27:35 pm »

I propose to have a limited amount of MNs that slowly grows over time:

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

Quote from: MyFarm on February 15, 2015, 04:46:51 pm

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.

Strumpet! · « **Reply #18 on:** February 21, 2015, 08:30:23 pm »

Quote from: elbandi on February 21, 2015, 08:17:23 pm

Quote from: Strumpet! on February 21, 2015, 06:29:27 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.

georgem · « **Reply #19 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.

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.

Strumpet! · « **Reply #20 on:** February 21, 2015, 08:58:18 pm »

Quote from: 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.

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.

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...

georgem · « **Reply #21 on:** February 21, 2015, 09:09:03 pm »

Quote from: Strumpet! on February 21, 2015, 08:58:18 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.

Strumpet! · « **Reply #22 on:** February 21, 2015, 09:11:50 pm »

Quote from: georgem on February 21, 2015, 09:09:03 pm

Quote from: Strumpet! on February 21, 2015, 08:58:18 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.

georgem · « **Reply #23 on:** February 21, 2015, 09:20:48 pm »

Quote from: Strumpet! on February 21, 2015, 09:11:50 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.

georgem · « **Reply #24 on:** February 21, 2015, 09:22:53 pm »

Quote from: Strumpet! on February 21, 2015, 09:11:50 pm

Quote from: georgem on February 21, 2015, 09:09:03 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

SJRulez83 · « **Reply #25 on:** February 22, 2015, 12:24:26 pm »

Quote from: georgem on February 21, 2015, 06:52:22 pm

Quote from: 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

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.

pokeytex · « **Reply #26 on:** February 22, 2015, 01:10:59 pm »

I am not a programmer but you can count on me for testing purposes.

georgem · « **Reply #27 on:** February 22, 2015, 03:19:25 pm »

Thanks for offering your help, guys.

gjhiggins · « **Reply #28 on:** February 22, 2015, 09:11:38 pm »

Quote from: georgem on February 21, 2015, 06:52:22 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

njs811 · « **Reply #29 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.

News:

Author Topic: Features for a new version (round 3) (Read 6277 times)

georgem

Re: Masternodes Testing, Round 3

elbandi

Re: Masternodes Testing, Round 3

georgem

Re: Masternodes Testing, Round 3

Strumpet!

Re: Masternodes Testing, Round 3

georgem

Re: Masternodes Testing, Round 3

Strumpet!

Re: Masternodes Testing, Round 3

georgem

Re: Masternodes Testing, Round 3

Strumpet!

Re: Masternodes Testing, Round 3

georgem

Re: Masternodes Testing, Round 3

georgem

Re: Masternodes Testing, Round 3

SJRulez83

Re: Masternodes Testing, Round 3

pokeytex

Re: Masternodes Testing, Round 3

georgem

Re: Masternodes Testing, Round 3

gjhiggins

Re: Masternodes Testing, Round 3

njs811

Re: Masternodes Testing, Round 3