V12 Testing Thread

AjM said:
Masternodes does not get to sync, bc is synced (maybe), waited already 15 min, pbar says 15 h behind, also info says zero masternodes, dunno...
Click to expand...

Interesting debug.log rows...
Code: 
2015-08-12 12:50:33 Running DashMiner with 1 transactions in block (182 bytes)
2015-08-12 12:50:33 keypool added key 1089, size=1001
2015-08-12 12:50:33 init message: Loading wallet... (108.79 %)
2015-08-12 12:50:33 keypool reserve 89
2015-08-12 12:50:33 CreateNewBlock: Failed to detect masternode to pay
2015-08-12 12:50:33 CreateNewBlock(): total size 1000
2015-08-12 12:50:33 Running DashMiner with 1 transactions in block (182 bytes)
2015-08-12 12:52:12 DashMiner terminated
2015-08-12 12:52:12 keypool return 87
2015-08-12 12:52:12 DashMiner terminated
2015-08-12 12:52:12 keypool return 89
2015-08-12 12:52:26 Timeout downloading block 00000126ef1392521ab14173e6b407f89e434b52f2cce0072c99f2d8debc54e7 from peer=1, disconnecting
2015-08-12 12:52:27 receive version message: /Dash Core:0.12.0.35/: version 70100, blocks=78699, us=37.136.76.102:3142, peer=10
2015-08-12 12:52:27 Added time data, samples 10, offset -39 (+0 minutes)
2015-08-12 12:52:31 CMasternodeSync:ProcessMessage - ssc - got inventory count 2 8
2015-08-12 12:52:31 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:31 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:52:32 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:52:32 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:53:13 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(aa8d84f3531747fdf9d99cf6f7df57a8db7fa6622345e953cc7df1738299dabc, 1), scriptSig=)
2015-08-12 12:53:13 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:53:13 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:53:13 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:53:13 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:53:41 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(7a10ff36ba1f75331922257c0523e2950f331e5e40cd0a70534d75a9bb3675e8, 1), scriptSig=)
2015-08-12 12:54:39 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:54:39 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:55:06 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:55:06 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:55:10 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(70e17ed9962a1b505f06b495beebd500b1c7dc2ab9362b188ab6648af582375c, 1), scriptSig=)
2015-08-12 12:55:11 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:55:11 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:57:07 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(3184ca10a51828743fc48a21afa4fcb70c367b7a8747ac8035c9ae3e2d0aaa4c, 3), scriptSig=)
2015-08-12 12:57:08 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:57:08 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:57:08 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(9615bdce9391e5fa7cb60ad77726695a5b316f6e7c4be072771b388bcfa7d7d7, 0), scriptSig=)
2015-08-12 12:57:09 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:57:09 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:58:38 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(bf7efa440e138ec5fb821ccf91a5b92e931f360bb6c21450260903038a2c853e, 0), scriptSig=)
2015-08-12 12:58:38 CMasternodeMan::AskForMN - Asking node for missing entry, vin: CTxIn(COutPoint(b3d76223f52d40a02be852f92c53c37f8df233d38e0913a7ae05c06028f38558, 1), scriptSig=)
2015-08-12 12:58:39 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:58:39 ProcessMessage(mnb, 384 bytes) FAILED peer=10
2015-08-12 12:58:40 ProcessMessages(mnb, 384 bytes): Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2015-08-12 12:58:40 ProcessMessage(mnb, 384 bytes) FAILED peer=10
 
v0.12.0.43-6c6196a
Synced ok, very slow, about 1 min.
8 mnodes only.

Edit: No clue what is correct block count.
 
 
windows 64bit / windows 10
v0.12.0.43-7f27d02

- observation : once fully synced the "'out of sync" warning in the wallet has a tendency to stay visible for some time before getting cleared
 
UdjinM6 Eduffield

I'm still seeing some conflicted transactions (see Testdash 2 & 5) eventhough all my wallets are in full sync

bcpvkWU.jpg


19:30:01

getmininginfo

{
"blocks" : 83282,
"currentblocksize" : 0,
"currentblocktx" : 0,
"difficulty" : 0.00827825,
"errors" : "",
"genproclimit" : -1,
"networkhashps" : 71637,
"pooledtx" : 29,
"testnet" : true,
"chain" : "test",
"generate" : false,
"hashespersec" : 0
}
 
Last edited by a moderator:
i wonder if we could not somehow prioritize the Darksend transactions, those still unconfirmed (and oldest) should get higher priority towards getting confirmed
and those transactions that are already confirmed a number of times (6+ or something) should get lower priority.
i'm just thinking outloud here... for all i know this could be going straight against how blockchain confirmations works.
 
qwizzie said:
i wonder if we could not somehow prioritize the Darksend transactions, those still unconfirmed (and oldest) should get higher priority towards getting confirmed
and those transactions that are already confirmed a number of times (6+ or something) should get lower priority.
i'm just thinking outloud here... for all i know this could be going straight against how blockchain confirmations works.
Click to expand...
I always thought they were prioritized due to time spent in the memory pool, could be low hash rate and small network instabilites causing spurious results.
 
Using v0.12.0.43-7f27d02, I just started 3 wallets, only 1 needed -reindex (stuck @ 83499), other 2 took a little longer to open - synching sporks and MN winners, all currently match same block (83312) as Insight, and 1 wallet successfully started 7 MNs, all of which are ENABLED. All looks not too bad, will try some DS and IX I suppose.
 
bertlebbert said:
Using v0.12.0.43-7f27d02, I just started 3 wallets, only 1 needed -reindex (stuck @ 83499), other 2 took a little longer to open - synching sporks and MN winners, all currently match same block (83312) as Insight, and 1 wallet successfully started 7 MNs, all of which are ENABLED. All looks not too bad, will try some DS and IX I suppose.
Click to expand...
Flood me until you are running on unconfirms please,
y74W8s3qNQBHZCcJSvXH8A5BzRe8TVz26M
 
bertlebbert said:
K, IX or regular? or does it matter?
Click to expand...
I only know how to flood with IX using this,
dash-cli sendtoaddressix yEXdUTyTj1hYabR9ZLQMAsTgAsJxskcUTA .01
dash-cli sendtoaddressix yEXdUTyTj1hYabR9ZLQMAsTgAsJxskcUTA .01
dash-cli sendtoaddressix yEXdUTyTj1hYabR9ZLQMAsTgAsJxskcUTA .01
etc...

edit: there is a sendtoaddress command but its not as much fun
 
Sub-Ether said:
I only know how to flood with IX using this,
dash-cli sendtoaddressix yEXdUTyTj1hYabR9ZLQMAsTgAsJxskcUTA .01
dash-cli sendtoaddressix yEXdUTyTj1hYabR9ZLQMAsTgAsJxskcUTA .01
dash-cli sendtoaddressix yEXdUTyTj1hYabR9ZLQMAsTgAsJxskcUTA .01
etc...

edit: there is a sendtoaddress command but its not as much fun
Click to expand...
sent 7x, all good and confirmed 5/6.
 
Sub-Ether said:
your address, Sir?
Click to expand...
yGy2t53G6gVHRKdi5GLSU2vCMBCnZF3nbX

Did you sent already, cant see anything?
Are we in same chain, i have 83317 now.

Edit: ahaa, now its flooding, thanks.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top