Sometimes it's good to just start fresh, I've made four separate discoveries so far  . I'm sorry, but I've got to agree with the trolls here: Posts like this one contain no useful information and only create the impression that the dev is trying to pump their own coin. So if you're unwilling to share anything of substance, it might be better not to post on the development progress at all. Did I mention that I hate those teaser-based marketing strategies? I was waiting for someone to ask what I discovered... Basically, something called masternode input age based quorum layering. Quorums are created using the age of the masternodes, 25% of the quorums are more than 1.5 years old, the next 25% is more than 1 year old, the next 25% is more than 6 months old, then the final 25% is any masternode that is newer than that. It guarantees, you can't control a quorum by just buying coins from an exchange to make new masternodes, there will always be masternodes that are really, really old. okay i gotta ask : "masternode input age based quorum layering", is that one of four discoveries you made ? if the answer is yes i think you will know my next question  Yes. I also figured out how to implement user/masternode vote blinding, which will allow literally everyone to remain semi-anonymous on the network. Imagine you can vote privately on budgets. 3 and 4 are related to programming, the evolution platform is really nice to work with All good, one question regarding the use of MN age in selection of quorums. Will they also still be selected from the hash? I hope you can do both because I like the randomness of that. If you can select with both requirements, that's be impossible to game IMO  Exactly. Instead of using the hash to build the quorum at all once, you do it in four steps, by age. It's still deterministic. |
|
|
|
Sometimes it's good to just start fresh, I've made four separate discoveries so far . I'm sorry, but I've got to agree with the trolls here: Posts like this one contain no useful information and only create the impression that the dev is trying to pump their own coin. So if you're unwilling to share anything of substance, it might be better not to post on the development progress at all. Did I mention that I hate those teaser-based marketing strategies? I was waiting for someone to ask what I discovered... Basically, something called masternode input age based quorum layering. Quorums are created using the age of the masternodes, 25% of the quorums are more than 1.5 years old, the next 25% is more than 1 year old, the next 25% is more than 6 months old, then the final 25% is any masternode that is newer than that. It guarantees, you can't control a quorum by just buying coins from an exchange to make new masternodes, there will always be masternodes that are really, really old. okay i gotta ask : "masternode input age based quorum layering", is that one of four discoveries you made ? if the answer is yes i think you will know my next question Yes. I also figured out how to implement user/masternode vote blinding, which will allow literally everyone to remain semi-anonymous on the network. Imagine you can vote privately on budgets. 3 and 4 are related to programming, the evolution platform is really nice to work with |
|
|
|
Sometimes it's good to just start fresh, I've made four separate discoveries so far . I'm sorry, but I've got to agree with the trolls here: Posts like this one contain no useful information and only create the impression that the dev is trying to pump their own coin. So if you're unwilling to share anything of substance, it might be better not to post on the development progress at all. Did I mention that I hate those teaser-based marketing strategies? I was waiting for someone to ask what I discovered... Basically, something called masternode input age based quorum layering. Quorums are created using the age of the masternodes, 25% of the quorums are more than 1.5 years old, the next 25% is more than 1 year old, the next 25% is more than 6 months old, then the final 25% is any masternode that is newer than that. It guarantees, you can't control a quorum by just buying coins from an exchange to make new masternodes, there will always be masternodes that are really, really old. |
|
|
|
Sometimes it's good to just start fresh, I've made four separate discoveries so far . |
|
|
|
Hey Everyone, I'm working on Evolution's code currently and have designed a whole new way of documenting projects, which is really neat. To fully take advantage of this documentation, I'd like to sponsor the development of a sublime plugin. It should be really easy to create, I would like to render markup links that are in c++ comments. If you have experience with sublime plugins and want to make some DASH shoot me a PM. class CDashDriveEventEngine()
{
std::map<int64_t, CDashDriveAction> mapActionQueue;
CDashDriveAction* currentAction;
bool fAbortLoop;
bool AddActionToQueue(CDashDriveAction& newAction)
{
mapActionQueue.push_back(newAction);
std::sort(mapActionQueue.begin(), mapActionQueue.end());
//if we have a new event from before what we're working on
// we'll need to abort working on that event and start on this one
// this will [keep us consistent](/dash-docs/components) <-- this would get turned into a link and open the documentation in a new tab in Sublime.
if(newAction.GetTime() < currentAction.GetTime()){
}
}
//registered to it's own thread
void MainLoop()
{
}
}
|
|
|
|
It is impossible to say what the final number of coins will be. Dash has a flexible reward system. If mining wanes because it's unprofitable, the rewards go up according the the formula posted on the OP. The Budget system could lower that, but a lot of the estimate is based on the lowest rewards possible and a possible "high maximum" which is a complete guess.
Still, those are the boundaries between which the actual number of coins will be. So if we know the minimum reward is 5 and the maximum is 25, the final number will be somewhere between 18.6 and 73.3 million. I think there's a limit of 20 million (or something in that region) defined somewhere in the code, so the upper boundary is actually lower, but the 14 million from the OP don't really work out. I just updated the OP and the website, I'm not entirely sure where 14M came from but it's completely wrong. I did a projection and it comes out to about 18.9M here: https://docs.google.com/spreadsheets/d/1RpLd87PTs65sz8USrrXwGRoVGVbzaC-nunErEtGSJoE/edit#gid=0* 6.1M includes coins created through the end of this year ** 2017 is calculated to have 5.5DASH per block (which is what we've been averaging this year) *** 2018+ assumes the reward will be pegged to 5DASH per block (which is likely) According to this calculation, we should stop coin emission near 2300 |
|
|
|
So - I assume there will not be any more DASH updates until Jan 2016 or even longer.....  ? right? anybody? Sure, there will be 12.1 and probably 12.2 before we switch to Evolution |
|
|
|
Hello! I'm glad to see you're still around and looking at some of the more advanced issues within the space. I'm really liking how you laid out the issues and the trouble with this type of implementation. These are the exact issues that I've been thinking about solutions to over the last year and I finally found a strategy that has none of these issues mentioned. If you review the quotes of Evan I dug up and if you understand how he implemented InstantX, then you can deduce very obviously how he is intending to implement faster TPS, as I explained. To resummarize, the block chain hash combined mathematically (hashed?) with the inputs to a transaction is used to determine which quorum of masternodes can sign the transaction, then if M of N of them sign, this is broadcast to the block chain and the transaction is considered confirmed even before the block chain has produced the next block. Note Evan specifically stated inputs and not outputs and I assume the reason is so you can't game which masternodes can be the quorum, but then each input needs to reach a mathematically determined quorum separately (don't know if he has realized that yet), and thus the number of signatures on the block chain will increase by the average number of inputs per transaction (multiplied by N!).
Thus the negative implications of this increased TPS and instant confirmations (which will be realized in his design) are as I stated upthread:
Block chain becomes more bloated due to N times more signatures, not less.
However, signatures only need to be stored for a few thousand blocks. There's simply no chance of a reorg rearranging days of transactions unless something went terribly wrong with the network. In that case, the Bitcoin code is actually setup to halt, which is better than having two competing chains for that long. So in this case, bloat is not an issue. Also, instant transactions are now a natural result of the evolution design, not something build on top as they are currently. Instant transactions built in this way also are anonymous. We're talking about a different technology. Immunity to 51% attack is an incorrect claim, because the block chain hash determines which quorum, thus a chain reorganization can rewrite which quorum was authorized to M of N sign.
The proof of work hashes we use are buried deeper in the blockchain for Evolution, beyond the reach of chain reorganization. It's also multiple hashes that will decide the quorum structure, we're calling this technology the quorum-chain. The instant confirmations can not be trusted because if they are on an orphaned chain (not 51% attack but just the normal process of orphan rate or even 25 - 33% selfish mining attack), then they can be reversed.
In Evolution, miners don't decide which transactions are mined, the masternode network does via Quorum technology. |
|
|
|
This is not true. Darksend was closed source until RC5 in August/September 2014, when the source code was released. The rest of the Darkcoin source was open, but the Darksend portion was closed until Aug/Sept 2014. I helped write the official press release about Darksend being open-sourced, so I remember it well =)
and I think that worked out well, don't you? I mean, we did have a bunch of complainers/trolls again, saying you can't close source it, but it is after all a company, Dash is, and we should use tactics that protect our intellectual property until it's needed to be open sourced, which is required to be taken seriously in the crypto world for good reason. Still, while working on it, we don't need to let everyone see what we're doing. We can hide until the big reveal just like Apple does. . We're just going to build it privately, then open source it as soon as we launch . that's good news! But why not build it publicly, so other developers/volunteers can help? Also, now that you are online, can you please answer my newb questions: 1) How are the masternode locks enforced in the network? How do you force miners to not mine a double spent transaction?
2) Is it possible that there is a competing locked transaction? If that transaction has a higher fee (double spend attempt), I guess the miners rather confirm the transaction with the higher fee...
3) Masternodes don't get fees to lock transactions? What is the incentive to do the work? How are the masternode rewards distributed? How can the network "know" that masternodes are online and doing the work in stead of just being idle to have a lower bandwidth usage?
4) I wonder how you can have so much transactions per second? (the slide shows 500-1500) I read that bitcoin is limited to 7 transactions per second. I showed that it seems impossible to lock 350 transactions simultaneously with 3500 masternodes, unless you allow overlap. But that should be avoided, because it can happen that a masternode has the power to decide which of the 2 transactions he confirms during a double spend attack.
1.) There is code that scans all incoming blocks for transaction locks when accepting transactions and blocks. This means that a block that contains a conflicting transaction will be automatically rejected. 2.) The answer to this one is 3 fold. a. Currently if there are conflicting locks on the network, they will actually cancel each other. 2 conflicting locks doesn't really give miners a choice, it just removes instantX and goes back to proof of work. b. The quorums are selected by inputs though, so you'll get the same quorum for the same transaction even with a different fee. This means, they would have already decided and no conflicting lock would be issued. c. The new improved way is to use the quorum timestamp, then take the earliest one always. 3.) Masternodes are paid from the blockchain reward, which will be worth more as the services are utilized more. My position is that monetary services of the network should be provided at no or low cost, then we can add on other services over the coming years by financing them from the budget. The masternode network will own Virtual Corporations that are working to expand the reach of Dash. Then they will be paid from the dividends from those companies (a few years off). 4.) DAPI was just one of many components -- it isn't what allows for such scalability |
|
|
|
This is not true. Darksend was closed source until RC5 in August/September 2014, when the source code was released. The rest of the Darkcoin source was open, but the Darksend portion was closed until Aug/Sept 2014. I helped write the official press release about Darksend being open-sourced, so I remember it well =)
and I think that worked out well, don't you? I mean, we did have a bunch of complainers/trolls again, saying you can't close source it, but it is after all a company, Dash is, and we should use tactics that protect our intellectual property until it's needed to be open sourced, which is required to be taken seriously in the crypto world for good reason. Still, while working on it, we don't need to let everyone see what we're doing. We can hide until the big reveal just like Apple does. There are no plans to close source anything. We're just going to build it privately, then open source it as soon as we launch . |
|
|
|
I stopped following this topic after a while , posts seem to be a lot so I lost control and forget the pages  anyway does anyone here know if the Electrum wallet is out or not yet ? last time they said it's like 99% completed Not been following it, best I can find is soon(tm) : https://dashtalk.org/threads/october-2015-budget-proposal.6234/The budget proposal has been approved so its getting funded, should speed things up a bit It's been like three weeks since OP told me that it's being funded and should be released within one week or something if I remember right well .. thanks i guess , going to wait like everybody else Every part of the electrum wallet works perfect except calculating DarkGravityWave, the developers have been battling with that implementation. For some reason the result is ever so slightly off. We expected the bug to be found and killed relatively quickly, but it might have turned into a larger issue. I'll shoot an email over to them and see what the status is. |
|
|
|
Wasn't the 500 coin masternodes just an example of how the network could scale to even higher potential? Please, the Bitcoin block size debate has been bad enough and surely something like a change in the collateral needed for a masternode would be an issue for the voting mechanism.
Yeah, I was just talking hypothetically. We don't need to do it at all, our current network scales to 1M+ and the Evolution scales to 200M+ out of the box. When we hit 50M or so, we can start debating. We'll be doing an Evolution v1 release, then v2, then v3. These scaling changes will be included in those later updates. |
|
|
|
What happens if we cut it in half?
The collateral gets halved
The reward gets halved
Expenses remain the same
Wouldn't expenses double ? For a given holding, you've got to run twice the number of nodes for the same return. I mean per masternode. Collateral gets cut in half The reward gets cut in half Expenses remain the same etc |
|
|
|
.....
What about reducing the collateral to 500 DASH? Now we have 6600 masternodes....
I'm not sure that works. But perhaps I'm missing something. If you half the collateral, it doesn't follow that you double the masternodes. First, the block reward hasn't changed, so the revenue to run nodes remains the same overall. Second, going from one MN to two would potentially double the cost to run them - you have to ignore any speculation on price increases, although it would (speculating) potentially go up with real world adoption. So, one server goes to two servers, but the reward remains the same. If you introduce a micro fee, that would enable the network to scale with a reduction in collateral requirement. Currently the true ROI is about 14%: (blocks per day * avg reward * mn share / masternodes * days) = (reward at the end of the year) 576*6*.5/3270*365 = 192.88 DASH (19.2% of 1000 DASH) Let's say a server costs $10 a month, so true ROI is about 144 DASH per year (14.4% of 1000 DASH). --- What happens if we cut it in half? The collateral gets halved The reward gets halved Expenses remain the same Overall return goes down Node count should nearly double (slightly lower because of the reduced reward) (blocks per day * avg reward * mn share / masternodes * days) = (reward at the end of the year) 576*6*.5/6490*365 = 97 DASH (19.6% of 500 DASH) ( notice it's not double 3270, that would be 6540... it's lower) Let's say a server costs $10 a month, so true ROI is about 49.18 DASH per year (14.6% of 500 DASH) All things being equal, it's just supply and demand working themselves out in something like a bond market. The market demands a return on average currently of about 14% after expenses, the idea is it carries over no matter what collateral is required. Nodes that are allocated before should be allocated after, even if the user decides he doesn't want to do it, that would raise the ROI on the market, which would drive people to setup more nodes, getting us back to where we're at now. That help? It's a tad confusing |
|
|
|
Quick and possibly daft question on the method for selecting the 10 masternodes. The 10 nodes to handle a transaction are selected by the 10 nearest transaction IDs for the 1000 Dash transaction needed to set up the masternode (I think). Is that vulnerable to the malleability issues Bitcoin is seeing at the mo? ie. could transaction IDs be modified to direct to a small number of malicious masternodes? Unless I'm mistaken, it's based off the block hash, not the transaction IDs. All security is inherited from the mining network, which basically is deterministically setting up the quorum system, in a way that is provable. For example when you use DAPI, it will do something like create a transaction from Xaddr1 to Xaddr2 for 10 DASH. You then get back your command, a result status and all of the signatures from the quorum participants. You as the end user will know what quorum is activated for that node already, so you can tell if they're lying. In terms of scalability, if we have 3300 masternodes and a quorum size of 10, that means we can handle 330 requests at once. If the average time per request is about 100 ms, that means we can do 3300 requests per second. The estimate is based on the fact that the network is also doing maintenance at all times (propagating blocks, shard updates, syncing clients, etc), so I'm guessing ~50% of a fully utilized network will go to other activities. Therefore we end up with 1650 requests per second. Also we're going to aim for your average every day user, so we're talking just a few requests per month. So how many users can we support if they use 15 requests per month? 86400*1650*30/15 = 285,120,000. Ok, 285 million, that's pretty good. What about reducing the collateral to 500 DASH? Now we have 6600 masternodes and can handle 570 million users. Isn't the masternode count going up anyway? Yep. That number should hit about 700M about when we launch. This is why it says 500-1500 tx per second, I guess that should say "requests per second" because it's not really accurate. Also the 700M should be a range also, that's the high end, the low end is 285M for current Dash requirements. I've done a lot of guesswork to figure out these numbers, we'll see how close I am when we start seeing some serious adoption. Either way the system is built to scale with adoption in a way nothing else can, it should be pretty cool. I figure if we start to see a good deal of adoption and usage, we'll always either ask for more storage, processing power or reduce the collateral to split the network before it becomes an issue . They'll be good problems to have and we'll have lots of solutions available. |
|
|
|
|
Show Posts
