Topic: [ANN] ¤ DMD Diamond 3.0 | Scarce ¤ Valuable ¤ Secure | PoS 3.0 | Masternodes 65% - page 546. (Read 1260677 times)

With the new wallet minting works a lot better. Even small pile in the business now. 

second node

193.136.96.30


I have a third node but its my mining node, so for now i will keep it private

now the load as reduced a lot


top - 14:26:31 up  4:54,  3 users,  load average: 0.37, 0.52, 0.57
Tasks: 178 total,   1 running, 176 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.0 us,  0.7 sy,  0.2 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.5 st
KiB Mem:   3797964 total,  3674596 used,   123368 free,    48212 buffers
KiB Swap:  7945212 total,     3568 used,  7941644 free,  2548620 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                               
11629 sysop     20   0  958m 483m  24m S   1.7 13.0  98:42.07 diamond-qt                                                                                                             
   12 root      rt   0     0    0    0 S   0.3  0.0   0:00.13 watchdog/1                                                                                                             
  142 root      20   0     0    0    0 S   0.3  0.0   0:16.99 scsi_eh_1                                                                                                             
 3023 root      20   0 71288 2128 1960 S   0.3  0.1   0:02.40 sshd                                                                                                                   
 9428 sysop     20   0  498m  22m  12m S   0.3  0.6   0:03.27 gnome-settings-                                                                                                       
10710 sysop     20   0  477m  23m  14m S   0.3  0.6   0:03.18 gnome-panel                                                                                                           
12589 root      20   0     0    0    0 S   0.3  0.0   0:00.42 kworker/0:3


i think this is going on the right way

we can explain actual POW and POS situation like this

because network overloaded in sort out bad blocks and main nodes nearly always at 100% cpu load

this create a situation where multiple blocks compete to be the next one found

just because the selection process in network what is the next block is delayed

but its clear only one can be the next one
so a lot blocks orphan minting/mining

(this is what people did say their found blocks where overwritten
because they didnt propagate over majority of network and their wallet reorg back to join the majority
normal network make this less visible because a orphan would be easy visible but at actual situation it can need some time until wallet discover this block made it not into the main chain and then they remove it and accept the real block (this is called a reorg automated fix of local blockchain content))

less people mining and minting is less competition
(a pool here just count as one wallet so we suggest solomine if u have a real big hashrate but use a pool example donkeypool is u have medium or low hashrate)

less wallets online is less spread of block all around

less people sync their blockchains is less load

once network load normalize everything will work smooth like the last half year

then people can turn on their wallets again

there is no reason to have a wallet online now other than

try to be a relay node
try to solomine
dont have wallet open for POS now
u can pos later u lose nothing...


 ot valuable data got gathered by us and we will work on improvements in wallet code
in the area performance optimisatzion CPU useage

to reduce the chance such stuff happens again
no matter what crap got put in circulation in network
it should not be able eat up all wallet resources and have impact on normal operation

as always every attack or lets call it incident in the end make dmd diamond stronger

multiple times tested in the past each time leading to improvements
this test again will just increase our network setup stability and wallet code optimisatzion as result

here we have the problem
a nice network produce normal load
but a bad network create lot load
even a secure code wallet can lead to instabilities if good nodes just overworked to give good answers in time

the situation will normalize after some time when network get rid of the bad blocks

but we got some homework to do for code optimisation that security checks (which are good and needed)
and other wallet code is optimized for lowest possible cpu load and still fullfil their task

for now more backbone nodes will still help
10 nodes have a higher chance one respond in time than 4 nodes...

thanks mate quick response as always ... bit of drama by the look of it....

normal message for solo mining

i just started to solo mine and it seems to be working. but i just had a question dose anyone know what this means??? "no suitable long-pool found for http://127.0.0.1:17772" thanks

{
"version" : "v2.0.5.5",
"protocolversion" : 60012,
"walletversion" : 60000,
"balance" : 0.00000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 874542,
"moneysupply" : 994818.71613400,
"connections" : 31,
"proxy" : "",
"ip" : "193.136.97.30",
"difficulty" : 93.38328036,
"testnet" : false,
"keypoololdest" : 1428659785,
"keypoolsize" : 102,
"paytxfee" : 0.00000000,
"errors" : ""
}

top - 13:20:16 up  3:48,  3 users,  load average: 0.53, 0.40, 0.41
Tasks: 180 total,   1 running, 178 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.0 us,  1.7 sy, 48.6 ni, 49.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.5 st
KiB Mem:   3797964 total,  3649852 used,   148112 free,    43832 buffers
KiB Swap:  7945212 total,     3572 used,  7941640 free,  2545532 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                
11629 sysop     20   0  955m 468m  24m S 100.4 12.6  58:50.64 diamond-qt                                                                                                            
  142 root      20   0     0    0    0 S   0.3  0.0   0:12.12 scsi_eh_1                                                                                                              
