V12 Release

camosoul said:
I got to try the "start-missing" command today.

(My updated from .49 to .51 resulted in a --reindex that I did not specify on the command line, apparently a default behavior now? This delayed long enough for nodes to delist.)

But, it didn't work as advertised. 2 nodes remained active and the sigtimes were reset along with the rest. The command reported all nodes were restarted even though 2 were still active.
Click to expand...

That's weird. Basicaly how that command works is:
Code: 
- hey, do I have this MN in my list?
  - yep, skip it
  - nope, act as usual start-many

Are you sure your wallet was synced when you issued this command?
 
I've been prioritizing updates over playing the game for the most profit. Because I'm a greedy, evil, republican masnternode operator that invented gravity to keep a brotha down...
 
UdjinM6 said:
That's weird. Basicaly how that command works is:
Code: 
- hey, do I have this MN in my list?
  - yep, skip it
  - nope, act as usual start-many

Are you sure your wallet was synced when you issued this command?
Click to expand...
Yup. Had the big wallet up and synced before I even touched the nodes. They all pulled a reindex without being told to do so, so it was a long time. Long enough for most of them to get delisted. Big wallet was syncned waayyy before. That's what created the need to run that command in the first place. Only 2 were left standing. But all were reset as if none...

I'm no expert programmer, but that's a pretty simple bit. I can't see why it would happen, either... It just did...

I've made goofs where I was parsing a list for comparison and read it in incorrectly, so the strings were all goofed and nothing ever matched. Since this is a false-negative situation, it might be something like that... If the data is goofed, the logic can be perfect and it won't work...
 
Last edited by a moderator:
I had the win64 .51 version wallet crash on me with Windows 8. Looks like the same time as the screen went to sleep(not hibernate, just screen blanking). This was also during a darksend mix. Is this a bug?

Debug file here:
2015-08-31 00:21:03 Added time data, samples 23, offset +3 (+0 minutes)
2015-08-31 00:21:03 nTimeOffset = +1 (+0 minutes)
2015-08-31 00:21:03 Last Darksend message: Mixing in progress...
GUI: setGeometry: Unable to set geometry 5x13+596+300 on QWidgetWindow/'QLabelClassWindow'. Resulting geometry: 124x13+596+300 (frame: 8, 31, 8, 8, custom margin: 0, 0, 0, 0, minimum size: 0x0, maximum size: 16777215x16777215).
2015-08-31 00:59:20 AppInit2 : parameter interaction: -listen=0 -> setting -discover=0
2015-08-31 00:59:20 GUI: "registerShutdownBlockReason: Successfully registered: Dash Core didn't yet exit safely..."
 
Do we have a yet unannounced feature in .51 or maybe V12?
When starting to darksend mix a box popped up that said something like sort by "most common" to filter out darksend transactions.
So what does "most common" mean?
It looks like everything except fees and darksend mixing transactions...Maybe a better term would be "standard" or "sent and received". Cool to see new options coming up.
 
Solarminer said:
Do we have a yet unannounced feature in .51 or maybe V12?
When starting to darksend mix a box popped up that said something like sort by "most common" to filter out darksend transactions.
So what does "most common" mean?
It looks like everything except fees and darksend mixing transactions...Maybe a better term would be "standard" or "sent and received". Cool to see new options coming up.
Click to expand...
Here's a Masternode wallet (Testnet but Mainnet should be the same) that shows the most "common" transactions which are MN earnings. This was done due to the requests of many people over the course of testing the wallet. So I'm guessing "most common" is for the type of most transactions on your wallet:


upload_2015-8-30_22-36-20.png
 
TanteStefana said:
That sounds useful? Could you explain what situations it can be used for?
Click to expand...
Say you have five masternodes that you control with one single cold wallet masternode.conf. Two of the five MNs had problems and were delisted, but the other three are still active and are in line to get paid. After verifying everything's okay with the hot servers of those two MN, their daemons say "no suitable coins" when you type masternode debug, which means a cold-start is needed to get those two MN back online.

The easiest way to cold start those two MN is to issue a "start-many" from the cold wallet, but I believe doing so will also cold start the other three online masternodes and move them to the back of the payment line along with your two offline ones.

Previously, if you wanted to make sure not to mess with your operational MN's place in line for payment, you needed to issue a "start-alias MN03", and a "start-alias MN05" (if those were the two offline nodes from your masternode.conf). This new command does the work of finding out which MN from your list are offline and cold starts ONLY those ones, so your other MNs' place in the payment line is preserved. At least that's how I used it. It's just easier management, even if you only have two masternodes in your list.
 
Bridgewater said:
Say you have five masternodes that you control with one single cold wallet masternode.conf.
Click to expand...

Do you have a link on how to run a cold node with just the masternode.conf? I couldn't find it. As I understand it you set up a wallet with no private keys on any computer (even an infected computer) and just run masternode restart based on the .conf file?

I know it's a sideline but would defintiely appreciate the link :).

Pablo.
 
Bridgewater said:
This new command does the work of finding out which MN from your list are offline and cold starts ONLY those ones, so your other MNs' place in the payment line is preserved.
Click to expand...
At least that's how it's supposed to work. My experience is that all nodes were reported started, and those that were active were resigned to the back of the line. Same as if I had used start-many. I'm going to keep using start alias explicitly....
 
fible1 said:
Do you have a link on how to run a cold node with just the masternode.conf? I couldn't find it. As I understand it you set up a wallet with no private keys on any computer (even an infected computer) and just run masternode restart based on the .conf file?

I know it's a sideline but would defintiely appreciate the link :).

Pablo.
Click to expand...

Until version 12.1 is released, you still need the keys that control the 1000 DASH in order to send a masternode start.
(The start packet is signed by the private key associated with the 1000 DASH address.)

Version 12.1 will incorporate two 'proxy' keys that can a) start and b) vote. Leaving the key attached to the 1000 DASH isolated.
This will require some setup, but guides will be built when the functionality is available.

--

Also, since version 12, nodes that were started DO NOT NEED to be started again across typical (non-protocol-bump) updates.

Just launch dashd and wait. It'll start itself if the network saw it as started within the last 70 minutes.
(re-issuing start resets your place in line)

There's a new command 'start-missing' that will only issue starts for nodes that do not meet the criteria above.
 
moocowmoo said:
Also, since version 12, nodes that were started DO NOT NEED to be started again across typical (non-protocol-bump) updates.
Click to expand...

Been that way longer than v12... If your new daemon starts up, recognizes it's key/vin association from masternode.conf, and pings before the 70 minutes, you're on. No need to issue any commands from big wallet. No commands at all, actually. Just get it done in under 70 minutes and you're fine. Worked this way for most of v11's life, too.

moocowmoo said:
There's a new command 'start-missing' that will only issue starts for nodes that do not meet the criteria above.
Click to expand...

I want there to be a caveat with this... I've only tried it once, and it did exactly the same thing as start-many; reset all sigtimes indiscriminately, back of the line... I expect people who have only 1 or a few nodes are most bothered by this. They also don't really save any time over using start-alias since they've only got few... If you've got 40+, you probably don't care if you miss a few payments cuz you're filthy rich already...
 
I'm curious to see how the bitching and whining is going to go with the shared node service operators and votes of people with only have 50 DASH in the pot...

Frankly, if you gave up your responsibility to run the node yourself, you gave up the right to vote... I don't get to vote if I renounce my citizenship... If you can't be asked to do your part, you can suck it.
 
camosoul said:
I'm curious to see how the bitching and whining is going to go with the shared node service operators and votes of people with only have 50 DASH in the pot...

Frankly, if you gave up your responsibility to run the node yourself, you gave up the right to vote... I don't get to vote if I renounce my citizenship... If you can't be asked to do your part, you can suck it.
Click to expand...
Blunt as always... :grin:
 
Solarminer said:
Do we have a yet unannounced feature in .51 or maybe V12?
When starting to darksend mix a box popped up that said something like sort by "most common" to filter out darksend transactions.
So what does "most common" mean?
It looks like everything except fees and darksend mixing transactions...Maybe a better term would be "standard" or "sent and received". Cool to see new options coming up.
Click to expand...

It means everything but mixing-related transactions (like collaterals, denominations and all that stuff).
I didn't like to have my first "real" transaction" show up on page 4, so implemented this filter somewhere in v11.
 
Hi! I found a little bug in InstantX. After successful payment and 1 confirmation "listreceivedbyaddress" shows 6 confirmations (5 IX + 1 BASIC), but "listsinceblock" show only 1 confirmation. Thanks.
 
You must log in or register to reply here.
Back
Top