vazaki3
Well-known member
"High Collateral Masternodes". The DCG misleadingly names them "High Performance Masternodes"
Read here. https://www.dash.org/forum/index.ph...orm-run-only-on-high-performance-nodes.53374/
Dash Core Group announces first v19 chain halt
- Thread starter GrandMasterDash
- Start date
Read here. https://www.dash.org/forum/index.ph...orm-run-only-on-high-performance-nodes.53374/
vazaki3
Well-known member
And what is the usage of BLS signatures? Do we need them for the 4k HCMNs or not?
You should first point to the code that caused the blockchain halt, and then we will discover whether it is related or not to the HCMN.
Last edited:
Yes exactly.
On several occasions I have publicly asked for alternatives to the server side code.
The problem is, dash is not a protocol, it is a product. I understand many people here like to think it's a protocol but in reality it is not and never has been. DCG is supposedly producing reference code for others but there are no incentives for others to build alternatives based on the protocol. The end result is that everyone involved stupidly treats DCG code as an official and trusted product, which is exactly why dash is a security. The chain halt as produced by DCG demonstrates the network's dependence for both the problem and the fix.
Last edited:
@GrandMasterDash
If you want a change, do it.
Do it yourself, organize a new group or propose an alternative solution and put it for voting.
Constant complaining without realistic solutions is just graphomania.
Telling the others what they should do, without doing anything yourself is just showing off.
If you want a change, do it.
Do it yourself, organize a new group or propose an alternative solution and put it for voting.
Constant complaining without realistic solutions is just graphomania.
Telling the others what they should do, without doing anything yourself is just showing off.
First of all, realistic alternative solutions were presented to DCG which were entirely dismissed.
Please, go ahead and tell us which feedback did DCG implement from their "discussion"? - none.
Request for delays for the sake of finding other solutions were also a possibility yet rejected by DCG.
Initiation of said discussions was magically dropped on us at the last minute as though it had just popped into Sam's head.
Zero discussions regarding content censorship initiated by DCG, only to be introduced in the HCMN discussions. A "we'll cross that bridge when we come to it" attitude, when such discussions should be had during the initial design phase.
In other words, DCG own this massive fucking cock-up and attempts to call out my "complaining" will not lesson it.
Sure, you can label my "complaining" (and from demo and others) as "showing off" if you like, doesn't change what happened and I personally am not looking for an apology. At this point, Sam should be on his fucking knees and apologizing profusely to the entire network, but you know what? - he will never fully own this and he will not step down as a result of it because he's too damn arrogant. I'm sure you can find a label for that personality type too.
Why are you expecting DCG to do whatever you tell them and want from them?
Since when ANYTHING in this world works this way @GrandMasterDash?
Since when ANYTHING in this world works this way @GrandMasterDash?
vazaki3
Well-known member
I tottaly agree with the above.
The Dash protocol should be first voted by the members of the Dash community. Thats why organized governance, and cheep governance questions are desperately needed.
After deciding the dash protocol, then various code implementations of the protocol should be coded by numerous independant coders.
Dash community should get rid of the centralized DCG. DCG is a severe point of failure of the Dash, DCG is a bug on itself.
Last edited:
vazaki3
Well-known member
The bug occured in the file
https://github.com/dashpay/dash/blob/v19.0.0/src/evo/deterministicmns.cpp
as @QuantumExplorer recently admitted.
Code:
Since it being asked of me sure part of the code at issue is here
if (dmn->pdmnState->pubKeyOperator.Get().IsValid() && !DeleteUniqueProperty(*dmn, dmn->pdmnState->pubKeyOperator)) {
mnUniquePropertyMap = mnUniquePropertyMapSaved;
throw(std::runtime_error(strprintf("%s: Can't delete a masternode %s with a pubKeyOperator=%s", __func__,
proTxHash.ToString(), dmn->pdmnState->pubKeyOperator.Get().ToString())));
}
Line 602 in deterministicmns.cpp
CDeterministicMNList CDeterministicMNList::ApplyDiff(const CBlockIndex* pindex, const CDeterministicMNListDiff& diff) const
{
CDeterministicMNList result = *this;
result.blockHash = pindex->GetBlockHash();
result.nHeight = pindex->nHeight;
for (const auto& id : diff.removedMns) {
auto dmn = result.GetMNByInternalId(id);
if (!dmn) {
throw(std::runtime_error(strprintf("%s: can't find a removed masternode, id=%d", __func__, id)));
}
result.RemoveMN(dmn->proTxHash);
}
for (const auto& dmn : diff.addedMNs) {
result.AddMN(dmn);
}
for (const auto& p : diff.updatedMNs) {
auto dmn = result.GetMNByInternalId(p.first);
result.UpdateMN(*dmn, p.second);
}
return result;
}
Line 405 in deterministicmns.cppThe file deterministicmns.cpp is inside EVO folder, isnt it?
So OBVIOUSLY the bug occured due to the (unnecessary and dangerous) complexity that the DashPlatform/Evo added to the Dash protocol.
So, @AgnewPickens , it was you who misinformed the community, it was not me.
Last edited:
vazaki3
Well-known member
More detailed info for the above.
https://github.com/dashpay/dash/tree/v0.13.0.0-rc1/src/evo
the deterministicmns.cpp file is used to allow reusing of external collaterals in DIP3.
In DIP3 (a specification that is supposedly written mainly by @QuantumExplorer aka Samuel) it is written ....
In DIP3 it is also written ...
See how the 4000 Dash collateral, called also 4k HPMN (or HCMN) appears in DIP3? See how the deterministicmns.cpp file is related to 4k HPMN?
The 10k collateral does not appear in DIP3, nor any other collateral solution. Only the 4k collateral appears, exactly the same 4k collateral solution that has been voted by the masternodes.
The 4k implementation was added in DIP3 here, last month, Apr 17 2023. So the DIP3 specification changed to support 4k collateral.
Can you see it now? The agents designed the dystopian future of dash a long time ago. The agents always control the dash community (through the masternodes votes) and always succeed for the dash community never to escape from its predestined dystopian future
https://github.com/dashpay/dash/tree/v0.13.0.0-rc1/src/evo
the deterministicmns.cpp file is used to allow reusing of external collaterals in DIP3.
In DIP3 (a specification that is supposedly written mainly by @QuantumExplorer aka Samuel) it is written ....
In DIP3 it is also written ...
See how the 4000 Dash collateral, called also 4k HPMN (or HCMN) appears in DIP3? See how the deterministicmns.cpp file is related to 4k HPMN?
The 10k collateral does not appear in DIP3, nor any other collateral solution. Only the 4k collateral appears, exactly the same 4k collateral solution that has been voted by the masternodes.
The 4k implementation was added in DIP3 here, last month, Apr 17 2023. So the DIP3 specification changed to support 4k collateral.
Can you see it now? The agents designed the dystopian future of dash a long time ago. The agents always control the dash community (through the masternodes votes) and always succeed for the dash community never to escape from its predestined dystopian future
Last edited:
TheNetworkIsBiggerThanYou
Active member
qwizzie
Well-known member
I think at this point its clear that with the introduction of Evo nodes and the coding that was involved so far to support this new feature,
a bug related to above occurred that caused the Dash blockchain to halt. I do not believe this was intentional, and also believe this bug did not materialized on devnet or testnet before and came out of the blue to both developers and Dash users.
Before the introduction of Evo nodes and the coding involved so far to support this new feature, i was under the assumption that Dash spork technology would protect the Dash network against chain halts. The whole benefit of Dash sporks is having the ability to switch a (new) feature off through disabling a specific spork and by doing that restore the Dash network to a safe state.
Dash Core v19 had no new spork that DCG could switch off to restore the Dash network to a safe state, and i am now not sure if a new spork could have prevented a Dash chain halt in the first place.
I am now left wondering if chain halts were always a risk that Dash spork technology could not ever fully mitigate, or if the lack of a specific spork for Dash Core v19 / Evo nodes undermined the safety of the Dash network. Or if the introduction of Evo nodes and the coding that was involved so far to support this, directly undermines how Dash can prevent chain halts in the future.
What i do find ironic is that during the discussions about having Dash Platform supported by all masternodes or by a group of masternodes with a higher collateral, the argument was consistently used by Sam that having Dash Platform supported by all masternodes could have the real risk that if there was a problem with Dash Platform, it could affect the Dash network as well (Platform down --> Dash network down). Using only Evo nodes would prevent this.
Yet what we witnessed now is Dash network down before Dash Platform is even up and running. And the Dash Network was down due to a bug in code meant to directly support Dash Platform.
Do we still think it is a good idea that the Dash Core Group cancelled their planned independent third party Code Audit of Dash Platform, citing reasons like time restraint, money restraint and simply feeling that bugs can be found and fixed through internal developer teams checking each others code ?
a bug related to above occurred that caused the Dash blockchain to halt. I do not believe this was intentional, and also believe this bug did not materialized on devnet or testnet before and came out of the blue to both developers and Dash users.
Before the introduction of Evo nodes and the coding involved so far to support this new feature, i was under the assumption that Dash spork technology would protect the Dash network against chain halts. The whole benefit of Dash sporks is having the ability to switch a (new) feature off through disabling a specific spork and by doing that restore the Dash network to a safe state.
Dash Core v19 had no new spork that DCG could switch off to restore the Dash network to a safe state, and i am now not sure if a new spork could have prevented a Dash chain halt in the first place.
I am now left wondering if chain halts were always a risk that Dash spork technology could not ever fully mitigate, or if the lack of a specific spork for Dash Core v19 / Evo nodes undermined the safety of the Dash network. Or if the introduction of Evo nodes and the coding that was involved so far to support this, directly undermines how Dash can prevent chain halts in the future.
What i do find ironic is that during the discussions about having Dash Platform supported by all masternodes or by a group of masternodes with a higher collateral, the argument was consistently used by Sam that having Dash Platform supported by all masternodes could have the real risk that if there was a problem with Dash Platform, it could affect the Dash network as well (Platform down --> Dash network down). Using only Evo nodes would prevent this.
Yet what we witnessed now is Dash network down before Dash Platform is even up and running. And the Dash Network was down due to a bug in code meant to directly support Dash Platform.
Do we still think it is a good idea that the Dash Core Group cancelled their planned independent third party Code Audit of Dash Platform, citing reasons like time restraint, money restraint and simply feeling that bugs can be found and fixed through internal developer teams checking each others code ?
Last edited:
@qwizzie
I think the idea of having audit is definitely good and necessary sooner or later. However there is absolutely no guarantee that audit will eliminate every possible risk and prevent every possible outage. Audits aren't miraculous processes to eliminate all possible risks - these are just additional layers of quality check.
There is always risk that needs to be taken into consideration.
The biggest question for me is if there is a third party competent enough to audit completely new product like Dash Platform. Auditors build their processes and audit methodology based on the experience gained in the real world, working with existing tools. As far as I know, there is no auditor in the world who has experience with this particular tool.
I think the idea of having audit is definitely good and necessary sooner or later. However there is absolutely no guarantee that audit will eliminate every possible risk and prevent every possible outage. Audits aren't miraculous processes to eliminate all possible risks - these are just additional layers of quality check.
There is always risk that needs to be taken into consideration.
The biggest question for me is if there is a third party competent enough to audit completely new product like Dash Platform. Auditors build their processes and audit methodology based on the experience gained in the real world, working with existing tools. As far as I know, there is no auditor in the world who has experience with this particular tool.
qwizzie
Well-known member
Has everyone read this : https://medium.com/dash-org/dash-network-update-79544025c611 ?
Also with Dashninja.pl updated to v19.1 we can take a look at the miners side of Dashninja.pl
Source : https://www.dashninja.pl/blocks.html
Looks like we lost a lot of Dash miners / a lot of miners still need to update to v19.1 / a lot of miners with incorrect ratio
Dash miners hashrate over time (3 months) :
Source : https://bitinfocharts.com/comparison/dash-hashrate.html#3m
Looks like Dash miners hashrate has recovered to previous level
I am wondering if we should even be talking about expediting the activation date of Dash Core v19, with above (low) statistics of miners.
Update :
Much better statistics of miners, from 54.33% to 76.23% in one day.
See : https://github.com/dashpay/dash/pull/5392
Thoughts ?
Also with Dashninja.pl updated to v19.1 we can take a look at the miners side of Dashninja.pl
Source : https://www.dashninja.pl/blocks.html
Looks like we lost a lot of Dash miners / a lot of miners still need to update to v19.1 / a lot of miners with incorrect ratio
Dash miners hashrate over time (3 months) :
Source : https://bitinfocharts.com/comparison/dash-hashrate.html#3m
Looks like Dash miners hashrate has recovered to previous level
I am wondering if we should even be talking about expediting the activation date of Dash Core v19, with above (low) statistics of miners.
Update :
Much better statistics of miners, from 54.33% to 76.23% in one day.
Last edited:
I really wish you would try to stick to the facts, the BLS serialisation issue not part of the platform release and was not required for Platform to go live, it is a nice to have, but not strictly required. The HCMN had nothing to do with this issue.
qwizzie
Well-known member
That would be true if the issue is only to do with BLS serialisation. However if we look at the Github pull request itself (https://github.com/dashpay/dash/pull/5392/commits), then there are a number of issues getting addressed :
fix: Rework bls_legacy_scheme switch points
chore: drop RepopulateUniquePropertyMap
feat: store protx version in CDeterministicMNState and use it to ser/deser pubKeyOperator
feat: show pubKeyOperator according to nVersion to match CDeterministicMNState serialization
test: check pubkeyoperator in masternodelist rpc (internal test i assume)
Sam already stated that part of the problem lays with the deterministicmns.cpp file (line 602 and line 405), a file which in my view was adjusted to either support Evo nodes and their higher 4K collateral directly or to support Dash Platform in general, introducing more code complexity.
Since Dash Core v19 is mostly about supporting Evo nodes, and the issues occurred with Dash Core v19 activation, i do think part of the issues are caused by increased code complexity, in order to support Evo nodes.
Unless all the issues that are getting addressed by above mentioned Github pull request, are all related to BLS serialisation and BLS serialisation only. A postponement of the update of BLS basic to BLS legacy to a future Dash Core v21 for example, would then have avoided the Dash chain halt during v19 activation. The bug(s) would then have materialized during Dash Core v21 activation.
Last edited:
vazaki3
Well-known member
Exactly.
The narrative that the blockchain halt had nothing to do with DashPlatform is an ostrich-like behavior.
It reminds me of the reaction of the ostrich trying to hide when in danger.
Last edited:
vazaki3
Well-known member
It depends on how you define compelling.
I like the encointer community.
Encointer Explorer
Last edited:
You're halfway there then making assumptions about the rest, why would it be better if it occurred during v21 activation? This entire PR and all those commits are to do with BLS serialization, the bug was an edge case in the serialization, in the masternodelist, which involves protxs and pubKeyOperators. Those 5 commits you've posted are actually helping xk's point and aren't "a number of issues getting addressed" - it's the same issue.
Bad BLS conversion on "ghost" nodes caused dashd to trip over them, using legacy keys instead of the new basic style on nodes that went away ~1000 blocks or so before the fork and are still in the mnlist.
What you have here is protxs, pubKeyOperator, nVersion, and dropping the repopulate (because it repopulated the mnlist and then failed) which is all related to the same issue, just in multiple places in the codebase. Would you rather we patched it in two lines of code or actually fixed the thing so this won't happen again?
qwizzie
Well-known member
I just used Dash Core v21 as example in case the Github pull request was indeed about BLS serialisation and BLS serialisation only (which i was not sure about). If you say that the Github pull request was indeed only about BLS serialisation, then i believe that to be the case.
What i personally would have preferred to see is a focus only on supporting Evo nodes in Dash Core v19 and a focus only on supporting Dash Platform launch in Dash Core v20. Instead features have been added to both Dash Core v19 and Dash Core v20 that are not strictly necessary to support Evo nodes and the launch of Dash Platform. Having BLS upgraded from basic to legacy does little for the Dash network right now and will only be fully utilized down the road, when Dash Core Group focus on blockchain inter-exchangeability. If the BLS upgrade was pushed back to a later update, i wonder if Dash Core v19 would have been in development as long as it did. In my view (assumption) having added the BLS upgrade caused delay of Dash Core v19 and ultimately a severe bug in BLS serialisation also caused the Dash blockchain to halt.
I do think postponing the activation of Dash Core v19 and taking the time to fully fix the issue was the right action of Dash Core Group. I just think Dash Core Group is putting too many features into large Dash Core updates, often causing a Dash Platform delay and in this case even a Dash blockchain halt.
Last edited: