How much could I make running 10 MASTERNODES for one year?
15% after overhead, a masternode earns approximately 15% or 150 dash per year.
Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 1698. (Read 9723973 times)
October 21, 2015, 02:53:03 PM
after overhead, a masternode earns approximately 15% or 150 dash per year.
October 21, 2015, 02:47:37 PM
When will we see a $25-50 price in DASH?
1. 12 months or less
2. between 2 -5 years
3. 5 + years
1. 12 months or less
2. between 2 -5 years
3. 5 + years
I don't want to be rude but this is ridiculous question.
The question for you. Do you know anybody who know the future?
satoshi would have thought that one day every Bitcoin 1 thousand dollars?
Nobody knows about the future
October 21, 2015, 02:46:36 PM
Masternodes are what interests me the most about DASH...
How much could I make running 10 MASTERNODES for one year?
How much in DASH or btc ?
How much could I make running 10 MASTERNODES for one year?
How much in DASH or btc ?
15%
Please someone explain this
October 21, 2015, 02:42:22 PM
Quote from: your name
sourceLocked-why
Because Shelby thinks differently than most people, and decided to lock his unmoderated thread while simultaneously keeping it bumped by himself.
In order to compensate for the eccentricity, I had to form the quotes manually.
Personally I'm a little offended you didn't have the brain cells to piece this together, but this is btctalk, logic is involved, lots of things are going on, and all so I get it. Don't worry I'll let you cuban cigar and everything though.
No grand conspiracies here, other than the obviously enthralling name, doublewrite, shining the lights on cockroaches, occasional venting, the realization that fat people aren't always addicted to eating, but rather the endorphin-fueled hour long high after defecation that I've decided to successfully link to the idea that most people here aren't addicted to altcoins, but instead losing money.
I get it, that's all. I don't hate you, I hate your condition, so never change
Oh, no no no, I'm definitely addicted to eating, especially sugar and chocolate. I have no reason to wonder why I'm fat. It's quite obvious, LOL.
hero member
Activity: 617
Merit: 509
Crypto Card - https://platinum.crypto.com/r/28cz7d
October 21, 2015, 02:41:36 PM
Masternodes are what interests me the most about DASH...
How much could I make running 10 MASTERNODES for one year?
How much in DASH or btc ?
How much could I make running 10 MASTERNODES for one year?
How much in DASH or btc ?
15%
October 21, 2015, 02:38:15 PM
Masternodes are what interests me the most about DASH...
How much could I make running 10 MASTERNODES for one year?
How much in DASH or btc ?
How much could I make running 10 MASTERNODES for one year?
How much in DASH or btc ?
October 21, 2015, 02:31:13 PM
You would have to own a majority of masternodes in order to attack instant transaction locks. The cost of acquiring this many nodes (currently about 1.7 million DASH) would be prohibitive, as there is obviously not that much available for sale and even if there was, the price would skyrocket if anyone tried to obtain this much.
October 21, 2015, 02:25:32 PM
Quote from: your name
sourceLocked-why
Because Shelby thinks differently than most people, and decided to lock his unmoderated thread while simultaneously keeping it bumped by himself.
In order to compensate for the eccentricity, I had to form the quotes manually.
Personally I'm a little offended you didn't have the brain cells to piece this together, but this is btctalk, logic is involved, lots of things are going on, and all so I get it. Don't worry I'll let you cuban cigar and everything though.
No grand conspiracies here, other than the obviously enthralling name, doublewrite, shining the lights on cockroaches, occasional venting, the realization that fat people aren't always addicted to eating, but rather the endorphin-fueled hour long high after defecation that I've decided to successfully link to the idea that most people here aren't addicted to altcoins, but instead losing money.
I get it, that's all. I don't hate you, I hate your condition, so never change
October 21, 2015, 02:16:47 PM
So it wasn't even Anonymint, eh? Well, brought back good memories anyway 
Yah Tok, I'm just an old lady having way too much fun here, and I do have Mama Bear protective instincts, which are quite funny. I have gone "crazy" at perceived slights on my children, when I've always been such a quiet non-confrontational person before. OMG, one guy yelled at my daughter for pouring out her ice as we were parked in front of his house. He was nasty, and it made her cringe. I got out of the car and was ready to kill him for making her feel bad (she's very sensitive) and I undoubtedly made things worse, but I go a bit crazy for my kids. Can't help it! LOL
Actually, I've seen a lot of women do this, and I'm convinced it's instinct, LOL
Yah Tok, I'm just an old lady having way too much fun here, and I do have Mama Bear protective instincts, which are quite funny. I have gone "crazy" at perceived slights on my children, when I've always been such a quiet non-confrontational person before. OMG, one guy yelled at my daughter for pouring out her ice as we were parked in front of his house. He was nasty, and it made her cringe. I got out of the car and was ready to kill him for making her feel bad (she's very sensitive) and I undoubtedly made things worse, but I go a bit crazy for my kids. Can't help it! LOL
Actually, I've seen a lot of women do this, and I'm convinced it's instinct, LOL
October 21, 2015, 02:15:26 PM
I did not see anything offensive on Anonymint's post, if anything he is giving his perspectives from his point of view and was not negative. Dont get carried away by the way that poster shared it here. Anonymint clearly says he is commenting from limited knowledge and would wait to see if he is right about the potential weaknesses he thought about.
So please relax, I felt there were some good warnings and thoughts to take into consideration. I think he will see how challenging it is to go beyond design and whitepapers and into a practical implementation as he works on his own project. I think that is where Evan has shown exceptional talent in making things a reality and implementing them in a practical way that actually works.
So please relax, I felt there were some good warnings and thoughts to take into consideration. I think he will see how challenging it is to go beyond design and whitepapers and into a practical implementation as he works on his own project. I think that is where Evan has shown exceptional talent in making things a reality and implementing them in a practical way that actually works.
Great post. I agreed with this sentiment when I read anonymint's post. (though some of the terminology in Tante's was highly entertaining all the same
) October 21, 2015, 02:14:30 PM
October 21, 2015, 02:10:19 PM
I did not see anything offensive on Anonymint's post, if anything he is giving his perspectives from his point of view and was not negative. Dont get carried away by the way poster shared it here. Anonymint clearly says he is commenting from limited knowledge and would wait to see if he is right about the potential weaknesses he thought about.
So please relax, I felt there were some good warnings and thoughts to take into consideration. I think he will see how challenging it is to go beyond design and whitepapers and into a practical implementation. I think that is where Evan has shown exceptional talent in making things a reality and implementing them in a practical way that actually works.
So please relax, I felt there were some good warnings and thoughts to take into consideration. I think he will see how challenging it is to go beyond design and whitepapers and into a practical implementation. I think that is where Evan has shown exceptional talent in making things a reality and implementing them in a practical way that actually works.
Minotaur26, I'm not perfect, but he was a snob, at least he typed as a big snob, and that was my impression. But like I admitted, he is highly intelligent, and probably on-spectrum, hence the snobbish impression. And he was being, IMO, disrespectful to Evan, who had already made a soft spot in my heart. So I felt very protective of my boy, LOL.
YOU got the name though, Anonymint! Not Ajax, LOL. If Anonymint is actually very nice, I'm glad. It's hard to express yourself on forums, as I well know, and have come across totally wrong many times. I just still have Mommy Bear protection mode on around Evan, LOL.
October 21, 2015, 02:06:41 PM
I did not see anything offensive on Anonymint's post, if anything he is giving his perspectives from his point of view and was not negative. Dont get carried away by the way that poster shared it here. Anonymint clearly says he is commenting from limited knowledge and would wait to see if he is right about the potential weaknesses he thought about.
So please relax, I felt there were some good warnings and thoughts to take into consideration. I think he will see how challenging it is to go beyond design and whitepapers and into a practical implementation as he works on his own project. I think that is where Evan has shown exceptional talent in making things a reality and implementing them in a practical way that actually works.
So please relax, I felt there were some good warnings and thoughts to take into consideration. I think he will see how challenging it is to go beyond design and whitepapers and into a practical implementation as he works on his own project. I think that is where Evan has shown exceptional talent in making things a reality and implementing them in a practical way that actually works.
October 21, 2015, 02:05:31 PM
You mean the shojaxit guy from like a year ago?
No no, this guy was smart
He and Evan were ping ponging on the forum, he kept talking about attack vectors and other ideas, of course his angle was that they couldn't be solved, he didn't like DRK, but Evan absorbed it all, and came up with solutions. The best example of... well he was borderline trolling and Evan learning and coming up with solutions and ideas. He did make DarkCoin happen, only he did it by being a borderline jerk. He's highly intellegent, but lacking in imagination and has a sour outlook, which also holds him back. And that he helped Evan made his irritation palpable. If he does have his ideas used by Evan, good on Evan, et al! Evan is smart enough to at least try to keep his ideas close to the vest until it has to come out, so that he doesn't get on-upped.
This guy was a braggart, and if he hasn't gotten anywhere to this day (he had at least one of his own coins), it is probably because he'd rather talk than code
October 21, 2015, 01:53:47 PM
Whats up suicides? Apparently you're on shitcoiner watch!
I redacted a name or two so you don't get triggered like good little toys and make fools of yourselves again.
Apparently he is the one who actually made your masternodes too?
Quote from: TPTB_need_war on October 21, 2015, 04:24:14 PM
Both |||||||||||||| and r0ach have mentioned Dash working on a new block chain scaling design. The only information I found on this as follows:
https://dashtalk.org/threads/rebranding-and-scalability.4254/
I have a reasonable sure idea what Evan is thinking. I expect the weaknesses of his design I expect he is conflating distributed and decentralized and uses the later term where he should use the former. Yes the masternodes are distributed but if you give them any discretionary power then you have the problem of power corrupts absolutely. Remember masternodes can be purchased.
Edit: I found the following information:
https://dashtalk.org/threads/development-update-oct-19-2015.6429/
https://dashtalk.org/threads/dash-team-at-bitcoin-wednesday-amsterdam-presentation.6287/page-6 (see last post on page)
Appears to be something like this Open Transactions white paper:
http://stashcrypto.com/how-it-works/
So Evan is planning to allow a quorum of masternodes to confirm a transaction through thresholded multisig. He will move transaction confirmation off chain, similar to the InstantX which moved certain transactions presigned to certain outputs off chain to the masternode. The transaction's hash will determine I assume which quorum the transaction is routed to.
So yes he is doing exactly what I expected him to do. The weakness is that a little bit of corruption in the masternodes and you have either chaos of a block chain that is double-spent or loss of fungible permission-less commerce. The difficulties are in coordination overhead (DoS, etc), fungibility, and verifiable global coherence. The security model of crypto currency either has to be proven to still be in force, or he has to explain how he has modified the security model and why his alternative is secure. The Bitcoin security model is that any full node can download the entire block chain history and verify everything.
Evan claims immunity to 51% attacks. I also claimed this is in my design in recent months. He didn't mention that in the March post, so assume he (or Dash people) read my posts. (remember the masternode concept originally started back when Darkcoin was created when I was in discussion in the forum with Evan about the weaknesses of his first design for Darkcoin).
I know how he intends to achieve 51% attack immunity. But I think he will lose verifiable global coherence. I claimed that feature knowing that I could not commit these shortcut errors in design that I assume he is making. Any way, I haven't seen his design, so let's see if I end up being correct. Perhaps they will read this post and try to correct the mistakes they were going to make.
Edit#2: found this and seems to confirm to me that he is doing it the way I expected him to do it. Not enough details are revealed for me to determine how he is handling the issues I stated above.
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.
Edit#3: It doesn't appear this is aimed at block chain scaling rather only at faster confirmation times for transactions. Because it appears that all the confirmation records have to come back to the block chain. So you still need huge blocks and lots of CPU power to verify all the confirmation records. He is authorizing a quorum to preconfirm the transaction before the block confirmation.
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.
Edit#4: I realized his claim of immunity against 51% attacks is not true. Because if the minority refuses to honor the collusion between some masternodes and 51% of the mining hashrate, then those masternodes can stop responding to the minority block chain, thus forcing the minority chain either to violate its own protocol or be orphaned. As usual, he hasn't thought this out very well.
https://dashtalk.org/threads/rebranding-and-scalability.4254/
I have a reasonable sure idea what Evan is thinking. I expect the weaknesses of his design I expect he is conflating distributed and decentralized and uses the later term where he should use the former. Yes the masternodes are distributed but if you give them any discretionary power then you have the problem of power corrupts absolutely. Remember masternodes can be purchased.
Edit: I found the following information:
https://dashtalk.org/threads/development-update-oct-19-2015.6429/
https://dashtalk.org/threads/dash-team-at-bitcoin-wednesday-amsterdam-presentation.6287/page-6 (see last post on page)
Appears to be something like this Open Transactions white paper:
http://stashcrypto.com/how-it-works/
So Evan is planning to allow a quorum of masternodes to confirm a transaction through thresholded multisig. He will move transaction confirmation off chain, similar to the InstantX which moved certain transactions presigned to certain outputs off chain to the masternode. The transaction's hash will determine I assume which quorum the transaction is routed to.
So yes he is doing exactly what I expected him to do. The weakness is that a little bit of corruption in the masternodes and you have either chaos of a block chain that is double-spent or loss of fungible permission-less commerce. The difficulties are in coordination overhead (DoS, etc), fungibility, and verifiable global coherence. The security model of crypto currency either has to be proven to still be in force, or he has to explain how he has modified the security model and why his alternative is secure. The Bitcoin security model is that any full node can download the entire block chain history and verify everything.
Evan claims immunity to 51% attacks. I also claimed this is in my design in recent months. He didn't mention that in the March post, so assume he (or Dash people) read my posts. (remember the masternode concept originally started back when Darkcoin was created when I was in discussion in the forum with Evan about the weaknesses of his first design for Darkcoin).
I know how he intends to achieve 51% attack immunity. But I think he will lose verifiable global coherence. I claimed that feature knowing that I could not commit these shortcut errors in design that I assume he is making. Any way, I haven't seen his design, so let's see if I end up being correct. Perhaps they will read this post and try to correct the mistakes they were going to make.
Edit#2: found this and seems to confirm to me that he is doing it the way I expected him to do it. Not enough details are revealed for me to determine how he is handling the issues I stated above.
Quote from: eduffield on October 08, 2015, 10:19:52 PM
Quote from: ddink7 on October 08, 2015, 09:10:06 PM
Quote from: stan.distortion on October 08, 2015, 09:05:38 PM
Quote from: Minotaur26 on October 08, 2015, 07:35:25 PM
...
In this video Evan explains decentralized oracles, is a must watch to understand subquorums.
https://www.youtube.com/watch?v=uGh43BQrxK0
In this video Evan explains decentralized oracles, is a must watch to understand subquorums.
https://www.youtube.com/watch?v=uGh43BQrxK0
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.
Edit#3: It doesn't appear this is aimed at block chain scaling rather only at faster confirmation times for transactions. Because it appears that all the confirmation records have to come back to the block chain. So you still need huge blocks and lots of CPU power to verify all the confirmation records. He is authorizing a quorum to preconfirm the transaction before the block confirmation.
Quote from: eduffield on October 12, 2015, 07:04:15 PM
Quote from: cryptonewb on October 12, 2015, 06:48:40 PM
Quote from: cryptonewb on October 12, 2015, 02:04:19 PM
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.
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.
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.
Edit#4: I realized his claim of immunity against 51% attacks is not true. Because if the minority refuses to honor the collusion between some masternodes and 51% of the mining hashrate, then those masternodes can stop responding to the minority block chain, thus forcing the minority chain either to violate its own protocol or be orphaned. As usual, he hasn't thought this out very well.
I redacted a name or two so you don't get triggered like good little toys and make fools of yourselves again.
Apparently he is the one who actually made your masternodes too?
LOL, Is the retracted name ... Oh shit, starts with an A, no? Smart guy but with a lot of ego. H argued with Evan and gave Evan a lot of good ideas, and when Evan solved all his arguments, he disappeared... Oh, what's his NAME! Um.... I'll come up with it, I'm sure Something like Ajax....
October 21, 2015, 01:43:19 PM
Whats up suicides? Apparently you're on shitcoiner watch!
I redacted a name or two so you don't get triggered like good little toys and make fools of yourselves again.
Apparently he is the one who actually made your masternodes too?
Quote from: TPTB_need_war on October 21, 2015, 04:24:14 PM
Both |||||||||||||| and r0ach have mentioned Dash working on a new block chain scaling design. The only information I found on this as follows:
https://dashtalk.org/threads/rebranding-and-scalability.4254/
I have a reasonable sure idea what Evan is thinking. I expect the weaknesses of his design I expect he is conflating distributed and decentralized and uses the later term where he should use the former. Yes the masternodes are distributed but if you give them any discretionary power then you have the problem of power corrupts absolutely. Remember masternodes can be purchased.
Edit: I found the following information:
https://dashtalk.org/threads/development-update-oct-19-2015.6429/
https://dashtalk.org/threads/dash-team-at-bitcoin-wednesday-amsterdam-presentation.6287/page-6 (see last post on page)
Appears to be something like this Open Transactions white paper:
http://stashcrypto.com/how-it-works/
So Evan is planning to allow a quorum of masternodes to confirm a transaction through thresholded multisig. He will move transaction confirmation off chain, similar to the InstantX which moved certain transactions presigned to certain outputs off chain to the masternode. The transaction's hash will determine I assume which quorum the transaction is routed to.
So yes he is doing exactly what I expected him to do. The weakness is that a little bit of corruption in the masternodes and you have either chaos of a block chain that is double-spent or loss of fungible permission-less commerce. The difficulties are in coordination overhead (DoS, etc), fungibility, and verifiable global coherence. The security model of crypto currency either has to be proven to still be in force, or he has to explain how he has modified the security model and why his alternative is secure. The Bitcoin security model is that any full node can download the entire block chain history and verify everything.
Evan claims immunity to 51% attacks. I also claimed this is in my design in recent months. He didn't mention that in the March post, so assume he (or Dash people) read my posts. (remember the masternode concept originally started back when Darkcoin was created when I was in discussion in the forum with Evan about the weaknesses of his first design for Darkcoin).
I know how he intends to achieve 51% attack immunity. But I think he will lose verifiable global coherence. I claimed that feature knowing that I could not commit these shortcut errors in design that I assume he is making. Any way, I haven't seen his design, so let's see if I end up being correct. Perhaps they will read this post and try to correct the mistakes they were going to make.
Edit#2: found this and seems to confirm to me that he is doing it the way I expected him to do it. Not enough details are revealed for me to determine how he is handling the issues I stated above.
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.
Edit#3: It doesn't appear this is aimed at block chain scaling rather only at faster confirmation times for transactions. Because it appears that all the confirmation records have to come back to the block chain. So you still need huge blocks and lots of CPU power to verify all the confirmation records. He is authorizing a quorum to preconfirm the transaction before the block confirmation.
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.
Edit#4: I realized his claim of immunity against 51% attacks is not true. Because if the minority refuses to honor the collusion between some masternodes and 51% of the mining hashrate, then those masternodes can stop responding to the minority block chain, thus forcing the minority chain either to violate its own protocol or be orphaned. As usual, he hasn't thought this out very well.
https://dashtalk.org/threads/rebranding-and-scalability.4254/
I have a reasonable sure idea what Evan is thinking. I expect the weaknesses of his design I expect he is conflating distributed and decentralized and uses the later term where he should use the former. Yes the masternodes are distributed but if you give them any discretionary power then you have the problem of power corrupts absolutely. Remember masternodes can be purchased.
Edit: I found the following information:
https://dashtalk.org/threads/development-update-oct-19-2015.6429/
https://dashtalk.org/threads/dash-team-at-bitcoin-wednesday-amsterdam-presentation.6287/page-6 (see last post on page)
Appears to be something like this Open Transactions white paper:
http://stashcrypto.com/how-it-works/
So Evan is planning to allow a quorum of masternodes to confirm a transaction through thresholded multisig. He will move transaction confirmation off chain, similar to the InstantX which moved certain transactions presigned to certain outputs off chain to the masternode. The transaction's hash will determine I assume which quorum the transaction is routed to.
So yes he is doing exactly what I expected him to do. The weakness is that a little bit of corruption in the masternodes and you have either chaos of a block chain that is double-spent or loss of fungible permission-less commerce. The difficulties are in coordination overhead (DoS, etc), fungibility, and verifiable global coherence. The security model of crypto currency either has to be proven to still be in force, or he has to explain how he has modified the security model and why his alternative is secure. The Bitcoin security model is that any full node can download the entire block chain history and verify everything.
Evan claims immunity to 51% attacks. I also claimed this is in my design in recent months. He didn't mention that in the March post, so assume he (or Dash people) read my posts. (remember the masternode concept originally started back when Darkcoin was created when I was in discussion in the forum with Evan about the weaknesses of his first design for Darkcoin).
I know how he intends to achieve 51% attack immunity. But I think he will lose verifiable global coherence. I claimed that feature knowing that I could not commit these shortcut errors in design that I assume he is making. Any way, I haven't seen his design, so let's see if I end up being correct. Perhaps they will read this post and try to correct the mistakes they were going to make.
Edit#2: found this and seems to confirm to me that he is doing it the way I expected him to do it. Not enough details are revealed for me to determine how he is handling the issues I stated above.
Quote from: eduffield on October 08, 2015, 10:19:52 PM
Quote from: ddink7 on October 08, 2015, 09:10:06 PM
Quote from: stan.distortion on October 08, 2015, 09:05:38 PM
Quote from: Minotaur26 on October 08, 2015, 07:35:25 PM
...
In this video Evan explains decentralized oracles, is a must watch to understand subquorums.
https://www.youtube.com/watch?v=uGh43BQrxK0
In this video Evan explains decentralized oracles, is a must watch to understand subquorums.
https://www.youtube.com/watch?v=uGh43BQrxK0
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.
Edit#3: It doesn't appear this is aimed at block chain scaling rather only at faster confirmation times for transactions. Because it appears that all the confirmation records have to come back to the block chain. So you still need huge blocks and lots of CPU power to verify all the confirmation records. He is authorizing a quorum to preconfirm the transaction before the block confirmation.
Quote from: eduffield on October 12, 2015, 07:04:15 PM
Quote from: cryptonewb on October 12, 2015, 06:48:40 PM
Quote from: cryptonewb on October 12, 2015, 02:04:19 PM
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.
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.
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.
Edit#4: I realized his claim of immunity against 51% attacks is not true. Because if the minority refuses to honor the collusion between some masternodes and 51% of the mining hashrate, then those masternodes can stop responding to the minority block chain, thus forcing the minority chain either to violate its own protocol or be orphaned. As usual, he hasn't thought this out very well.
I redacted a name or two so you don't get triggered like good little toys and make fools of yourselves again.
Apparently he is the one who actually made your masternodes too?
October 21, 2015, 01:17:46 PM
Sounds like you are a dog with 2 bones 
Yes found two gems. ALT scene is coming back with a lot of opportunity right now IMO. So what is next for DASH? Are there any conferences we can attend?
http://btcmiami.com/speakers/
Let us know how it goes if you go..
Sweet!
Miami here I come.
October 21, 2015, 01:17:16 PM
Sounds like you are a dog with 2 bones
Yes found two gems. ALT scene is coming back with a lot of opportunity right now IMO. So what is next for DASH? Are there any conferences we can attend?
http://btcmiami.com/speakers/
Let us know how it goes if you go..
October 21, 2015, 01:12:49 PM
...
I see a world where DASH is worth $100 and DIGIBYTE is worth $1 ...Bitcoins will be digital gold type of thing.
Its amazing how the crypto world worked itself out like this so perfectly. Just natural for DASH to succeed now.
Sounds like you are a dog with 2 bones I see a world where DASH is worth $100 and DIGIBYTE is worth $1 ...Bitcoins will be digital gold type of thing.
Its amazing how the crypto world worked itself out like this so perfectly. Just natural for DASH to succeed now.
Yes found two gems. ALT scene is coming back with a lot of opportunity right now IMO.
So what is next for DASH? Are there any conferences we can attend?
October 21, 2015, 01:11:31 PM
...
I see a world where DASH is worth $100 and DIGIBYTE is worth $1 ...Bitcoins will be digital gold type of thing.
Its amazing how the crypto world worked itself out like this so perfectly. Just natural for DASH to succeed now.
Sounds like you are a dog with 2 bones I see a world where DASH is worth $100 and DIGIBYTE is worth $1 ...Bitcoins will be digital gold type of thing.
Its amazing how the crypto world worked itself out like this so perfectly. Just natural for DASH to succeed now.
Jump to: