Quote from: BrainShutdown on September 24, 2017, 10:44:56 PM

Quote from: sidhujag on September 24, 2017, 09:26:32 PM

Quote from: qwizzie on September 24, 2017, 08:55:29 PM

Quote from: sidhujag on September 24, 2017, 07:29:43 PM

Quote from: qwizzie on September 24, 2017, 05:55:56 PM

Also the InstantSend vulnerability was described in more detail at the Dash Conference : https://www.youtube.com/watch?v=d8ExmIqRqOk
(see the 40 minutes marker)

Basicly it has to do with how InstantSend can revert back to previous blocks (even after it got confirmed through proof of work).
A masternode owner with six masternodes could take advantage of that by calculating high scores for their own masternodes
by making a lot of InstantSend transactions offline.

Currently the fix to that vulnerability is :

* making it impossible for Instantsend to revert back to older blocks
* the calculatescore now includes a need for 15 confirmations, before it can calculate the score. This means a pack of 6 masternodes can not calculate/influence their score
offline anymore.

InstantSend is currently disabled through a spork and will be fixed in Dash update 12.2

Note 1 : as the fix is still work in progress, the code could still be subject to changes.
Note 2 : above mentioned InstandSend vulnerability and the planned fix is what i summarized from the presentation, it could be subject to misinterpretation from my side.

How can you use the blockhash for quorum when you do not know masternode lists on a per block basis.. you only have the latest? Imagine i had to resync.. how will quorums be validated in the past when the past mn list is not available?

I'm assuming there is a mn list that gets synced during startup of your wallet. In case of a sync from scratch where the mn list does not exist, it will be newly created and then synced.
How the blockhash for quorum interacts exactly with that masternode list, so that it can obtain all its history .. i dont know.
Hopefully someone in here can answer that for you. You can also create a thread on the dashtalk forum, frankly its a much better forum to get answers to technical questions like these
as the core-team hangs out there much more.

Yea i know it forces sync of latest list but how say it ensures certain masternodes were selectes at a set.block thru a random selection is still not clear. I think since its p2p by definition it cannot form consensus and is tradeoff of network storage requirements vs security.

Ahh so looks like its a "soft consensus" so its vulnerable to replay attacks and the network just assumes noone will change the payout and quorum structures manually on their nodes because network wont know the difference if you did.

https://hackernoon.com/hong-kong-research-and-planning-4206e065aa9c

He seems to realize the problem and is doing it via a hard consensus so not p2p based list anymore in evolution im guessing. I will make a post on dashtalk i guess to learn more.

It's deterministic based on mined block hash so... (experts correct me if I'm wrong please)

Its not historically deterministic 100% it cannot be because theres only 1 list and quorums cannot be reproduced in the past. This means there is no way to verify that previous quorums were correct only that the current ones are correct. Previous ones it seems are just taken as is without revalidating.