Sub-Ether
Well-known member
Party wouldn't have been the same without TaoOfSatoshi
v0.11.1 - InstantX Release
- Thread starter eduffield
- Start date
oblox
Well-known member
Looks like the site was updated about 5 minutes ago and is now reflecting the v11.1.19 as the latest (coded as InstantX).
Congrats to all--a glorious day indeed. (Yes, I know; glorious means means radiant, shining, brightly lit. But it still applies.:tongue
FWIW--using Arch Linux, DRK 0.11.1.19 (like all previous versions) compiled flawlessly using the command: yaourt -Syua --devel . Thank you Vertoe for introducing me to Arch.:grin:
FWIW--using Arch Linux, DRK 0.11.1.19 (like all previous versions) compiled flawlessly using the command: yaourt -Syua --devel . Thank you Vertoe for introducing me to Arch.:grin:
eduffield
Hey I had an idea for the masternode network today. What if we created a redundancy mode in which I can run a second backup server to a Masternode in a different location or different VPS or even at home so that if my main masternode gets taken down then the backup masternode takes over. This second masternode does not get paid or anything and can only exists if it is tied to an already existing node so you can't use it to sybil attack the network.
In reality the servers act as only one masternode in redundancy mode. This has no benefit to the masternode operators other than supporting the network, VPSs expenses are low and if Darkcoin rises in price I think a lot of people would show support by running in redundancy mode, the backup node could even be one of those raspberry pi 2s people have been testing. So we get the best of both worlds, quality masternodes running on high quality data centers and a backup node running in a different location.
I don't know if its possible, just an idea I had and wanted to present it to you guys, something to think about for the future. If the price of DRK rises a lot we can even require people to run each node with redundancy. You guys can let me know if this makes any sense or if I am completely off. Cheers. :smile:
Hey I had an idea for the masternode network today. What if we created a redundancy mode in which I can run a second backup server to a Masternode in a different location or different VPS or even at home so that if my main masternode gets taken down then the backup masternode takes over. This second masternode does not get paid or anything and can only exists if it is tied to an already existing node so you can't use it to sybil attack the network.
In reality the servers act as only one masternode in redundancy mode. This has no benefit to the masternode operators other than supporting the network, VPSs expenses are low and if Darkcoin rises in price I think a lot of people would show support by running in redundancy mode, the backup node could even be one of those raspberry pi 2s people have been testing. So we get the best of both worlds, quality masternodes running on high quality data centers and a backup node running in a different location.
I don't know if its possible, just an idea I had and wanted to present it to you guys, something to think about for the future. If the price of DRK rises a lot we can even require people to run each node with redundancy. You guys can let me know if this makes any sense or if I am completely off. Cheers. :smile:
Rux
Member
Good one Minotaur
I would setup that masternode in redundancy mode just to secure masternodes in future... even if i had to pay for 2nd server...
imagine someone have ability to ddos some % of masternodes.... and cut them off ... these "plan B" masternodes could kick in... this could be handy to make masternodes even more strong
I would setup that masternode in redundancy mode just to secure masternodes in future... even if i had to pay for 2nd server...
imagine someone have ability to ddos some % of masternodes.... and cut them off ... these "plan B" masternodes could kick in... this could be handy to make masternodes even more strong
crowning
Well-known member
Am I the only one?
Without reloading the complete blockchain from scratch all my darkcoind (Masternodes, my local one for the Abe, some others, you name it) end sooner or later with "Corrupted block database detected. Do you want to rebuild the block database now?".
And yes, I did delete peers.dat, called it with --reindex and --upgradewallet and the whole shebang.
And yes, I do use the official Linux binary, not a self build one.
They did work fine after the upgrade, were in the correct blockchain etc., everything looked great.
But stop it, restart it, error....
Update: darkcoind --reindex fixes the problem...until I stop the daemon and start it again...
Without reloading the complete blockchain from scratch all my darkcoind (Masternodes, my local one for the Abe, some others, you name it) end sooner or later with "Corrupted block database detected. Do you want to rebuild the block database now?".
And yes, I did delete peers.dat, called it with --reindex and --upgradewallet and the whole shebang.
And yes, I do use the official Linux binary, not a self build one.
They did work fine after the upgrade, were in the correct blockchain etc., everything looked great.
But stop it, restart it, error....
Update: darkcoind --reindex fixes the problem...until I stop the daemon and start it again...
Last edited by a moderator:
Updated my MN.
Wow! Less than a 24 hours after release and already 1/3 of the MN's are on a new version. Nice.
Wow! Less than a 24 hours after release and already 1/3 of the MN's are on a new version. Nice.
AlexMomo
Member
Happened to me this morning on all my masternodes.
I had to manually zap the blocks and chainstate folders and peers.dat file. I restarted with --reindex and it solved my problem.
When was the last protocol update? I was able to just restart darkcoind rather than starting my MN from the wallet although it seems like I should have started from the wallet.
My MNs went offline about an hour after I updated and start-many'd them. Start-many'd them again and it seems to have stuck. Didn't -reindex though, and my MN wallet is v60001 or something, so I was probably asking for trouble.
TaoOfSatoshi
Well-known member
I also had this issue. Re-started with -reindex and it seems to be good. I'll wait and see.
hello all,
I'm running into the issue presented here: https://darkcointalk.org/threads/ma...ely-but-nothing-from-hotcold-or-ip-grep.3929/
I've --reindex(ed) but I still can't seem to find any proof that my masternode is actually running. Is the debug log being on the latest block good enough as proof?
Thank you
I'm running into the issue presented here: https://darkcointalk.org/threads/ma...ely-but-nothing-from-hotcold-or-ip-grep.3929/
I've --reindex(ed) but I still can't seem to find any proof that my masternode is actually running. Is the debug log being on the latest block good enough as proof?
Thank you
IX just got mentioned in one of my BTC chatgroup here , i explained a little to one guy ... and the rest of the crowed went CRAZY on me ! (for real )
all stupid haters, but the point is
we are really onto something here !!!
the crazier they go , the more their fear (of us) taints their judgment .... the more we are coming on the sidelines and showing them (BTC and Crpto in general ) what is actually possible in creative coding !!
dam is this exciting
Congrats again to the team for steady innovation and catapulting us straight to the future
Edit: top hater was a writer for BitcoinMagazine , he just got kicked out (that NEVER ever happened on Coin Dojo which is a very well respected BTC Chatroom !!! lol )
all stupid haters, but the point is
we are really onto something here !!!
the crazier they go , the more their fear (of us) taints their judgment .... the more we are coming on the sidelines and showing them (BTC and Crpto in general ) what is actually possible in creative coding !!
dam is this exciting
Congrats again to the team for steady innovation and catapulting us straight to the future
Edit: top hater was a writer for BitcoinMagazine , he just got kicked out (that NEVER ever happened on Coin Dojo which is a very well respected BTC Chatroom !!! lol )
Last edited by a moderator:
I figured out my issue. My masternodeprivkey changed. Here are the steps to fix:
1. Open wallet with your 1,000 DRK
2. Unlock wallet
3. Open Debug Console -> enter "masternode genkey"
4. Copy that key into your darkcoin.conf and/or masternode.conf files on BOTH your 1000 DRK wallet and your masternode. (line reads masternodeprivkey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXX)
For most set-ups, you will change the darkcoin.conf file you use for your 1000 DRK wallet and you will change that value in the darkcoin.conf file you for your masternode
5. Not sure if this step is neccessary, but I ran:
./darkcoind --upgradewallet
waited a 2 minutes
./darkcoind stop,
./darkcoind --reindex
6. After reindexing is done, go back to your Darkcoin wallet with 1000 DRK.
7. Unlock wallet
8. Open Debug Console (if it isn't already open) -> type "masternode start YOURWALLETPASSWORD"
9. You can check if your masternode is enabled by running the command: "./darkcoind masternode list | grep YOURIPADDRESS" (no port is needed)
Have run into three bugs when trying to send an outbound IX.
All cause this dialog to appear:
Bug 1 -- incoming IX is in progress (hung):
Wallet A sends (IX) 1 drk to wallet B. IX hangs with insufficient signature threshold.
Wallet B selects different, existing, confirmed inputs, attempts outbound IX.
Dialog appears.
Bug 2 -- incoming IX is complete with one block confirmation:
Wallet A sends (IX) 1 drk to wallet B. IX meets signature threshold. Confs equal 5.
Block is discovered. Confs equal 6.
Wallet B selects newly received IX input, attempts outbound IX.
Dialog appears.
Bug 3 -- unrelated outbound ix is blocked until incoming ix reaches 6 blocks.
Also, display count exceeds actual count, confusing when compared to dialog message.
Wallet A sends (IX) 1 drk to wallet B. IX meets signature threshold. Confs equal 5.
Wallet B selects different, existing, confirmed inputs, attempts outbound IX.
Dialog appears.
Block is discovered. Conf display shows 6. Still cant send (dialog appears)
Block is discovered. Conf display shows 7. Still cant send.
Block is discovered. Conf display shows 8. Still cant send.
Block is discovered. Conf display shows 9. Still cant send.
Block is discovered. Conf display shows 10. Still cant send.
Block is discovered. Conf display shows 6.
Wallet B can now successfully send non-related-input outbound IX
Thanks for all your hard work team!
All cause this dialog to appear:
Bug 1 -- incoming IX is in progress (hung):
Wallet A sends (IX) 1 drk to wallet B. IX hangs with insufficient signature threshold.
Wallet B selects different, existing, confirmed inputs, attempts outbound IX.
Dialog appears.
Bug 2 -- incoming IX is complete with one block confirmation:
Wallet A sends (IX) 1 drk to wallet B. IX meets signature threshold. Confs equal 5.
Block is discovered. Confs equal 6.
Wallet B selects newly received IX input, attempts outbound IX.
Dialog appears.
Bug 3 -- unrelated outbound ix is blocked until incoming ix reaches 6 blocks.
Also, display count exceeds actual count, confusing when compared to dialog message.
Wallet A sends (IX) 1 drk to wallet B. IX meets signature threshold. Confs equal 5.
Wallet B selects different, existing, confirmed inputs, attempts outbound IX.
Dialog appears.
Block is discovered. Conf display shows 6. Still cant send (dialog appears)
Block is discovered. Conf display shows 7. Still cant send.
Block is discovered. Conf display shows 8. Still cant send.
Block is discovered. Conf display shows 9. Still cant send.
Block is discovered. Conf display shows 10. Still cant send.
Block is discovered. Conf display shows 6.
Wallet B can now successfully send non-related-input outbound IX
Thanks for all your hard work team!
Last edited by a moderator:
I'd just like to add this minor inconvenience to what moocowmoo said: I was mixing coins the whole time we were sending coins and thus had the wallet unlocked for anonymization only. To send coins I had to unlock it properly, but the wallet then locked itself completely afterwards aborting the mixing. Obviously the wallet should go back to the state it was in before initiating a transaction, not locking itself no matter what state it was in.
Ninja-edit: Forgot to mention I'm blown away by the fast progress! You guys are the best; made my day!
Ninja-edit: Forgot to mention I'm blown away by the fast progress! You guys are the best; made my day!