V12 Release

weirdgod said:
Just noticed that all the files in dash-win-32bit zip file, are dated as 1/10/2014 ... which is a bit confusing?
Click to expand...
To create deterministic builds (i.e. the one that can be verified by anyone else who is using the same source) you need all bits to be the same, even the date/time of the binaries.
 
patrolman said:
I think mixing needs to be faster - there needs to be a greater incentive to provide liquidity for mixing. It was suggested in the past that a budget proposal could be put forward to provide mixing liquidity, but as far as I know at the moment it would be a trusted solution, so the suggestion in the past was for trusted community members to offer the service, which I think is a reasonable idea if there has to be trust.

Let's say a masternode currently earns 0.63 DASH per day (according to http://178.254.18.153/~pub/Darkcoin/masternode_payments_stats.html), on average there are about 30.4 days per month, which would be 19.152 DASH earned per month in a masternode. I don't know what would be the best amount for a liquidity provider, but I have had a little trouble mixing 100s at times in the past, so let's say 2 x 500 DASH liquidity nodes. Obviously you would need to offer a greater incentive than that which is offered to run the Masternodes with funds in a cold wallet, so let's say instead of the estimated 19.152 for 1000 DASH for one month, 40 DASH is offered as compensation - 20 DASH for each 500 DASH liquidity provider. It's not an ideal solution, because trust is involved (one entity running both liquidity nodes would not be a good idea in my opinion), but it would be one way of increasing the speed of the mixing process.

Perhaps 20 DASH wouldn't be enough though, for the risk involved. The great thing is, even if it starts out at 50 DASH per node and people agree to it, in the future someone could beat the price, so the funds could be reallocated to the new party with the better offer.
Click to expand...

I agree.
While waiting for next 1000 dash to form next MN, I am running annonymization of the funds... But for 8 rounds it typically needs more than a week... ? We need more nodes doing the anonymization ... I think that if we succeed at providing the basic anonymization (2 rounds) within 15 minutes, and strong 8 rounds in few hours, this would go long way in term of DASH value and user base.
 
weirdgod said:
I agree.
While waiting for next 1000 dash to form next MN, I am running annonymization of the funds... But for 8 rounds it typically needs more than a week... ? We need more nodes doing the anonymization ... I think that if we succeed at providing the basic anonymization (2 rounds) within 15 minutes, and strong 8 rounds in few hours, this would go long way in term of DASH value and user base.
Click to expand...

We actually need it to be much faster than that to have mass appeal, think instant (10 seconds or less) mixing for 2 rounds and 5 minutes for 8 rounds.

Pablo.
 
fible1 said:
We actually need it to be much faster than that to have mass appeal, think instant (10 seconds or less) mixing for 2 rounds and 5 minutes for 8 rounds.

Pablo.
Click to expand...
This is a dream, like a lottery jackpot :)
 
