Have you started masternode from your local wallet via "masternode start-alias someAliasHere"?
Hi, thanks for your reply UdjinM6, I haven't reached the point of trying to start the masternode yet which is step 9 I think, I'm still stuck on step 7. There is some problem with sentinel connecting to the daemon or something it seems like. Can I clarify has the port changed? It used to be 9999 and is now 9998 ? Do I need to reconfigure my firewall ? I bet the guide just should be slightly updated  @moocowmoo did a LOT of work to put this all together, no wonder if some steps are not quite polished yet  EDIT: same issue, same solution https://www.dash.org/forum/threads/version-12-1-release.12985/#post-113033 Appreciate the help guys, but I'm not there yet, will keep going tomorrow. From TaoOfSatoshi guide looks like i need port 9999 after the IP address in dash.conf which I've put back in. Now I'm trying to remote start the masternode using "masternode start-missing <passphrase>" in the local debug console but its not working says "Error: Please enter the wallet passphrase with walletpassphrase first. (code -13)" Providing password in "masternode start-<mode>" is not supported anymore. "walletpassphrase <passphrase> 9999" cli command to unlock your wallet first (9999 is timeout in seconds). "walletlock" (after you're done with "masternode start-<mode>") will lock your wallet again. Or unlock/lock it via menu like @stray suggested. |
|
|
|
Have you started masternode from your local wallet via "masternode start-alias someAliasHere"?
Hi, thanks for your reply UdjinM6, I haven't reached the point of trying to start the masternode yet which is step 9 I think, I'm still stuck on step 7. There is some problem with sentinel connecting to the daemon or something it seems like. Can I clarify has the port changed? It used to be 9999 and is now 9998 ? Do I need to reconfigure my firewall ? I bet the guide just should be slightly updated @moocowmoo did a LOT of work to put this all together, no wonder if some steps are not quite polished yet EDIT: same issue, same solution https://www.dash.org/forum/threads/version-12-1-release.12985/#post-113033 |
|
|
|
I've reached this point. step 7) test sentinel has nothing to say
at this point, running
venv/bin/python bin/sentinel.py
should return nothing but silence. This is how you know it's working. Even though it seems to have synced correctly. It says, Invalid Masternode Status, cannot continue. Anyone know what I have to do to fix that? I'm still having this problem, some more info when I run the command, dash-cli masternode status it says my protocol version is wrong "status": "Not capable masternode: Invalid protocol version" why would that be? running the getinfo command tells me my protocol info as "version": 120100,
"protocolversion": 70206,
If this is not the right place to get help can someone point me where I should look? I thought I'd be able to crack this but obviously something has gone wrong somewhere Have you started masternode from your local wallet via "masternode start-alias someAliasHere"? |
|
|
|
Afaik this feature is obsolete, and currently it's not possible. Maybe in 12.1 the feature will return, not sure about it though. If Udjin lurks around here he might be able to answer. Yep, this thing is deprecated. NOT going to be implemented in 12.1 - we had issues with figuring out the right mn winner when donations were enabled which was causing forks. Mn winner detection was refactored and improved (hopefully) in 12.1, so let's see how new winner detection is going to perform on mainnet first and then _maybe_ we can try to get this feature back (not promising anything though). |
|
|
|
It all takes time, so you need to look at this in perspective: Isn't facilitating DarkSend the entire point of Masternodes?...time passed... Isn't facilitating DarkSend and InstantX the entire point of Masternodes?...time passed... Isn't facilitating DarkSend, InstantX and Governance the entire point of Masternodes?.... To be continued |
|
|
|
... snip...
With this new major exchange coming on board and stress testing instantx/instantsend is it now time to implement the 2MB blocks? If this would finally bring us some tx volume - I guess so. So far our blocks are 1-10kb however, so we still have plenty of free space. Not sure which path bitcoin is going to take trying to solve this issue (segwit or BU or something else), so it's hard to say how to stay compatible and expand at the same time. Personally, I really like the idea of dynamic block size limit, specifically bip104 https://github.com/bitcoin/bips/blob/master/bip-0104.mediawiki |
|
|
|
I think that in order to get more efficiency from the budget system we need to do one or more of the following things:
a) Lessen the time factor--There is a real sense of urgency, in that we have only one month (at most) to plan and make proposals to the network before the funds or irretrievably "lost" for future development.
b) Given that any unallocated funds are lost forever (by simply not being created), we have a situation in which there is essentially zero cost for failure. If a proposal doesn't work out, then so what? The funds would have been lost anyway. The flip side is that almost any proposal with even the slightest chance of bringing value to the ecosystem is worthwhile, from a strict cost-benefit analysis. Take the latest proposal to integrate with a major exchange: that's just over 2,000 DASH or $30,000 USD. Not spending that money would effectively increase the value of all DASH in existence by half a cent, which is infinitesimal.
c) Communication must be improved. The creation of the new subforum is an excellent start.
My suggestion is to allow the network to "bank" any unspent funds so that they can be used at a later time by worthy projects. This has several advantages:
1) There's an incentive for saving. Today's unused funds will likely be worth quite a bit more in the future, due to price appreciation. This month's proposals, therefore, essentially have to compete against the possibility of even better proposals in the future. We don't want to fund marginal projects today, since that takes money away from potentially better projects in the future.
2) It eliminates the time factor, since there's no longer a hurry to spend funds before we lose them (i.e. before the month's superblocks are created). That gives more time to craft better proposals, more time for communication, and greater ability to hold contractors accountable (since there's no rush to approve expenditures).
3) It alters the cost-benefit analysis, because now the cost of disapproving a proposal is lower and the cost of approving a proposal is higher, since the funds if unused would be available for future projects.
P.S. It is vitally important that masternode owners realize there is risk in everything, and that it is up to them to assess the risk. There have been, and will continue to be, budget proposals that simply don't work out very well. That's simply how the world works--there are no guarantees in anything. All we can do is assess the risk and make the best possible decision with the information we have. If something doesn't work out, we learn from it and use that knowledge later. Failure is to be expected; if we never fail, it's because we never aspired.
Couple of VERY important points you bring up on this that I've never understood and never agreed on...why can't the funds be "banked"  This urgency to spend the funds before they are "burned" is ridiculous. This should be addressed...unless there is some compelling technical reason as to why we can't do this, this requirement should be removed. And second back to my original point...and one you touch on here...we need a very clear way to assess the performance of the budget system. Certainly we are all grown ups here(well most are here... lol ) and can assess risk using our own criteria. The problem is that the information to make this kind judgement of system is incomplete and not readily available. This is quite problematic. So to recap...2 things need to be addressed, we should be advocating the removal of the time limit on spending the funds in a limit time frame and 2 creating a portal to which not only masternode operators but the community at large can gauge the performance of our system. The issue was a technical one if I remember correctly. People balked at members of Core being in control of the "bank" (for good reason) -- and it wasn't feasible for funds to be in a n of m multisig account as the the m (number of masternodes) is always changing. If fact, I don't think a proposal can even be paid out to any type of multisig account currently... 12.1 and Sentinel may allow such a functionality and it does make sense to explore this "bank" if it is technically feasible. A dev can probably offer more insight. Just to clarify, by "banked" I mean "uncreated, but able to be created in a future superblock." Essentially, I'm suggesting that the network "remember" how many Dash have gone uncreated, and be able to create that many Dash in a future month. For example, under the present system (hypothetical) with a maximum budget of 7450 DASH per month: Month 1 -- 5218 DASH paid to proposals, 2232 unpaid and never created Month 2 -- 6938 DASH paid to proposals, 512 unpaid and never created Month 3 -- 6277 DASH paid to proposals, 1173 unpaid and never created Month 4 -- 9000 DASH in proposals have enough votes to be paid, but the limit is still 7450 DASH, meaning *at least* 1550 DASH worth of proposals end up being unpaid Under a new system where unused funds are "banked" or "remembered" by the network: Month 1 -- 5218 DASH paid to proposals, 2232 unpaid and never created, network remembers that it can create up to 2232 more DASH Month 2 -- 6938 DASH paid to proposals, 512 unpaid and never created, network knows that it can create up to 2744 more DASH Month 3 -- 6277 DASH paid to proposals, 1173 unpaid and never created, network knows that it can create up to 3917 more DASH Month 4 -- 9000 DASH in proposals have enough votes to be paid, network pays all proposals, since there are plenty of funds to do so (7450 DASH for the month, plus 3917 previously "banked" or "remembered" DASH that could have been created, but weren't) Now, you don't want this to go on forever; uncreated DASH eventually have to "expire." The original discussion of DGBB involved the possibility of "banking" uncreated DASH, but the worry was that superblocks might end up creating an insane amount of DASH one month due to all the uncreated DASH being expended all at once. There's also the risk of perverse incentive: if a massive amount of uncreated DASH was remembered by the network, a few masternode owners could collude and create a worthless proposal that would vote all the funds to themselves. It would hurt Dash, but they huge payout would make it worthwhile. I think it would be beneficial for the network to have a three month "memory." Nothing crazy, but enough to be a little flexible. Sounds like a good idea to explore in 12.2+. Should also be easier/less resource hungry to scan past blocks because superblocks are not going to be paid in N blocks (N is number of approved proposals, 1..100, flexible) but in 1 single superblock. |
|
|
|
DASH governance system
Dash's governance is way way way more fair and decentralized than BTC, which is controlled by only a handful of centralized miners in china. Nope. Dash does not have a governance system. Governance implies that you can force a change. The only thing the budget system can do is pay out a project that is submitted. Proof: Budget passed to increase block size to 2MB. Result is still 1MB blocksize. Of course, this proposal is used over an over to say Dash can increase the blocksize in 24 hours....um. right....1 year and still no change. The only ones that can control changes are those with access to github. And even then, the code needs to be created and tested before it can be approved. Charlie was spot on with the "Marketing over Tech". To get you started on that blocksize increase, here is a start. https://github.com/dashpay/dash/blob/master/src/primitives/block.h/** The maximum allowed size for a serialized block, in bytes (network rule) */ static const unsigned int MAX_BLOCK_SIZE = 1000000; change to static const unsigned int MAX_BLOCK_SIZE = 2000000; That could be a good start but it's definitely not enough. With this change only network is going to fork in two during update once someone spams it with few thousands of txes overflowing 1mb, so you need more code: either define a starting block at some time in the future and apply if/then logic in block validation (assuming that everyone _must_ upgrade before this block, which is an old way of doing thing and we really should stop using it btw) or implement it via signaling/"supermajority rule". As for proposal/block size limit/etc: - this was a "poll proposal", imo it's clear from its text - there was no date set in stone in its text besides "before Evolution"; - historically 1MB limit was set in bitcoin as a temporary protection while network is in its early age and tokens are too cheap i.e. it's economically vulnerable to spam - I believe our network is still better to be protected that way; - the point of the poll was "let's give Dash more room to grow on-chain when needed" - 1MB is clearly enough right now, so we are focused on other things which are critical for closest launch and following releases. If you still feel like it should be coded _right now_ for whatever reason and you want to code it yourself - submit PR on github (preferably, not a hardcoded block height solution), we'll happily review and apply it when time comes, if you don't want to code it - we'll implemented it ourselves when needed. If you think it should be applied right now just "because reasons", you'd better find some arguments imo. Solar, I don't mind you having an opinion, but I do take issue when you post assumptions as fact. If blocks do get full, InstantX transactions will start to be unlocked.
100% completely and utterly false. IX locks are mempool entries same as transactions. They don't get flushed until the transaction gets written into a block, regardless of how many blocks that takes. ... ... This is from the initial release post here: https://www.dash.org/forum/threads/v0-11-1-instantx-release.3923/Transaction locks are lost when restarting the client and only last for an hourSo if there are enough transactions that have fees higher than the InstantX fee, and blocks are kept full for an hour, the lock will be released and transaction unlocked. Well, Solarminer is kind of right about that one, to be fair. Currently locks are kept for 1h / 24 blocks. This is more like a buffer for chain reorgs, not a mempool atm. A flooding attack could be mitigated say by changing "ix mempool" behavior to expire locks not 24 blocks from the entry block but from locked tx confirmation block for example. ... .. . I'll have a look  EDIT: fixed typos |
|
|
|
Re Charlie Lee: Unfair instamined launch... rrrrright... That's really funny to hear from a guy who launched a coin with ~10000 blocks (~500.000 LTC) mined in the first 24h https://twitter.com/UdjinM6/status/824212258695905284Re SDC (to Solarminer): It's not some 2nd tier tech, it's basically a colored coin (OP_RETURN) + ring sig, all on the same 1st tier nodes/blockchain. And it's yet another (custom) utxo which grows forever and can't be pruned (all txo are forever "unspent" there). |
|
|
|
How to change a watching only lite client to.a working one ?
I'm sorry, I don't understand the question? My wallet contains some dash that i want to send , but sending does not work and i see thé mention "Watching only " How go get it operational ? Or functional ? Or efficient ? If the only balance you see is "watching only", you probably used "importaddress" rpc cmd when you should've use "importprivkey". You can't spend watch only balance from such wallet, you need to import private key to be able to spend these coins. |
|
|
|
...
I am trying to move funds between 2 addresses and due to malfunctioning dash wallet I can not see GUI so I am only using the console.
... Mind providing a bit more info about what kind of an issue you have there? ...
I type getbalance and get 1013.
I would like to send 13 coins to another address of mine so I type sendtoaddress "myaddress" 13
However, despite having high enough balance I get "Insuficient funds. (code -4)" error.
Can you tell me what is the problem here? The issue may be related to a fact that I am running a masternode.
Make sure you left some space for fees e.g. try sending 12.99 instead. |
|
|
|
When just a dozen masternodes decide its time to cut their losses, thats enough volume to crash dash price on poloniex to ~zero. So if that masternode chart shows anything right now, then Id describe it as a ticking nuclear bomb.
Let me help you. When just a dozen of <large currency holders> decide its time to cut their losses, thats enough volume to crash <currency> price on <exchanges> to ~zero. So if that <coin supply> chart shows anything right now, then Id describe it as a ticking nuclear bomb. https://blockchain.info/charts/total-bitcoins |
|
|
|
...
Here are few facts: - Neither masternode owners, nor community as a whole paid for the domain with _their own_ money, network generated _new coins_ to compensate expenses of few core team members who paid upfront. - In real world you need someone to be listed as domain owner. - Infrastructure (domain included) _is_ managed by several well-known community members, not by Evan only. Obviously, you can't give an access to infrastructure to each and every community member or masternode owner, some things just doesn't work that way. - None of us is happy it took so long to recover. The recent issue (and btw, it was two different issues which happened almost at the same time actually) revealed the fact that the process was not organized very well. Now when it's known, team is working to improve it and going to setup few fallback and automated recovery options. The actual solutions are still being discussed though to find the best combination because some of them could be costly. |
|
|
|
the site dash.org does not work... pending to icann verification .
reason ?
Nothing evil. Evan didn't see/click the contact validation email so the registrar automatically suspended the domain. We'll get it back online once we get in touch with Evan, but it may be in the morning. thank you for the response by the way my dash core v0.12.0.58 is on the reseau (three bars on the net out of 4) but does not sync any more. Is it normal ? Without any additional info I can only say that if problem persists after wallet restart make sure that timezone in your OS settings is the correct one for your location. |
|
|
|
I have a question concerning Dash and Hardware Wallets.
I read about using the Trezor for Dash with the Electrum-Dash wallet.
Do all the Dash remain stored in the local wallet and it is just using the safety features of Trezor?
Or is it possible to also use the trezor for cold storage?
thx for help
okay ....as far as I get it the trezor is only used for the confirmation of transfer right? So I can´t use trezor as a sort of real storage at the moment? I'm not quite sure what you mean but there is probably some confusion. There are no coins in your wallet, all "coins" are "stored" in the blockchain and you unlock them using "confirmation of transfer rights" i.e. private keys. You just either store private keys directly in software wallet (in some file) or on your hardware wallet (e.g. trezor). |
|
|
|
hello sir, how can I find a wallet DASH online, happy to get an answer from the people in this thread, thanks
http://dash.org/downloads/NOTE: there is no web wallet, dash-walllet[dot]com is a scam |
|
|
|
|
Show Posts
