Core 18.2.0 withdrawn! Cannot sync past block 1800330 on mainnet

strophy

strophy

Administrator
Staff member
Dash Core Group
Dash Support Group
https://twitter.com/x/status/1611286052525969408

WARNING!

Dash Core 18.2.0, released two days ago on 2023-01-04, contains an issue that does not permit it to sync past block 1800330. Please do not use this version on mainnet! The build will be withdrawn and devs are investigating to find a solution. Further communication will be posted in this thread.

If you have already updated to 18.2.0, please downgrade to 18.1.0. No rescan or reindex is necessary.
 
kot said:
What are you proposing instead of it?
Click to expand...

Hi Kot, I am not smart enough to solve such a problem, however, I know in my experience that when I come up with a super complex solution to some problem, it usually means I was thinking about the problem wrong and after some careful thinking I can come up with a much better solution. Quorum Rotations strikes me as a very complex solution to a problem which has been to date a rich source of bugs. I also see many parallels in the Platform code. o_O
 
xkcd said:
Hi Kot, I am not smart enough to solve such a problem, however, I know in my experience that when I come up with a super complex solution to some problem, it usually means I was thinking about the problem wrong and after some careful thinking I can come up with a much better solution. Quorum Rotations strikes me as a very complex solution to a problem which has been to date a rich source of bugs. I also see many parallels in the Platform code. o_O
Click to expand...

We write code together for mnowatch.org, since 2018. I write easier code than DCG does, I write the mnowatch code just for hobby (while DCG is paid a lot), but still I have the dignity (and the self knowledge of my mental limits) not to write code that has bugs I am not aware of. In my mnowatch code, how many times have you discovered a bug that it is unknown to me, @xkcd ?

I think it is unacceptable the Dash community to tolerate a DCG that codes and create bugs.
We are talking about MONEY SOFTWARE, so A BUG FREE CODE IS THE NUMBER ONE PRIORITY.
Whoever developer writes buggy software, should have financial consequences.
 
Last edited:
The thing that surprised me the most about this withdrawn v18.2 release is that the issue of not getting synced past block 1800330, was apparently already known on Testnet.

Knipsel.JPG

Source : www.reddit.com/r/dashpay/comments/103y05l/dash_core_v182_release_announcement/

So what went wrong here ? Did the developers not know about this sync issue on Testnet ? Or did they think they fixed it ?
Could this have been prevented by using a dedicated v18.2 test thread in here : https://www.dash.org/forum/topic/testing.53/ ??

For this situation to occur (having to withdraw Github final release binaries due to a severe sync bug), something must have gone very wrong in the testing phase of this v18.2 update.

And this coming from the same group of developers that do not want to externally security audit the Dash Platform code, because they are so confident they can catch all the bugs themselves. Yet they did not catch this severe sync bug on a minor Dash Core update.

It does not boost confidence.
 
Last edited:
Don't worry, I'm sure Sam has a totally logical explanation for this. OTOH, this supports exactly what he claimed about Platform bugs taking down the entire network. I have renewed faith that DCG can produce such bugs.
 
qwizzie said:
The thing that surprised me the most about this withdrawn v18.2 release is that the issue of not getting synced past block 1800330, was apparently already known on Testnet.

View attachment 11573
Source : www.reddit.com/r/dashpay/comments/103y05l/dash_core_v182_release_announcement/

So what went wrong here ? Did the developers not know about this sync issue on Testnet ? Or did they think they fixed it ?
Could this have been prevented by using a dedicated v18.2 test thread in here : https://www.dash.org/forum/topic/testing.53/ ??

For this situation to occur (having to withdraw Github final release binaries due to a severe sync bug), something must have gone very wrong in the testing phase of this v18.2 update.

And this coming from the same group of developers that do not want to externally security audit the Dash Platform code, because they are so confident they can catch all the bugs themselves. Yet they did not catch this severe sync bug on a minor Dash Core update.

It does not boost confidence.
Click to expand...

I would like to better understand what went wrong here too, the chatter I am hearing is that this issue was known, but the chances of it happening on mainnet were believed to be extremely small, so they went with the release anyway, instead of using a fork, which will now be required for 18.2, so the changes in 18.2 will be rolled up into v19.
 
  • Like
Reactions: kot
xkcd said:
the chatter I am hearing is that this issue was known, but the chances of it happening on mainnet were believed to be extremely small, so they went with the release anyway,
Click to expand...

If it was a known bug , where has it been reported? A known bug that is not reported anywhere, it is rather an unknown bug. Or at least a bug from coders who do not have the professional dignity to report the bug.
 
xkcd said:
Hi Kot, I am not smart enough to solve such a problem, however, I know in my experience that when I come up with a super complex solution to some problem, it usually means I was thinking about the problem wrong and after some careful thinking I can come up with a much better solution. Quorum Rotations strikes me as a very complex solution to a problem which has been to date a rich source of bugs. I also see many parallels in the Platform code. o_O
Click to expand...

Hi @xkcd.
There is no perfect code nor perfect software on this world.

I rather see it a novel, and therefore complicated, tech. Cryptography isn’t simple, p2p isn’t simple, blockchain concepts aren’t simple, tools for payments and accounting aren’t simple, building development platform backend isn’t simple by any means. And Dash is a mix of all of that.
I am pretty sure that, with more time, the code will be simplified and matured wherever possible. It’s inevitable.
Now I want the platform to be released, so we can start serious testing. I know that particular change for 0.18.2 was done for the core but it is connected to the whole development direction of the platform release and development.

In my opinion, after the release, devs should implement only smart contracts and STOP doing other innovations and new features. Focus should be on polishing and, as you suggest, simplifying the code and tech, getting customer feedback and promotion like crazy.
If the platform is appreciated by the market (which in this case means developers who build new apps on top of the platform), then we can go further and build new features (based on the customer needs and feedback). If it is not used and appreciated, there is no need to invest more money into further development.
We can win only by the market-oriented approach. No more innovations are needed at the moment - Dash has more than enough. What is needed are users and developers using Dash (for payments and building apps).
 
Last edited:
kot said:
Hi @xkcd.
There is no perfect code nor perfect software on this world.

I rather see it a novel, and therefore complicated, tech. Cryptography isn’t simple, p2p isn’t simple, blockchain concepts aren’t simple, tools for payments and accounting aren’t simple, building development platform backend isn’t simple by any means. And Dash is a mix of all of that.
I am pretty sure that, with more time, the code will be simplified and matured wherever possible. It’s inevitable.
Now I want the platform to be released, so we can start serious testing. I know that particular change for 0.18.2 was done for the core but it is connected to the whole development direction of the platform release and development.

In my opinion, after the release, devs should implement only smart contracts and STOP doing other innovations and new features. Focus should be on polishing and, as you suggest, simplifying the code and tech, getting customer feedback and promotion like crazy.
If the platform is appreciated by the market (which in this case means developers who build new apps on top of the platform), then we can go further and build new features (based on the customer needs and feedback). If it is not used and appreciated, there is no need to invest more money into further development.
We can win only by the market-oriented approach. No more innovations are needed at the moment - Dash has more than enough. What is needed are users and developers using Dash (for payments and building apps).
Click to expand...

What a stupid rant/pomposity/bombast!
All this pomposity in order to justify a filthy bug?
Pathetic!

Dance until death!
#13
 
Last edited:
xkcd said:
Specifically, the quorum rotations introduced by QE is a rich source of bugs.
Click to expand...


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!
 
Last edited:
qwizzie said:
And this coming from the same group of developers that do not want to externally security audit the Dash Platform code, because they are so confident they can catch all the bugs themselves. Yet they did not catch this severe sync bug on a minor Dash Core update.

It does not boost confidence.
Click to expand...
This makes me worried too! We should have audit from people not close to the code. People get blind by their own work! I know as i was a dev.

kot said:
There is no perfect code nor perfect software on this world.
Click to expand...
Maybe not but how often has BTC went rogue? how about LTC? For "money" to be taken seriously we can't downplay the occurrence of bugs. Pushing better QA for after platform is really a bad bad idea. We can't think that way. Quality assurance should be even more important now then ever. Making things complex will only introduce more bugs that must be captured. If we don't have proper routines and measures now it will only be worse later. If anything i would say make the QA better now before doing anything else. Not sure how much test automation we have even but all i can say is every network problem will haunt us forever as maxis will point to them and say Dash is not to be trusted as money.
For me platform is secondary but maybe thats me.
 
  • Like
Reactions: MN1
vampyren said:
Maybe not but how often has BTC went rogue? how about LTC?
Click to expand...

Actually, they both had bugs and BTC even experienced one outage in the past.
There is no perfect code. That being said, QA should be stellar - I agree with you on that.
 
kot said:
Actually, they both had bugs and BTC even experienced one outage in the past.
There is no perfect code. That being said, QA should be stellar - I agree with you on that.
Click to expand...
You mean the inflation bug that happened August 15th, 2010 ?

As @vazaki3 says i would say Bitcoin has close to perfect code delivery. Sure we are humans and can make mistakes but again downplaying the issue is not helping us. Let's look at what happened and improve! Take it as a opportunity to improve.
 
  • Like
Reactions: kot
You must log in or register to reply here.
Back
Top