it looks that there are still some issues with v53. After almost one day of running dashd crashed. Here are last few lines of log from console...

Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(07e58f1e932f6a555320e7a3f65de7bb9904e96302f0c364f7f1fa4a381349f7, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(53437783420335dea41d664f07ea872853223afb4ccc4d2da2aaf790f1a5bbaa, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(5549b842aaf10635f29a21cc58bc1fabe61167a30269aae666995b4699d8fdda, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(c8ee6a84aab6a1dd22ef961fde4c2185723a0f57839d550c029eb71aefc8379b, 1), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(088323e10c8b69e23d13c947a55a65ef658f2f1a52ba91f776fc36543c14ccf5, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(f511b08e0b00e76793fde9f80af7268dbb264852f22cbf11eabc6cb3c4d01e11, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 ProcessNewBlock : ACCEPTED
Sat Sep 5 02:02:50 2015 mnb - Got NEW Masternode entry - 7698494c58dcc53aa98f515b9c82d05155b24451a0d53bf812fec7e6a32dd9db - 91.122.44.208:9999 - CTxIn(COutPoint(95195c35875291f9a314b31da6606d8f8d0772fce292292b4423b92e23a4bc17, 2), scriptSig=) - 1441411473

they say nothing interesting for me... node just exits.
 
tungfa said:
I think he means we are jumping versions too fast, and he is probably right there
Click to expand...
I mean we should test new versions within the core people for a few time first,try to lowest the risk of bugs-jumping.Anyway dash goes like time of arrow.If dash goes wrong way,he can not come back to now to reboot because blockchain.
 
dashren said:
I mean we should test new versions within the core people for a few time first,try to lowest the risk of bugs-jumping.Anyway dash goes like time of arrow.If dash goes wrong way,he can not come back to now to reboot because blockchain.
Click to expand...

DASH is extensively tested in a test-net environment - Not all bugs can be found and squashed in test-net - some bugs will only reveal themselves on main-net due to 'higher usage' by users - Working in test-net, with 1% of the system running, does make a difference.....

You can join test-net and witness this for yourself....
 
TanteStefana said:
Thank you so very much! I'm sorry I disappeared, had to go. I did have to add the full path to dashd for some reason, but otherwise it worked. This is what I ended up with. If there is a mistake / bad design that you see could cause issue, please let me know :D

Code: 
#!/bin/bash
while [ true ] ; do
  if [ -z $(fuser -c ~usr1/.dash/dash.pid 2>&-) ]; then
    /usr/local/bin/dashd 1>&-
  fi
  sleep 300
done

I've learned a lot trying to do this, again, thanks!
Click to expand...
I noticed that you run crontab to run this. You don't really need the while loop if you do so because crontab will run your script periodically. You will end up with many many instance of your script. By the web, you don't even need a script. You can run:

Code: 
if [ -z $(fuser -c ~usr1/.dash/dash.pid 2>&-) ]; then /usr/local/bin/dashd 1>&- ; fi

In my original example for crontab, I also sleep for a random number of seconds because You don't want to start the MNs at the same time. The loads is pretty high during startup of a MN. "jot" just creates a random number.
 
"CActiveMasternode::ManageStatus() - not capable: Hot node, waiting for remote activation."

No matter how much remote activation it gets... .53, reindexed... Been 8 hours. Both sides are .53.

More info... This is really weird...

When the Big Wallet sends activations, it sends all of them, but as I watch the debug.log of each masternode, it gets really interesting...

All masternodes debug a list of the activations instantly. But, each one finds itself excluded from that list. To say it another way, if 4MNs are started on the Big Wallet, MN1 shows all but itself and still waits to be activated. MN2 shows all but itself, etc... It's like something is causing the node to exclude itself from the ability to read the announcement... It always sees everything but itself.

Update: I experimented with a smaller block of nodes to make it easier. I made sure all were on current version, and re-indexed. Same with the Big Wallet. I can confirm that the masternode daemons are self-excluding. I fired off a start-many for 3 nodes. All 3 get the "new masternode" announce immediately, but themselves are never in the list. MN1 shows MN2 and MN3 in debug. MN2 shows MN1 and MN3 in the debug. MN3 shows MN1 and MN2 in the debug. They hang around waiting to be made active, ignoring even explicit masternode start-alias. Again, if I run masternode start-alias MN1, MN2 and MN3 immediately see it in debug, but MN1 never shows any debug data. If I run masternode start-alias MN2, MN3 and MN1 both immediately see it in their debug, but MN2 never shows anything in it's debug...

cat ~/.dash/debug.log | grep "Enabled"

Returns nothing.

cat ~/.dash/debug.log | grep "Hot"

Long list of:

not capable: Hot node, waiting for remote activation.

cat ~/.dash/debug.log | grep "Ping"

Error on Ping: Darksend Masternode List doesn't include our Masternode, shutting down Masternode pinging service!

So, it was never enabled, but it's being shut down? Sumthins wonky...
 
Last edited by a moderator:
Defacto said:
it looks that there are still some issues with v53. After almost one day of running dashd crashed. Here are last few lines of log from console...

Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(07e58f1e932f6a555320e7a3f65de7bb9904e96302f0c364f7f1fa4a381349f7, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(53437783420335dea41d664f07ea872853223afb4ccc4d2da2aaf790f1a5bbaa, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(5549b842aaf10635f29a21cc58bc1fabe61167a30269aae666995b4699d8fdda, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(c8ee6a84aab6a1dd22ef961fde4c2185723a0f57839d550c029eb71aefc8379b, 1), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(088323e10c8b69e23d13c947a55a65ef658f2f1a52ba91f776fc36543c14ccf5, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 CBudgetVote::SignatureValid() - Unknown Masternode - CTxIn(COutPoint(f511b08e0b00e76793fde9f80af7268dbb264852f22cbf11eabc6cb3c4d01e11, 0), scriptSig=)
Sat Sep 5 02:02:29 2015 ProcessNewBlock : ACCEPTED
Sat Sep 5 02:02:50 2015 mnb - Got NEW Masternode entry - 7698494c58dcc53aa98f515b9c82d05155b24451a0d53bf812fec7e6a32dd9db - 91.122.44.208:9999 - CTxIn(COutPoint(95195c35875291f9a314b31da6606d8f8d0772fce292292b4423b92e23a4bc17, 2), scriptSig=) - 1441411473

they say nothing interesting for me... node just exits.
Click to expand...
Can someone comment on this? Do these log messages tell us anything? I think it is just a regular log file.
 
Last edited by a moderator:
camosoul said:
"CActiveMasternode::ManageStatus() - not capable: Hot node, waiting for remote activation."
cat ~/.dash/debug.log | grep "Enabled"

Returns nothing.

cat ~/.dash/debug.log | grep "Hot"

Long list of:

not capable: Hot node, waiting for remote activation.

cat ~/.dash/debug.log | grep "Ping"
Click to expand...

I'm seeing a lot of UUOC in here! If you want, you can save a few keystrokes each time:

Code: 
grep "Enabled"  ~/.dash/debug.log
 
GermanRed+ said:
Can someone comment on this? Do these log messages tell us anything? I think it is just a regular log file.
Click to expand...

another node... just crashed today with that same way...

pid 7619 (dashd), uid 65534: exited on signal 10 (core dumped)​

last few lines:
Sun Sep 6 20:01:43 2015 ProcessNewBlock : ACCEPTED
Sun Sep 6 20:02:15 2015 CheckBlock() : skipping transaction locking checks
Sun Sep 6 20:02:15 2015 CheckBlock() : skipping transaction locking checks
Sun Sep 6 20:02:15 2015 CheckBlock() : skipping transaction locking checks
Sun Sep 6 20:02:15 2015 UpdateTip: new best=00000000000e192131292c57a34e4182a1876f6e3eb5f1e2540d26243998fc55 height=331943 log2_work=61.692923 tx=1332485 date=2015-09-06 18:01:53 progress=0.999999 cache=2898
Sun Sep 6 20:02:15 2015 ProcessNewBlock : ACCEPTED
​
i got this time dashd.core dump...
is that problem known? anybody experience this type of crash?
 
You must log in or register to reply here.
Back
Top