12008 root      20   0     0    0    0 S   0.3  0.0   0:01.61 kworker/0:1                                                                                                            
12036 root      20   0     0    0    0 S   0.3  0.0   0:01.21 kworker/0:0                                                                                                            


basicaly its 100%
the wallet does not suport simetric multiprocessing

for a node to relay data and support the network thats the ideal config
how is ur cpu load (the core where wllet run not over all cores)? u get lot connections?

Update your wallets. This is mandatory.
There are too many wallets not updated.
The block explorer is seeing a 2.0.3.2 wallet
And numerous 2.0.4 and 2.0.4.1 versions of wallets.
https://chainz.cryptoid.info/dmd/#!network
Network tab/node list.
Here are the nodes not updated.
2.0.4
addnode=110.174.192.177
addnode=111.92.116.139
addnode=14.177.142.120
addnode=37.48.113.81
addnode=5.15.240.39
addnode=62.43.140.213
addnode=72.253.122.203
addnode=92.229.129.38
addnode=95.18.124.63
addnode=96.89.147.106
addnode=99.61.195.86
2.0.4.1 protocol 60006
addnode=212.243.7.37
addnode=79.120.211.194
2.0.4.1 protocol 60012
addnode=212.243.7.37
addnode=79.120.211.194
Strange ^^^^^^^^^^^ they are the same?
2.0.3.2
addnode=173.52.253.209
They need to be updated.
ASAP.

i'm using this config


any comments?


listen=1
server=1
daemon=1
addnode=193.68.21.19
addnode=54.191.208.14
addnode=54.255.133.30
addnode=54.86.164.216
bantime=14400
noirc=1

please post only ur nodes if u can maintain them and the IP is static

nodes that fullfill that requirements we will add to the list

- DEFAULT configuration that help network relay data and act as a node

Example entries in the config file:

listen=1
noirc=1
#foundation nodes
addnode=193.68.21.19
addnode=54.191.208.14
addnode=54.255.133.30
addnode=54.86.164.216
#community nodes 2015.04.10
#NineEleven
addnode=193.136.97.30
bantime=3600


- OPTIONAL configuration (only pools and very big solo miners/staking wallets)

Example entries in the config file:

listen=0
noirc=1
#foundation nodes
connect=193.68.21.19
connect=54.191.208.14
connect=54.255.133.30
connect=54.86.164.216
#communitynodes 2015.04.10
#NineEleven
connect=193.136.97.30
bantime=3600

Full node operacional synced and on the right chain


193.136.97.30

http://dmd.donkeypool.com:808/

is up and running as alternative pool

support him

or go solo mining

every helping hand is welcome

we will just gather a list of nodes

where foundation nodes AND community nodes are listed

and in time like this where our foundation nodes are overloaded we suggest to use the community nodes in conf too

at normal times its not needed to add them in conf because u will find them as peers anyway

a goal for future will be to distribute a good nodelist without need to add them in conf file always

The problem is basically the block relaying on the network is very slow. This, combined with the short block time is causing the "overwriting" situation.

The solution is more nodes running as permanent wallets and more block producing nodes (those are two separate things).

Another solution is for large miners to move off danbi's pool.

Yet another solution is to bring more hashpower to another pool.

What we have now is a very bad situation, which will persist until the fork (the 1000000 million DMD) -- after that point, PoS will run at much higher pace and PoW at lower, so even with 100% hash rate one source of blocks will not be enough to "overwrite" anything.

Shutting down danbi's pool will not do much more than punish those who mine there.

So please, if someone can -- run permanent nodes, connect them (with addnode=) to the current permanent nodes and publish your IP addresses for others to use. This will remove a lot of load from the existing nodes, letting blocks propagate faster.

Running a pool would change things slower, as you would need to convince miners they can trust you and change their settings -- but this is ultimately the long term goal.

I too agree, that frequent forks are bad idea and we try to avoid this as much as possible.

a clear visible development goal this situation gave us

midterm we need to find network topology with more nodes with less load or/and wallets who utilize multiple cpu cores

our wallet code is save it can outfilter the wrong blocks
but the amount of bad blocks circulating in network is overloading the backbone nodes
so they lag and respond late which create additional confusion

while in the past there where attackpattern that missused the bantime and made us suggest 600 sec bantime
now at this situation a higher time would help our network to not process the same bad block again and again every 10 min

so please increase ur bantime to 3600 or 36000 if u have the time to manual check that ur wallet stay on mainchain

maybe we find a way how we can in future reward people for hosting backbone nodes

and this way have more of them

brainstorming in that area can start once the actual situation relax