I've upgraded my masternodes to v12.0.49 but I'm still seeing some of them drop off the list after 1-2 hours as EXPIRED. It's strange because the 'expired' masternodes are still active with port open (responding to 'dash-cli getinfo'). Anyone else having this problem?
Sounds like your hot node wasn't activated. I would search the log for this "CActiveMasternode::EnableHotColdMasterNode() - Enabled! You may shut down the cold daemon." |
|
|
|
Can we get an update on this? How does the "hard fork" indicated in Step 2 differ from the typical "spork" that we are used to? Hopefully it's not going to be a "cross your fingers and pray" thing like RC3's (several) attempted forks? Has it already happened, or was this date pushed back when the release was pushed back? Is the first budget block still planned for 9/6? Thanks for any information! Step 1 and 2 are done and were successful. We shouldn't have any failures like RC3 anymore, we have a nice framework for expansion and there's nothing in the plans that could cause issues like that one. Step 3 isn't going to cause any problems, it's basically 4 lines of code Step 4 was tested extensively. I'll be pushing out the first budget proposal soon, then we should see the successful payment of those items on September 6th. |
|
|
|
Thank you Evan, answering FUD with quality words! now you see when main Dev answers you a question... with such an answer that you and rest of crypto FUDers can only say wtf ?  welcome to DASH, the future of crypto FUD is what powers Dash. I've gotten a bunch of ideas from it including the one about the masternode network being an active force to deflect attack. Keep it coming people  |
|
|
|
one word; 51-attack To this day, there has never been a 51% attack, ever, in any coin. Do you even understand how it works? It's a theoretical concept that ALL PoW algorithms "suffer" from, and basically makes the attacker bankrupt. It will allow for 1 double spend before the entire network realizes it, and even if he has 75%+ and manages to highjack the blockchain entirely, every one else would leave. (Like what is happening with Bitcoin-XT) - essencially, destroying the entire value of the coin. And that, does not happen in one 51% attack. a 51% attack theoretically would allow you to spoof ONE block and performa a double spend. Where would you double-spend a few coins? Buy a TV in Overstock.com, and have UPS block the shipment once the companie realizes that block got orphaned later on? Since there are no ASIC's, could someone please calculate the cost of how many 290x's + electrical bill to get over 50GH/s of mining power? Stop making a fool of yourself. You are not making serious questions. The 51% attack has been debated within bitcoin while Satoshi was still posting. We've all witnesses Slash's Pool at 60%, we've all seen GHash.io reach 60%. 51-attack is not one word, it's an alpha-numeric mash-up. Don't be silly. It's a bit naive to think that three letter agencies with unlimited resources can't carry out a 51-attack if they really want to... The goal is to make a confirmationless wallet, where all transactions are protected by IX. 51% attacks become much less powerful in that case, they can't really touch IX. That would protect our millions of users we're currently shooting for (valid / non-illegal users btw), which leaves an attacker one option... to buy masternodes to attack Dash. We know how that will go. We really do have an end-to-end solution to all problems within crypto now. I'm working on a 50+ page whitepaper that details the rest of the solution, I'm quite excited about it  Here's another one for good measure. We have sub-quorums for super secure tasks, but we could implement full-quorum based actions the masternode network can take as a whole. For example, banning attacking pools from the network, people, countries, etc. |
|
|
|
Hmmm, maybe not correct, you should put : First to post on bct that I've updated!  I'm pretty sure I was first  |
|
|
|
*********** v12.0.49 ************* - This fixes a couple other issues dealing with masternodes staying online/getting kicked off and syncing https://www.dashpay.io/downloads/ |
|
|
|
*********** v12.0.48 ************* - Fixed memory leak - Fixed the bug that made masternodes hang sometimes (when waiting for remote activation) https://www.dashpay.io/downloads/ |
|
|
|
One exists, one doesn't. Lightning is centralized by design. It's something like a centralized ledger that is capable of pushing out finalized transaction states to the real ledger at anytime. Drawbacks: - It screws with the UTXO set, because you can't tell where the money actually is in the system - It's 100% centralized and could be prone to regulation. I've seen them talk about this and they say if the centralized node starts to whitelist addresses or something to that effect, they'll just start another one. - It's incredibly complicated and will be prone to errors for the first year or two - It's not really that useful if you're paying different people with every transaction you do. It's more useful for subscriptions or companies that are paying each other all of the time. - There's probably more, but I lost interest The masternode network is decentralized by design and can pretty much do anything a centralized system can do but in a completely decentralized and stable way, including fixing all of these issues with scalability they're having in a much more elegant way. |
|
|
|
*********** 12.0.47 ************* There is a small issue with the way the masternode payment cycle is being calculated, which we've fixed in v47. This will fix the payment cycle so that it doesn't have issues during a network upgrades. Please update if you're running a masternode (end users and pools can stay on v46) https://www.dashpay.io/downloads/Is it a protocol bump? Nope, no cold restart is needed |
|
|
|
*********** 12.0.47 ************* There is a small issue with the way the masternode payment cycle is being calculated, which we've fixed in v47. This will fix the payment cycle so that it doesn't have issues during a network upgrades. Please update if you're running a masternode (end users and pools can stay on v46) https://www.dashpay.io/downloads/ |
|
|
|
Also, how can enforcement be on when there is still unpaid blocks (jmma) and paid to older versions.
We turned it off, the cycle is way too small due to only a few masternodes being updated when v12 came out at first. When it settles down we'll enable it again. In the mean time I asked coinmine to pay random masternodes rather than using the winners list which will work till enforcement is enabled. We'll fix this so it doesn't happen in the next update. |
|
|
|
1) How long until XxDotRpSDzgyAkx3jHkLZD8YYZRwbcjmmA stops hijacking 10%+ of the masternode payments?
2) Is it possible to prevent this from happening during future upgrades?
1.) How about now? 2.) When we stop changing the masternode protocol between versions this will stop. 2 to 3 days per 3-6 months doesn't seem like much of a sacrifice in order to have the type of flexibility to development such different protocols between versions. We're able to explore different ideas and really figure out the best option for the network because of it. |
|
|
|
Damn, i was about to bump dashwhale's post. I'm getting slow.. In the mean time my masternodes are up and running with v0.12.0.46, ready for that 1/100 chance of winning the daily network lottery. question is : do you feel lucky today ? or to be more precise, do you feel lucky 5 days from now ? Here's the last winner: "321988" : "XghcwFhDu5Eg58Cq6iZjw86tTiyBnN28mw:110", "321989" : "XghcwFhDu5Eg58Cq6iZjw86tTiyBnN28mw:109", |
|
|
|
Props to your designer, the site looks great! |
|
|
|
********************* New Version : v12.0.46 ********************** @Udjin: - Added conditional wait to function to improve CPU load - Progressbar sync text - Disable Mncache.dat https://www.dashpay.io/downloads/ |
|
|
|
Build from source choking @ :- /usr/bin/ld: ./leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb2DBE' can not be used when making a shared object; recompile with -fPIC
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
Anyone got a work around? Try 'make clean' and then do everything fresh, "bash autogen.sh && ./configure && make". I had errors like this a couple times and that fixed it for me. |
|
|
|
********** v12.0.45 : New Version ************* Our bamboo issues last night were resolved and 12.0.45 is now available. Please update if you haven't already, everything seems to be working pretty well now. @UdjinM6 chinese tw fix DS bug - endless collateral creation until one of them confirms refactor names and select logic for `ONLY_` coins enum members add masternodeSync.GetSyncStatus() / refactor mn sync status UI updates let translations mix qt and printf fixes for masternrode rpc fix GetSporkValue add mn list and mnw timeouts / use gettime / lower base timeout @eduffield lock wallet for select check mnw peer version fix GetSporkValue return fix spork int error Fix dseg message https://www.dashpay.io/downloads/ |
|
|
|
********** v12.0.45 : New Version ************* This is going to be our official v12 release. Please update if you haven't already, everything seems to be working pretty well now. @UdjinM6 chinese tw fix DS bug - endless collateral creation until one of them confirms refactor names and select logic for `ONLY_` coins enum members add masternodeSync.GetSyncStatus() / refactor mn sync status UI updates let translations mix qt and printf fixes for masternrode rpc fix GetSporkValue add mn list and mnw timeouts / use gettime / lower base timeout @eduffield lock wallet for select check mnw peer version fix GetSporkValue return fix spork int error Fix dseg message https://www.dashpay.io/downloads/Still says: ./dash-cli getinfo { "version" : 120044, "protocolversion" : 70103, yep, we are discussing it at dashtalk too .. both windows versions (32bit and 64bit) have correct download version description 0.12.0.45 and winrar version 0.12.0.45 files but turn out to be v0.12.0.44-61223ed Linux versions also turn out to be v0.12.0.44, as does OSX
Best to hold off with the downloads (any downloads) untill further announcements.FWIW, 61223ed is a commit from yesterday: https://github.com/dashpay/dash/commit/61223ed1476f9c67b8171ed41ee7106ac2013d21Definitely from before the commit marked v0.12.0.45 It's really strange, bamboo says it compiled v45 correctly, but the file inside does say 12.0.44. Hold off while we figure out what's going on with bamboo |
|
|
|
|
Show Posts
