Quote from: asepticskeptic on October 21, 2015, 06:43:19 PM

Whats up suicides? Apparently you're on shitcoiner watch!

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.

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

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.

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.

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....