• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Dash Core v20.1.1 Release Announcement

For Dashmate users :

Optionally perform a LLMQ PoSe check, to see if your Masternode / Evonode is currently not involved in a LLMQ quorum ->

dashmate stop
npm install -g dashmate (after this you get a warning that a newer version of npm exists, that you can optionally install)
dashmate update
dashmate start

After a few minutes :

dashmate status (here you should see that dashmate has updated to v20.1.1)
dashmate status masternode
 
Last edited:
This version fixes a deadlock / bug which rarely resulted in nodes becoming non-responsive, and resulted in some MNs becoming PoSe banned.

The LLMQ bullshit strikes again! YET ANOTHER BUG occured because of LLMQ stupidity!!!

Quorum rotation was introduced by @QuantumExplorer in order to solve the smelling shit of LLMQ.

dips/dip-0024.md at master · dashpay/dips · GitHub
" DIP-0024 Motivation
Before implementing and activating the solution presented in this paper, a very well-timed attack could lead to a double sign when new quorums replace old ones. At the same time, since masternode members were pseudo-randomly selected for quorums, some masternodes could be chosen for a large number of quorums while others were selected for none.

This DIP introduces a quorum rotation strategy in which only a quarter of members change at a time. This DIP also homogenizes the distribution of masternodes into quorums. Of all the solutions considered, this one was selected since it integrates more seamlessly into the current system."




So LLMQ is the responsible, in the first place. Long Living Masternode Quorums...A shit was created, and we still smell that shit!
Read the stupid motivation that was the underlying reason in order to create LLMQ

dips/dip-0006.md at master · dashpay/dips · GitHub

"DIP-0006 Motivation
Before the activation of Long Living Masternode Quorums as described in this document Masternode Quorums were already used in Dash for InstantSend and Masternode payment voting. These were however short living and very small (10 members). They were created per InstantSend input and required the network to fully propagate one vote per quorum member.
Those quorums did not scale very well, as complete propagation of all votes to the full network with larger quorums would have very likely overloaded the network. It was also not practical to store voting results on-chain, as too many signatures would have had to be stored in blocks.
New functionality and use cases required much larger quorums and also the storage of voting results on-chain.
Long Living Masternode Quorums and BLS M-of-N Threshold signatures provide a solution which reduces the network message quantity to 1 message per signing session (e.g. InstantSend input), regardless of the quorum size. Only the quorum itself has to keep track of all the messages which are part of a signing session. The quorum can then discard all intermediate messages (signature shares) after a final recovered threshold signature has been created and only this recovered threshold signature needs to be propagated network-wide."


THE LLMQ DESIGNERS SIMPLY DIDNT WANT WHATEVER KIND OF DASH VOTES TO BE STORED ON CHAIN!
THIS WAS THEIR UNDERLYING FILTHY MOTIVATION. VOTES SHOULD NOT BE STORED. AN AGENTS' PREREQUISITE!


Due to this stupidity I was forced to create mnowatch.sh and store some of the Dash votes. I did a job that DCG should have done in the very first place.

VOTES SHOULD BE STORED IN BLOCKCHAIN.
STORED FOR EVER.
BETTER STORE VOTES THAN TRANSACTIONS!
 
Back
Top