« previous next »
Pages: 1 2 [3] 4 5

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

elbandi

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Masternodes Testing, Round 3
« Reply #30 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!
Logged

georgem

  • Tech Admin
  • ******
  • Posts: 679
    • View Profile
Re: Masternodes Testing, Round 3
« Reply #31 on: February 23, 2015, 09:46:02 pm »
Quote from: 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!

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.
Logged
Forum donations: SVusZDRc8P1BjBRwrgdqYrJ4j5aY3gHFUg

georgem

  • Tech Admin
  • ******
  • Posts: 679
    • View Profile
Re: Features for a new version (round 3)
« Reply #32 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.
Logged
Forum donations: SVusZDRc8P1BjBRwrgdqYrJ4j5aY3gHFUg

SJRulez83

  • Admin
  • *****
  • Posts: 64
  • IT Manager,Software Developer and Geek
    • View Profile
Re: Masternodes Testing, Round 3
« Reply #33 on: February 23, 2015, 11:44:15 pm »
Quote from: 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!

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
Logged

Strumpet!

  • Full Member
  • ***
  • Posts: 158
    • View Profile
Re: Masternodes Testing, Round 3
« Reply #34 on: February 23, 2015, 11:48:48 pm »
Quote from: 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!

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. :)
Logged

elbandi

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Features for a new version (round 3)
« Reply #35 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 :)
Logged

njs811

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: Features for a new version (round 3)
« Reply #36 on: February 24, 2015, 08:45:30 pm »
Is anyone currently working on round three?
Logged

georgem

  • Tech Admin
  • ******
  • Posts: 679
    • View Profile
Re: Features for a new version (round 3)
« Reply #37 on: February 24, 2015, 09:11:50 pm »
Quote from: njs811 on February 24, 2015, 08:45:30 pm
Is anyone currently working on round three?

Yes, I am.
Logged
Forum donations: SVusZDRc8P1BjBRwrgdqYrJ4j5aY3gHFUg

elbandi

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Features for a new version (round 3)
« Reply #38 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)
Logged

SJRulez83

  • Admin
  • *****
  • Posts: 64
  • IT Manager,Software Developer and Geek
    • View Profile
Re: Features for a new version (round 3)
« Reply #39 on: February 25, 2015, 12:59:50 am »
Quote from: 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)

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
Logged

gjhiggins

  • Guest
Re: Features for a new version (round 3)
« Reply #40 on: February 26, 2015, 05:06:51 pm »
Quote from: 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)

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
Logged

elbandi

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Features for a new version (round 3)
« Reply #41 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.
Logged

elbandi

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Features for a new version (round 3)
« Reply #42 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
Logged

jjjordan

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: Features for a new version (round 3)
« Reply #43 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.
Logged

minerpage

  • Admin
  • *****
  • Posts: 81
    • View Profile
Re: Features for a new version (round 3)
« Reply #44 on: February 26, 2015, 06:33:27 pm »
Quote from: 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

Will test as soon as I get it compiled...
Logged
Pages: 1 2 [3] 4 5
« previous next »