V12.1 Testnet Launch Thread

Status
Not open for further replies.
Windows 10 local wallet and 2 Masternodes on Ubuntu servers

With the new build, if I try to use the tools in the wallet to zapwallettxes, and it restarts, it still hangs on "do not shut down until this window disappears" I have to end task to stop it.

Also, one masternode server dropped off after updating. The other is fine. My local wallet says it's still good but the remote server says it's waiting for input. Situation still same after restarting local and remote.

When I try to start it, it gives me the error "failed to start.... could not allocate vin" Nothing was changed in the masternode.conf

Hope this is pertinent:
Code: 
2016-05-25 22:57:24 ProcessNewBlock : ACCEPTED
2016-05-25 22:57:25 CActiveMasternode::GetMasterNodeVin - Could not locate valid vin
2016-05-25 22:57:25 CActiveMasternode::CreateBroadcast() - Could not allocate vin 6ec8b52d1325c0495b507288208b07d79e46d73676a8867c2e6b8c812cc67c08:1 for masternode 216.45.55.246:19999
2016-05-25 22:57:27 CMasternodeSync::Process() - tick 151 RequestedMasternodeAttempt 0 RequestedMasternodeAssets 4 nSyncProgress 0.750000
2016-05-25 22:57:34 CMasternodeSync::Process() - tick 157 RequestedMasternodeAttempt 0 RequestedMasternodeAssets 4 nSyncProgress 0.750000
2016-05-25 22:57:40 CMasternodeSync::Process() - tick 163 RequestedMasternodeAttempt 0 RequestedMasternodeAssets 4 nSyncProgress 0.750000
2016-05-25 22:57:46 CMasternodeSync::Process() - tick 169 RequestedMasternodeAttempt 0 RequestedMasternodeAssets 4 nSyncProgress 0.750000
2016-05-25 22:57:52 CMasternodeSync::Process() - tick 175 RequestedMasternodeAttempt 0 RequestedMasternodeAssets 4 nSyncProgress 0.750000
2016-05-25 22:57:58 CMasternodeSync::Process() - tick 181 RequestedMasternodeAttempt 0 RequestedMasternodeAssets 4 nSyncProgress 0.750000
2016-05-25 22:57:58 ProcessMessages(dstx, 2373 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2016-05-25 22:57:58 ProcessMessages(dstx, 2373 bytes) FAILED peer=5
2016-05-25 22:58:04 CMasternodeSync::Process() - tick 187

Also still stuck on Synchronizing additional data
 
Last edited:
qwizzie said:
The commandline option "privatesendmultisession=1" is really putting the turbo on the whole Privatesend mixing, i'm loving it.
Now we just need better message propagation (as i'm still having some conflicted transactions during mixing).
update : actually only one transaction got conflicted so far, the rest seems to be confirming just fine

I can also confirm that the Windows 10 (64bit) wallet has problems with showing correct amount and rounds after having changed it.

edit : i also decided to ban the peers that are not on version 70200 ..
you may wonder why ? because i can !! :D
Click to expand...

Does that in any way compromise quality of the mix? I mean, the mixing used to be spaced out to reduce the ability to do timing attacks, no? or some such? ???

If not, then why isn't this default? (hee hee hee, Just noticed Mangled asked same question)
 
MangledBlue said:
So if this option: "privatesendmultisession=1" works so well - why is it not on by default?
Click to expand...
Because it would be too fast for normal user. :rolleyes: Keypool has only 1000 keys by default and at that speed it would be depleted in no time - you need to be very careful with your wallet and backups but imo normal users only remember about that when things already gone wrong badly. We could set keypool to say 10.000 keys by default but this would significantly slowdown wallet creation (and again, no guarantee that there won't be wallet corruption one day and "ah,oh" situation). Better (but harder) option would be a properly implemented hd wallet so that no matter how many keys were used all of them were recoverable using one single master private key or seed. Hopefully we'll get there one day ;)
TanteStefana said:
With the new build, if I try to use the tools in the wallet to zapwallettxes, and it restarts, it still hangs on "do not shut down until this window disappears"
...
Click to expand...
I had same issue too, found nothing suspicios in code so far though...
@crowning I bet you're more familiar with restart/repair code ;) could you have a look into this pls?
 
What about not being able to restart my second masternode? I haven't changed anything on it, but it can't find my initial TX apparently?

Also, is everyone else still not synchronizing? I'm still stuck at 75%

Just want to make sure, we're on this version, right?
Dash Core version v0.12.1.0-585544a (64-bit)
 
Last edited:
TanteStefana said:
What about not being able to restart my second masternode? I haven't changed anything on it, but it can't find my initial TX apparently?

Also, is everyone else still not synchronizing? I'm still stuck at 75%

Just want to make sure, we're on this version, right?
Dash Core version v0.12.1.0-585544a (64-bit)
Click to expand...

Pretty sure everybody Is stuck @ 75%

:p
 
OK, thanks Mangled :)

Update, I just decided to open my hot wallet to start the MN and it started. I don't think I could have run out of time, but maybe the stars were misaligned?? Anyway, I guess we still need our hot wallets to start the masternodes if they drop off? I was hoping we could do it with an empty wallet :p
 
@TanteStefana Evan's fix for syncing process was merged only 2 hours ago so new version is coming soon.
I'm looking into mn broadcast relay issues, so probably there will be few more fixes later.
 
Yah, sounds good :)

Are we supposed to be able to start MNs with a non-hot wallet? That is, without the actual funds in it, just the masternode.conf file?
 
UdjinM6 said:
Because it would be too fast for normal user. :rolleyes: Keypool has only 1000 keys by default and at that speed it would be depleted in no time - you need to be very careful with your wallet and backups but imo normal users only remember about that when things already gone wrong badly. We could set keypool to say 10.000 keys by default but this would significantly slowdown wallet creation (and again, no guarantee that there won't be wallet corruption one day and "ah,oh" situation). Better (but harder) option would be a properly implemented hd wallet so that no matter how many keys were used all of them were recoverable using one single master private key or seed. Hopefully we'll get there one day ;)

I had same issue too, found nothing suspicios in code so far though...
@crowning I bet you're more familiar with restart/repair code ;) could you have a look into this pls?
Click to expand...

An HD wallet would be rockin :D.

Pablo.
 
nice to be back in testing. running an MN and mining. Any good p2p pool?

seeing this often in my debug log: Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
 
Last edited by a moderator:
 
jiggytom said:
...
seeing this often in my debug log: Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
Click to expand...
ignore that, it will go away once everyone are on 70200
 
Great, my MNs are updated and running successfully and I'm just waiting for the windows to download :)

I see a lot of masternodes including mine.

I had some kind of denomination tx that wouldn't confirm in the previous version. It wouldn't go away when I did --zapwallettxes I even reindexed and it wouldn't go away.

With this new version, it looks like it has finally got some confirmation. And finally, my mixing has started up again! (Applause!!!!)

Also, no more syncing issues, it's cleared up :)
 
Last edited:
Status
Not open for further replies.
Back
Top