V12 Release

UdjinM6 · Aug 18, 2015

AjM said:
If i remember it right, txindex=1 is default in the v12.
Maybe UdjinM6 can comment on this, is the txindex=1 mandatory in dash.conf, i thought it was only in v11?

Yep, it's default. It's just me - I like things to be explicitly defined in config

AjM · Aug 18, 2015

UdjinM6 said:
Yep, it's default. It's just me - I like things to be explicitly defined in config

Ok, my mn:s does not have this in any conf, and they work ok so far, except jumping cpu usage about 10-30%

qwizzie · Aug 18, 2015

the only thing i can think of thats different with two days ago is that a lot of masternodes all of a sudden got activated at once,
maybe that somehow caused huge spikes, overloading some masternodes ?

edit : also minersday post on top of this page looks interesting

Lukas_Jackson · Aug 18, 2015

qwizzie said:
the only thing i can think of thats different with two days ago is that a lot of masternodes all of a sudden got activated at once,
maybe that somehow caused huge spikes, overloading some masternodes ?

edit : also minersday post on top of this page looks interesting

Yes, but MNs shutdown long after that spikes.

qwizzie · Aug 18, 2015

I hope when enforcement goes on again it will be on both version and protocol and only those masternodes will get paid with both correct version number and protocol number.
Because a lot of splits are showing up on dashninja.pl, almost like people are trying out things and it wouldnt be fair to have them get paid as they are not active in the DS mixing
process (they get rejected during DS)

correct version / correct protocol
0.12.0.45 / 70103

incorrect version / protocol

0.11.2.23 / 70076
0.11.2.22 / 70103
0.11.2.23 / 70103
0.12.0.44 / 70103
0.12.0.44 / 70076
0.12.0.45 / 70076

djcrypto · Aug 18, 2015

UdjinM6 said:
What's in debug.log? Any errors?

Somehow I got past this issue after reindexing. However, the MNs go offline after a few hours. I noticed the "Disk write" graph spiked just before the CPU usage dropped to 0, which I assume is when Dash crashed.

djcrypto · Aug 18, 2015

TaoOfSatoshi said:
UdjinM6 djcrypto

I have similar issues with my dashd, although I suspect it may be because my VPSs can't handle the demands of V12. I have 256 memory with 256 swap. I am upgrading to 512/512 and seeing if that helps. Crypto, what are your VPS specs?

My VPS is 512MB /20GB SSD/1tb bandwidth. Crashed after a few hours. I noticed a Disk write spike on the graph just before the CPU usage went to 0.

Lebubar · Aug 18, 2015

@UdjinM6, just another crash of one MN.

This one is good, I saved the debug.log.
Just told me where I can send it to you.

moli · Aug 18, 2015

qwizzie said:
I hope when enforcement goes on again it will be on both version and protocol and only those masternodes will get paid with both correct version number and protocol number.
Because a lot of splits are showing up on dashninja.pl, almost like people are trying out things and it wouldnt be fair to have them get paid as they are not active in the DS mixing
process (they get rejected during DS)

correct version / correct protocol
0.12.0.45 / 70103

incorrect version / protocol

0.11.2.23 / 70076
0.11.2.22 / 70103
0.11.2.23 / 70103
0.12.0.44 / 70103
0.12.0.44 / 70076
0.12.0.45 / 70076

https://dashtalk.org/threads/please-update-to-v12-0-45.5912/#post-63791

moli · Aug 18, 2015

Does this mean 2441 masternodes have updated to v.12?

moli · Aug 18, 2015

MangledBlue said:
Explain this one please: txindex=1

txindex : maintains an extra index of old, spent transaction ids so they will be found by the getrawtransaction JSON-RPC method.
reindex : rebuild block and transaction indices from the downloaded block data.
you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices

https://bitcoin.stackexchange.com/q...ction-detail-in-bitcoin-version-0-8-and-above

qwizzie · Aug 18, 2015

moli said:
Does this mean 2441 masternodes have updated to v.12?

View attachment 1775

no, it means 1781 masternodes have updated to v12 and 655 are still on v11, together they form 2436 enabled masternodes. At least thats how i see it...

studioz · Aug 18, 2015

4 of 5 masternodes went off again all at about same time
im also with vultr
what can cause that ?

qwizzie · Aug 18, 2015

studioz said:
4 of 5 masternodes went off again all at about same time
im also with vultr
what can cause that ?

i think my masternodes on VULTR previously also crashed very close after each other, currently they are active again for two hours now.. more or less.
I have no idea whats causing it, its at least not provider related as it happened both on VULTR and Digital Ocean

Lebubar · Aug 18, 2015

One of mine crashed at 19:02:31 (UTC). And not on VULTR neither on digitalOcean.

duffman · Aug 18, 2015

Hmmm... What do clouds smell like?
Mr. Chairman, thank you for the new release. It is quite a show you are having here. I did not expect less from you. :grin:
I may have stumbled upon a wonderful loop (or someone is performing a stress test on the network):

Code:

2015-08-18 21:10:44 mnp - Masternode ping, vin: CTxIn(COutPoint(35191e0591a2aa89b8d42469cd2f3ceb1741e3f3a4b69ebaf0bed3c10f95d0ce, 0), scriptSig=)
2015-08-18 21:10:44 CMasternodePing::CheckAndUpdate - New Ping - 7e1737c7eecd61a5556650c93d9f461b600d1f23d95f8db3516bf32cd911c716 - 0000000000128c19d0ede3b48ea5506878691ed93d93ef3fd1c127570051be07 - 1439932027
2015-08-18 21:10:44 CMasternodePing::CheckAndUpdate - Masternode ping accepted, vin: CTxIn(COutPoint(35191e0591a2aa89b8d42469cd2f3ceb1741e3f3a4b69ebaf0bed3c10f95d0ce, 0), scriptSig=)
2015-08-18 21:10:44 sending: inv (37 bytes) peer=17
2015-08-18 21:10:44 sending: inv (37 bytes) peer=22
2015-08-18 21:10:44 sending: inv (37 bytes) peer=26
2015-08-18 21:10:44 sending: inv (37 bytes) peer=37
2015-08-18 21:10:44 sending: inv (37 bytes) peer=38
2015-08-18 21:10:44 sending: inv (37 bytes) peer=89
2015-08-18 21:10:44 sending: inv (37 bytes) peer=94
2015-08-18 21:10:44 sending: inv (37 bytes) peer=2
2015-08-18 21:10:44 sending: inv (37 bytes) peer=14
2015-08-18 21:10:44 sending: ping (8 bytes) peer=2
2015-08-18 21:10:44 received: dseep (116 bytes) peer=26
2015-08-18 21:10:44 received: inv (37 bytes) peer=94
2015-08-18 21:10:44 got inv: mn ping 7e1737c7eecd61a5556650c93d9f461b600d1f23d95f8db3516bf32cd911c716  have peer=94
2015-08-18 21:10:44 received: pong (8 bytes) peer=2
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=38
2015-08-18 21:10:44 received: dseep (116 bytes) peer=38
2015-08-18 21:10:44 received: dseep (116 bytes) peer=2
2015-08-18 21:10:44 dseep - relaying CTxIn(COutPoint(d8faddfeb6bc965e2d5f33bfbe3e620a36204151497c4348f17cbb0ca360267a, 0), scriptSig=)
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=2
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=14
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=15
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=17
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=22
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=26
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=37
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=38
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=89
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=94
2015-08-18 21:10:44 received: ping (8 bytes) peer=2
2015-08-18 21:10:44 sending: pong (8 bytes) peer=2
2015-08-18 21:10:44 sending: ping (8 bytes) peer=89
2015-08-18 21:10:44 received: notfound (37 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: inv (37 bytes) peer=89
2015-08-18 21:10:44 got inv: mn ping 7e1737c7eecd61a5556650c93d9f461b600d1f23d95f8db3516bf32cd911c716  have peer=89
2015-08-18 21:10:44 received: dseep (116 bytes) peer=15
2015-08-18 21:10:44 received: inv (37 bytes) peer=15
2015-08-18 21:10:44 got inv: mn ping 4675d6508dbae0ff0577ad68eb4290ef0c4dc004c257994f2e52f2f9109b0c00  new peer=15
2015-08-18 21:10:44 askfor mn ping 4675d6508dbae0ff0577ad68eb4290ef0c4dc004c257994f2e52f2f9109b0c00  0 (00:00:00) peer=15
2015-08-18 21:10:44 Requesting mn ping 4675d6508dbae0ff0577ad68eb4290ef0c4dc004c257994f2e52f2f9109b0c00 peer=15
2015-08-18 21:10:44 sending: getdata (37 bytes) peer=15
2015-08-18 21:10:44 received: mnp (147 bytes) peer=15

MangledBlue · Aug 18, 2015

does nobody use crontab -e

@reboot dashd

qwizzie · Aug 18, 2015

there is some activity going on in github : https://github.com/dashpay/dash/commits/v0.12.0.x
i wouldnt be surprised if we get another update soon.

aleix · Aug 19, 2015

Same problem here. After a while updated and ok, some of my masternodes are shown as a "inactive" in dashninja....

Lebubar · Aug 19, 2015

Well we all agree that we have stability problem

6 out of 15 offline tonight.
As say before some movements on github were detected, we all know that it will take max 48h for the dev team to correct those glitch. We are with you.:smile:

Edsit:
If debug.log are needed I got a lot.

Edit 2:
One say :

Code:

2015-08-18 20:30:19 Verifying mncache.dat format...
2015-08-18 20:30:20 Loaded info from mncache.dat  1126ms
2015-08-18 20:30:20   Masternodes: 2407, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 34, nDsqCount: 8189
2015-08-18 20:30:20 Writting info to mncache.dat...

The other :

Code:

2015-08-18 20:51:45 receive version message: /DashJ:0.12.2/Dash Wallet:4.18.11.1.22b/: version 70076, blocks=321577, us=127.0.0.1:9999, peer=2932
2015-08-18 20:51:47 Verifying mncache.dat format...

Code:

2015-08-18 21:18:54 Verifying mncache.dat format...

Last message really often about mncache.dat...

V12 Release

Official Dash Dev

Well-known member

Well-known member

Active member

Well-known member

Active member

Active member

Active member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Active member

Member

MangledBlue

Guest

Well-known member

Active member

Active member