Dnet listing has been activated at cryptocoin.cc - - http://cryptocoin.cc/table.php?cryptocoin=darknet
Topic: [ANN][PIVX] - PRIVATE INSTANT VERIFIED TRANSACTION - PROOF OF STAKE - ZEROCOIN - page 477. (Read 782382 times)
March 20, 2016, 05:41:31 PM
Dnet listing has been activated at cryptocoin.cc - - http://cryptocoin.cc/table.php?cryptocoin=darknet
March 20, 2016, 04:55:02 PM
I get a similar problem with 1.0.2.0 but not 1.0.1.0
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
Okay, I figured this out. The fix is simple.
Make sure you masternode start-alias from the 2.0.2.0 controller before you start the 2.0.2.0 masternode.
Another thing that you can do which works really well for me is to run your wallet locally as a controller and not a masternode. Then all of your remote nodes can be started with no issues. This is how i recommend people who use the coin-server.com hosting service for master nodes. Running in this manner tends to keep things problem free.
March 20, 2016, 04:32:37 PM
I get a similar problem with 1.0.2.0 but not 1.0.1.0
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
Okay, I figured this out. The fix is simple.
Make sure you masternode start-alias from the 2.0.2.0 controller before you start the 2.0.2.0 masternode.
March 20, 2016, 03:00:38 PM
Can I disable Obfuscating in the conf file? It keeps turning back on messing with my nodes.
March 20, 2016, 02:13:22 PM
Got mine upgraded too. first mn payment took about 30 hours or so?
Looks like we're up to 500+ masternodes now. nice.
Looks like we're up to 500+ masternodes now. nice.
March 20, 2016, 12:34:13 PM
Got mine up and running, brought in 80 dnet 
March 20, 2016, 12:18:56 PM
Are you trying to run 3 nodes locally? Do they all have public facing IP addresses that are distinct?
I'm just upgrading. If I upgrade to 1.0.2.0 the masternode reports it is not capable. If I revert to 1.0.1.0, it works. I'm gong to paste the problem again. I think there is an issue with this release.
I get a similar problem with 1.0.2.0 but not 1.0.1.0
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
March 20, 2016, 12:12:47 PM
I get a similar problem with 1.0.2.0 but not 1.0.1.0
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
I'm getting the exact same issue for last 3 MN that I created. (both 1.0.1.0 & 1.0.2.0)
I've never had this issue with other MN but only with the 3 MN I've set up today...
Edit: Got 1 of 3 using 1.0.2.0 to start locally. No idea why it worked now after failing last 10 goes. Now 2 to go!
Edit2: Now got all 3 started with 1.0.2.0. All I did was follow the guide by BitcoinFX to upgrade. Then started via "start-alias" from controller wallet.
What do you mean by "start locally"?
I have tried many many many times and it can never start with 1.0.2.0 but starts with no issue for 1.0.1.0, using the same protocol to sync a chain and bring up the node.
Are you trying to run 3 nodes locally? Do they all have public facing IP addresses that are distinct?
March 20, 2016, 11:28:23 AM
I get a similar problem with 1.0.2.0 but not 1.0.1.0
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
I'm getting the exact same issue for last 3 MN that I created. (both 1.0.1.0 & 1.0.2.0)
I've never had this issue with other MN but only with the 3 MN I've set up today...
Edit: Got 1 of 3 using 1.0.2.0 to start locally. No idea why it worked now after failing last 10 goes. Now 2 to go!
Edit2: Now got all 3 started with 1.0.2.0. All I did was follow the guide by BitcoinFX to upgrade. Then started via "start-alias" from controller wallet.
What do you mean by "start locally"?
I have tried many many many times and it can never start with 1.0.2.0 but starts with no issue for 1.0.1.0, using the same protocol to sync a chain and bring up the node.
March 20, 2016, 11:14:43 AM
status: going by the velocity of the collections by Master Nodes, I will be able to spin off 14th unit in approx 3 days
I see we have gained 20K overnight , good
I see we have gained 20K overnight , good
March 20, 2016, 10:36:27 AM
whats the rpcport for solo mining?
also why wont it allow
rpcallowip=*
any wild cards at all?
Do you have to enter all rigs manual ip?
also why wont it allow
rpcallowip=*
any wild cards at all?
Do you have to enter all rigs manual ip?
March 20, 2016, 10:17:06 AM
For those of us interested in achieving 'true' privacy and anonymity of transactions, from the client/user perspective, the choice of OS is vital.
Tails - https://tails.boum.org/ (The Amnesic Incognito Live System) - mentioned a few pages back, is an excellent choice for browsing the web and other tasks, although perhaps not as ideal for making crypto transactions, storing blockchains etc., (which is one reason it uses Electrum for Bitcoin).
Again, this is for client wallets i.e. not for Masternodes. So,
Whonix - is perhaps a way forward ...
Realizing that this solution requires at least 2 machines (or 2 Virtual Boxes!), being a "Gateway" and a "Workstation".
- https://wikipedia.org/wiki/Whonix - "...Unlike Tails, Whonix is not "amnesic"; both the Gateway and the Workstation retain their past state across reboots. Not being amnesic improves security on the Gateway, by allowing Tor's "entry guard" system to choose long-lived entry points for the Tor network, reducing adversaries' ability to trap users by running malicious relays."...
- https://www.whonix.org/
"Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network, Debian GNU/Linux and security by isolation.
Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. With Whonix, you can use applications and run servers anonymously over the internet. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP."
or
Qubes OS - https://www.qubes-os.org/ - https://wikipedia.org/wiki/Qubes_OS
..."With Whonix integrated into Qubes, you can easily route network traffic through the Tor anonymity network."...
Tails - https://tails.boum.org/ (The Amnesic Incognito Live System) - mentioned a few pages back, is an excellent choice for browsing the web and other tasks, although perhaps not as ideal for making crypto transactions, storing blockchains etc., (which is one reason it uses Electrum for Bitcoin).
Again, this is for client wallets i.e. not for Masternodes. So,
Whonix - is perhaps a way forward ...
Realizing that this solution requires at least 2 machines (or 2 Virtual Boxes!), being a "Gateway" and a "Workstation".
- https://wikipedia.org/wiki/Whonix - "...Unlike Tails, Whonix is not "amnesic"; both the Gateway and the Workstation retain their past state across reboots. Not being amnesic improves security on the Gateway, by allowing Tor's "entry guard" system to choose long-lived entry points for the Tor network, reducing adversaries' ability to trap users by running malicious relays."...
- https://www.whonix.org/
"Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network, Debian GNU/Linux and security by isolation.
Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. With Whonix, you can use applications and run servers anonymously over the internet. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP."
or
Qubes OS - https://www.qubes-os.org/ - https://wikipedia.org/wiki/Qubes_OS
..."With Whonix integrated into Qubes, you can easily route network traffic through the Tor anonymity network."...
Good stuff,
If anyone is interested, I will gladly add TOR masternodes to my hosting service. And, as soon as I2P is available I will add that as well.
Coin-Server
March 20, 2016, 09:10:52 AM
For those of us interested in achieving 'true' privacy and anonymity of transactions, from the client/user perspective, the choice of OS is vital.
Tails - https://tails.boum.org/ (The Amnesic Incognito Live System) - mentioned a few pages back, is an excellent choice for browsing the web and other tasks, although perhaps not as ideal for making crypto transactions, storing blockchains etc., (which is one reason it uses Electrum for Bitcoin).
Again, this is for client wallets i.e. not for Masternodes. So,
Whonix - is perhaps a way forward ...
Realizing that this solution requires at least 2 machines (or 2 Virtual Boxes!), being a "Gateway" and a "Workstation".
- https://wikipedia.org/wiki/Whonix - "...Unlike Tails, Whonix is not "amnesic"; both the Gateway and the Workstation retain their past state across reboots. Not being amnesic improves security on the Gateway, by allowing Tor's "entry guard" system to choose long-lived entry points for the Tor network, reducing adversaries' ability to trap users by running malicious relays."...
- https://www.whonix.org/
"Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network, Debian GNU/Linux and security by isolation.
Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. With Whonix, you can use applications and run servers anonymously over the internet. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP."
or
Qubes OS - https://www.qubes-os.org/ - https://wikipedia.org/wiki/Qubes_OS
..."With Whonix integrated into Qubes, you can easily route network traffic through the Tor anonymity network."...
Tails - https://tails.boum.org/ (The Amnesic Incognito Live System) - mentioned a few pages back, is an excellent choice for browsing the web and other tasks, although perhaps not as ideal for making crypto transactions, storing blockchains etc., (which is one reason it uses Electrum for Bitcoin).
Again, this is for client wallets i.e. not for Masternodes. So,
Whonix - is perhaps a way forward ...
Realizing that this solution requires at least 2 machines (or 2 Virtual Boxes!), being a "Gateway" and a "Workstation".
- https://wikipedia.org/wiki/Whonix - "...Unlike Tails, Whonix is not "amnesic"; both the Gateway and the Workstation retain their past state across reboots. Not being amnesic improves security on the Gateway, by allowing Tor's "entry guard" system to choose long-lived entry points for the Tor network, reducing adversaries' ability to trap users by running malicious relays."...
- https://www.whonix.org/
"Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network, Debian GNU/Linux and security by isolation.
Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. With Whonix, you can use applications and run servers anonymously over the internet. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP."
or
Qubes OS - https://www.qubes-os.org/ - https://wikipedia.org/wiki/Qubes_OS
..."With Whonix integrated into Qubes, you can easily route network traffic through the Tor anonymity network."...
March 20, 2016, 08:46:50 AM
Dnet devs. changed the download location from DarkNet-1.0.2.0-Linux64.zip to Darknet-Qt-Linux-Wallet-v1.0.2.0.zip
Updated post here: https://bitcointalksearch.org/topic/m.14220860
Updated post here: https://bitcointalksearch.org/topic/m.14220860
Thank you so much for this updated guide. Very much appreciated.
No worries. Tested upgrading only from the previous guide, however the above should all be OK.
Cheers!
March 20, 2016, 08:11:07 AM
Dnet devs. changed the download location from DarkNet-1.0.2.0-Linux64.zip to Darknet-Qt-Linux-Wallet-v1.0.2.0.zip
Updated post here: https://bitcointalksearch.org/topic/m.14220860
Updated post here: https://bitcointalksearch.org/topic/m.14220860
Thank you so much for this updated guide. Very much appreciated.
March 20, 2016, 08:09:31 AM
I get a similar problem with 1.0.2.0 but not 1.0.1.0
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
When enabling from the controller with start-alias, everything looks fine, with a "result":"successful".
Checking the debug.log of the masternode I can see the correct "Got NEW Masternode entry -" line (identified by txid). Then with masternode list, I can see the correct line "ENABLED" (identified by txid).
But when I do masternode status, I get:
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : "Not capable masternode: Hot node, waiting for remote activation."
}
I think there is a problem with the new release.
I'm getting the exact same issue for last 3 MN that I created. (both 1.0.1.0 & 1.0.2.0)
I've never had this issue with other MN but only with the 3 MN I've set up today...
Edit: Got 1 of 3 using 1.0.2.0 to start locally. No idea why it worked now after failing last 10 goes. Now 2 to go!
Edit2: Now got all 3 started with 1.0.2.0. All I did was follow the guide by BitcoinFX to upgrade. Then started via "start-alias" from controller wallet.
March 20, 2016, 07:06:58 AM
I was following the upgrade guide and this file no longer exists on github.
Do I use something else now to upgrade?
Dnet devs. changed the download location from DarkNet-1.0.2.0-Linux64.zip to Darknet-Qt-Linux-Wallet-v1.0.2.0.zip
Updated post here: https://bitcointalksearch.org/topic/m.14220860
Linux / Cloud VPS - DNET command line upgrade guide from: v1.0.1.0 to: v1.0.2.0
Stop the Dnet daemon:
Remove the 'old' Dnet folder and daemon etc:
Download Dnet v1.0.2.0 :
EDIT (new download link):
Re-make the Dnet directory:
Unzip the download :
EDIT:
Move the unzipped files to the 'default' directory :
Tidy up:
Restart the Dnet daemon:
Guide at: http://xeronet.c0m.li/dnet-crypto.php - to be updated.
EDIT: Go here: https://github.com/Darknet-Crypto/Darknet - If you prefer to build from source.
Stop the Dnet daemon:
Code:
cd Darknet
Code:
cd src
Code:
./darknet-cli stop
Code:
cd
Remove the 'old' Dnet folder and daemon etc:
Code:
rm -rv Darknet
Download Dnet v1.0.2.0 :
EDIT (new download link):
Code:
wget https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/Darknet-Qt-Linux-Wallet-v1.0.2.0.zip
Re-make the Dnet directory:
Code:
mkdir Darknet
Code:
cd Darknet
Code:
mkdir src
Code:
cd
Unzip the download :
EDIT:
Code:
unzip Darknet-Qt-Linux-Wallet-v1.0.2.0.zip -d Darknet/src
Move the unzipped files to the 'default' directory :
Code:
mv Darknet/src/Darknet-Qt-Linux-Wallet-v1.0.2.0/darknetd Darknet/src/
Code:
mv Darknet/src/Darknet-Qt-Linux-Wallet-v1.0.2.0/darknet-cli Darknet/src/
Code:
mv Darknet/src/Darknet-Qt-Linux-Wallet-v1.0.2.0/darknet-tx Darknet/src/
Tidy up:
Code:
rm -rv Darknet/src/Darknet-Qt-Linux-Wallet-v1.0.2.0
Code:
rm -rv Darknet/src/__MACOSX
Code:
rm -R Darknet-Qt-Linux-Wallet-v1.0.2.0.zip
Restart the Dnet daemon:
Code:
cd Darknet
Code:
cd src
Code:
./darknetd
Code:
./darknet-cli getinfo
Code:
./darknet-cli masternode start
Guide at: http://xeronet.c0m.li/dnet-crypto.php - to be updated.
EDIT: Go here: https://github.com/Darknet-Crypto/Darknet - If you prefer to build from source.
March 20, 2016, 04:47:05 AM
The zip you mention was there about 2 hours ago.
Use these.
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknetd
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknet-cli
Use these.
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknetd
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknet-cli
Thanks!
btw, I downloaded above and after starting it, when I run darknet-cli, it shows as below which is no different to my 1.0.1.0 masternodes.
How can I determine if I'm running the newer 1.0.2.0?
Quote
root@Client:~# ./darknet-cli getinfo
{
"version" : 1000100,
"protocolversion" : 70104,
"walletversion" : 61000,
{
"version" : 1000100,
"protocolversion" : 70104,
"walletversion" : 61000,
your upgrade was not successful otherwise ./darknet-cli getinfo will show:
{
"version" : 1000200,
.....
}
edit: try another upgrade with this wget link (works for me):
wget https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/Darknet-Qt-Linux-Wallet-v1.0.2.0.zip
March 20, 2016, 04:34:21 AM
The zip you mention was there about 2 hours ago.
Use these.
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknetd
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknet-cli
Use these.
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknetd
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknet-cli
Thanks!
btw, I downloaded above and after starting it, when I run darknet-cli, it shows as below which is no different to my 1.0.1.0 masternodes.
How can I determine if I'm running the newer 1.0.2.0?
Quote
root@Client:~# ./darknet-cli getinfo
{
"version" : 1000100,
"protocolversion" : 70104,
"walletversion" : 61000,
{
"version" : 1000100,
"protocolversion" : 70104,
"walletversion" : 61000,
March 20, 2016, 04:18:30 AM
Download Dnet v1.0.2.0 :
Code:
wget https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/DarkNet-1.0.2.0-Linux64.zip
I was following the upgrade guide and this file no longer exists on github.
Do I use something else now to upgrade?
The zip you mention was there about 2 hours ago.
Use these.
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknetd
https://github.com/Darknet-Crypto/Darknet/releases/download/v1.0.2.0/darknet-cli
Jump to: