v12.1 is going to be neat  ETA on 12.1 hitting testnet?  |
|
|
|
Moocowmoo it's nice to see you starting to offer this kind of service as well. I am awaiting your automatic fully secured offline service. I can confirm moocowmoo is a top person and you can trust his abilities and honesty. If I wouldn't provide similiar service I would use it without hesitation...I will anyway just to try it and NO I will not withdraw after 30 days...I know what the feeling it is  Yes, Amanda - thedailydecrypt - has contacted me as well so looks like she is planning to do a show about masternodes shares services or at least to sign it as aan available option. I also can confirm that Moocowmoos is a top person and his service is great (haven`t tested t the share thing yet). Still need to test Splawik... I am sure you guys have already thought about it, so why is there no Smart Contract type of tradable instrument yet? Tradeble MN-Shares, redeemable in DASH at the issuer after 30 days, but tradable in the meantime? I can vouch for Moocowmoo as well. His main masternode service is cheap and he helped me through the issues I had getting all my nodes up and running. A good service run by a better guy. I am sure the shares service will be just as top notch. |
|
|
|
Bump. In particular make sure to vote on the reallocation of the public awareness proposal posted by babygiraffe. And if you have any qualms about using the funds for fiat gateways then listen to Amanda's interview of Danial Diaz (Minotuar). Just Amazing! Interview: https://youtu.be/OhI3YrVRiUEDashwhale Proposal: https://www.dashwhale.org/p/PA-reallocation |
|
|
|
Also, what brought all this on?
Just me personally, but I always feel better about big moves not clearly related to any event. A lot of times a big price rise related to some milestone is just a "buy the rumor -- sell the news" cycle whereas this rise feels like people are starting to finally properly value the currency. |
|
|
|
No discernable reason for the rise so do be careful.
Added to BTC38 is a discernible reason. AFAIK, that is our first major Chinese exhange. We are on Bter since a long time and are with BTC38 not just since today I stand corrected... |
|
|
|
No discernable reason for the rise so do be careful.
Added to BTC38 is a discernible reason. AFAIK, that is our first major Chinese exhange. |
|
|
|
Also, we don't have enough time to review proposals. Generally, people are just giving us a couple of weeks, that's not enough to discuss and argue. I think, for this to work best, we should do this in 2 steps. First, gather the proposals, then spend 1 month discussing them before they're open for voting. Then vote. There's no need to rush any vote if the budget proposal is planned correctly. The only time constraints on a proposal's voting window are defined by the submitter. It's perfectly valid to submit a proposal that starts getting paid at a later cycle(s). In fact, I'd encourage future submitters to do just that, *especially* if it is a one-time payment. Here are next years cycle start blocks and approximate dates. Set your payment-start block's accordingly. block date
382168 - Sat Jan 16 01:20:00 UTC 2016
398784 - Sat Feb 13 21:40:00 UTC 2016
415400 - Sun Mar 13 18:00:00 UTC 2016
432016 - Mon Apr 11 14:20:00 UTC 2016
448632 - Tue May 10 10:40:00 UTC 2016
465248 - Wed Jun 8 07:00:00 UTC 2016
481864 - Thu Jul 7 03:20:00 UTC 2016
498480 - Thu Aug 4 23:40:00 UTC 2016
515096 - Fri Sep 2 20:00:00 UTC 2016
531712 - Sat Oct 1 16:20:00 UTC 2016
548328 - Sun Oct 30 12:40:00 UTC 2016
564944 - Mon Nov 28 09:00:00 UTC 2016
581560 - Tue Dec 27 05:20:00 UTC 2016
here's the script and math # 16616 / 576 = 28.8472 * 24 = 692.33
D0=$(TZ=UTC date --date="$(date --date="2015-12-07T08:27:12+0000")");
for block in `seq 382168 16616 $((382168 + (16616*24)))`;
do DD=$(TZ=UTC date --date="$(date --date="$D0") +692 hours +20 minutes");
D0=$DD;
echo "$block - $DD";
done
Also, I'd like to remind everybody of some important differences from typical elections that Dash's voting system has: (taken from masternode-budget.cpp) - Votes are counted every 16616 blocks - Votes can be recast at any time - Budget proposals remain on the network until: either 340 more nay votes than yay votes are cast (10% of total masternodes) or the proposal end block is reached - Approved budgets are paid in order of yay - nay votes - Approved budgets can be nullified at any time by recasting votes
Also, A bit of rumor control about "Evan controlling the budget system": Evan doesn't have enough masternodes online to pass anything. Neither do I. Even working together we couldn't vote the required 10%. From what I've gathered analyzing vote timestamps only otoh has enough masternodes provisioned to cast enough votes to pass a budget item. But even with approximately 600 masternodes (maybe less today), it would only take 261 no votes to prevent the budget item from passing. Additionally, the budget allocation is disbursed in order of yay - nay votes. So, even if somebody did sneak a budget item in at the last second, it would only be processed after all other approved budgets had been funded. -- I hope this post helps to dispel any concern about dash being controlled by whales. The way the system is set up, what is good for the currency will trump any few individuals' will to power. Thanks for this post! There has been a lot of fearmongering related to the voting system recently with people conveniently forgetting that voting is not just YES votes but YES - NO votes. If Otoh and/or Evan for whatever reason tried to get something sketchy passed, it would take a trivial campaign on this forum and dashtalk to get the couple hundred NO votes to shut them down. |
|
|
|
|
That fact that BFX persists in calling us Darkcoin 6 months after the rebranding prompts a "good riddance" from me.
|
|
|
|
Minimum requirement to get into a budget if there is literally nothing else in there to stop you is 5% of the network in votes, so currently that's 145 votes. But say, you get 100 "no" votes, that means you will need 245 yes votes to have 5%.
Oh wow, Evan, that's pretty dangerous IMO. otoh could overwhelmingly vote anything to himself (not that he would, but he could) with 20% of the masternodes, and if the other masternode owners aren't on top of things, this could slip by! Is there a minimum amount of time that must elapse before the first payment can happen (like a month?) so there is time to get people to down vote if it's a bad idea? At the end of each cycle, there is a finalization that happens. We'll look at the budget and make sure we like what is happening, if there's something like that happening we can downvote the items in question out of the system. This is really only a concern while we spin up the system anyway. Later on, say the average budget proposal has 30% yes votes, that means you'll need that amount to make it in. I'll add a minimum lifespan of a proposal before adding it into the budget though, that's a great idea. So the day of finalization we'll have the whole day to review things before they can make it into the final budget. So the "no"s are downvotes. Good to know. That way if a person with 5% of the Masternodes votes yes to fund a bogus project then 5% of "no" votes from other Masternodes could cancel this out by sending that owner's proposal back to zero. Edit: Evan, thinking about this a little more... the "finalization" period you speak of should only allow downvoting. Otherwise, a clever Masternode owner that has say 6% of the network might submit an harmless looking proposal that flies under the radar generating little support (for or against). Then, if yes voting is allowed during the "finalization" phase, that owner could execute a script to have the 6% of the network he controls vote "yes" say 1 minute before the deadline -- thus awarding himself coins for nothing. To prevent this we could have a 25 day period where proposals are submitted and voted on (for or against) and then have a 5 day review period where only against votes are allowed. After the review period qualifying proposals are paid. I think this will lower the chance of scammy proposals getting through. Thoughts? |
|
|
|
Does he need only 51%?
Define 51% 51% of the MN system would cost you MILLIONS - if that's what you mean :-P No haha Im thinking about % if they are important, some projects should require more than 51% (yes) For Voting on a Proposal? I've not seen the 'Voting' requirements yet Anybody??? Evan?? Minimum requirement to get into a budget if there is literally nothing else in there to stop you is 5% of the network in votes, so currently that's 145 votes. But say, you get 100 "no" votes, that means you will need 245 yes votes to have 5%. So if I understand this system... a proposal is scored by summing the votes from all Masternodes where a "yes" vote is +1, an "abstain" is 0, and a "no" is -1. Proposals will be paid starting at the highest score proceeding to the lowest score until the allotted funds are exhausted. Finally, to qualify for any payment at all a proposal must at least score greater than 0.05*Total Masternodes. If not enough qualifying proposals exist then the coins are not generated. For example, if 10% of the coin supply is dedicated to funding and on average qualifying proposals only need 7% of that supply then 3% of the coins will never be created. Is that correct? |
|
|
|
idiot you do realise there is a now a coin called Darkcoin, and has nothing to do with DASH ? even if we rebrand, we will still have technology ahead of your copy-clone whatevercoin Don't even bother Rux. That fact that they feel like they need to attack us and that drivel is the best they can come up with says all that needs to be said. |
|
|
|
A central escrow/wallet for projects will cause problems with theft/loss/confiscation/tax.
Multisig in general is VERY secure and is proven in Bitcoin. Thus the temp implementation of having 7~10/15 multisig will not suffer from this problem. As for future implementations... well we have testnet. I think you are making a mountain out of a molehill on this theft/loss issue. Multisig means jack shit when the psychopaths who run the asylum decide to ruin or end you. If they want your multisig key you are going to give it to them. They're slightly less likely to ask for it torture it out of you if it doesn't exist in the first place. Or do you think bad things only happen to those nasty brown people, on TV, in the land of Far Away?  No. I simply don't have an unhealthy paranoia about gov't. The gov't doesn't care about Dash. And they certainly aren't going to torture the 15 people with the multisig keys for the brief period of time that this temporary solution is in place. That is nothing but a red herring and I hope voters will not be fooled by it. |
|
|
|
My 2 Main concerns. A mandatory 10% tax will eventually turn into pork barrel projects along with an incentive for those getting the funding to increase that tax.
Your post is pretty misleading. One -- calling it a "tax" is VERY debatable and two -- it will not be 10% until 4/2016. We are starting out at a measly 1.25%. If you are right and this does turn out to be wasteful then there is plenty of time to change things before it is a big problem. As Evan says, there is nothing set in stone. If something doesn't work as intended then it will be fixed. That has been the mantra of this project since day 1 and the main reason why I still support the devs. They are always improving. A central escrow/wallet for projects will cause problems with theft/loss/confiscation/tax.
Multisig in general is VERY secure and is proven in Bitcoin. Thus the temp implementation of having 7~10/15 multisig will not suffer from this problem. As for future implementations... well we have testnet. I think you are making a mountain out of a molehill on this theft/loss issue. |
|
|
|
Given the debate here, it's probably best to take the significantly premined mark off of Dash until we can figure out a more appropriate solution. I agree that instamine is not the same as premine.
I see a few options here:
1) Change label to "Significantly mined around launch" or something among those lines
2) Make an instamine label
3) Not care about tracking instamine
I'm preferring #3 because "instamine" is not a well defined term and can be applied subjectively.
I see this as a wise choice. It is easy to see why you would not want to dig through this forum trying to vet the launch of every coin listed on your site based on a subjective criteria. |
|
|
|
There you have it coinmarketcap.com has corrected their listing... Premined has been removed from by our name.
Good for them. Hopefully they will be more resistant to trolling in the future. |
|
|
|
I don't get this. A instamine is not a premine. The devs did not preemptively take a large number of coins out of circulation. I wonder if money changed hands here to get us listed as such. Shame on coinmarketcap, shame on the Monero shills/devs. |
|
|
|
Excellent! Keep up the good work as always. I like how a lot of the talking points that have been going around the the community recently are addressed in your post.  Also, I really can't wait for the decentralized management whitepaper to be released this Wednesday. The key is whether or not we will be able to keep the efficiency in the development process that we have enjoyed in the past while trying to decentralize aspects of management. I look forward to reading it. |
|
|
|
Is it true that this coin has some kind of software "switch" that someone switches off and on when he decides to..  Yes. And it gets even better, you can DDoS the reference node to simply intercept the switching process. But in general I'm not worried about Dash, I read they have flowcharts and certified managers now... The only thing that worries me is that most followers of this thread have no idea what technically is going on. And that's probably the main reason why this coin still sells so good. DDOSing the reference node doesn't hurt the network. Th only thing that happens is the MN payments go from regular to random. Nice try though. |
|
|
|
Bitcoin is a consensus protocol specification, a team of developers maintaining a reference implementation,
Is has that now but it didn't when Satoshi was creating it. It was essentially a one-man-show (albeit with increasing levels of participation from others as it evolved.) Exactly. It is a strawman argument to compare Bitcoin in year 6 to DASH in year 2 when it comes to the development situation. If you want to complain, there are other things one can legitimately dislike about this project -- but criticizing this coin because it still primarly based around the goals of one person when it is only 18 months old reeks of sour grapes or a contrary agenda. |
|
|
|
|
Show Posts
