[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[NibiruHybrid]

Evolution Offers and Promotions Platform Proposal

Looking at the larger proposals that are currently under consideration by the Dash masternode network I found “Evolution Offers and Promotions Platform” submitted by: srolinson for 3 monthly payments of 845 DASH. I think this one requires a lot of review as it is very complex.

A simple way of thinking about it is adding a “special deals” tab to your current Dash wallet where you get offers from businesses that you can purchase with Dash.  I reached out to the proposal owner to get more information for this article.  I then found out that Craig Mason had just done this video interview with Brandon Willey the CEO of the company behind the proposal.

Read more: https://www.dashforcenews.com/evolution-offers-promotions-platform-proposal/

[1675633227]

1675633227

[NibiruHybrid]

Get Ready For The Great American Pilgrimage
With Stephen Baldwin & Max Keiser 👍
Coming soon to RT America 📽️ Starts 26th Nov
Powered by Dash 🏆

Watch the trailer here: https://twitter.com/markdavidmason/status/931895488533663744

[NibiruHybrid]

Dash Force News 3 Amigos Podcast Episode 26

Video repost of episode 26 of the three amigos podcast. This week we had special guest Scott Farnsworth from Dash Aerosports join us towards the end of the podcast. In this episode we discuss Joel’s recent trip to Europe and the House of Nakamoto. We also had a passionate talk about business adoption efforts and ideas on increasing merchants accepting Dash. Scott provided an update on his new proposal and future ideas on how to increase Dash awareness including taking his Dash Force One VR simulator to an upcoming Bitcoin conference.

The 3 amigos podcast takes place every Friday at 3pm EST / 8pm GMT.

If you haven’t done so by now, can you please make sure you like and subscribe to the Dash Force News YouTube channel. Thank you to the Dash community for your continued support.

Read more: https://www.dashforcenews.com/dash-force-news-3-amigos-podcast-episode-26/

[rodmanqs]

Dash Mining Reaches Petahash Range. Dash’s network hashrate has crossed the petahash line, indicating strong potential for future growth. Dash’s rise in mining hashpower has similarities to Bitcoin in 2013. In mid-September, the hashrate similarly crossed the petahash barrier. Around that time Bitcoin’s price was around $130, less than half of what Dash is now. Within a couple months, however, that price was over $1,000.
A surging network hashrate indicates a lot of investment, both in time/effort and resources, in Dash’s network and long-term viability, including a significant amount of entrepreneurial risk from miners purchasing hardware which may not turn a profit for some time. In particular, present hashrate makes Dash not very profitable to mine (possibly even profit-negative), meaning that many miners are counting on a significant price increase in the near future. While many other factors are at play here, a strong hashrate could mean that a Dash price surge is on the horizon.

[AzzAz]

Dash Mining Reaches Petahash Range. Dash’s network hashrate has crossed the petahash line, indicating strong potential for future growth. Dash’s rise in mining hashpower has similarities to Bitcoin in 2013. In mid-September, the hashrate similarly crossed the petahash barrier. Around that time Bitcoin’s price was around $130, less than half of what Dash is now. Within a couple months, however, that price was over $1,000.
A surging network hashrate indicates a lot of investment, both in time/effort and resources, in Dash’s network and long-term viability, including a significant amount of entrepreneurial risk from miners purchasing hardware which may not turn a profit for some time. In particular, present hashrate makes Dash not very profitable to mine (possibly even profit-negative), meaning that many miners are counting on a significant price increase in the near future. While many other factors are at play here, a strong hashrate could mean that a Dash price surge is on the horizon.

Long ago I said that I might sell few DASH when it reach $500... That sounded funny. But more funny was to watch it @500 and saying " sh*t this will soon be impossible to buy. I will never reach my masternode back"

So these miners might seem stupid but what they gave for it? Dollars? Bitcoins?

[K5Canada]

looks like more and more people are discovering this coin.

Yep, the more I read on Dash, the more I like it! Will be a good fight with Litecoin for the 5th place on CoinMarketCap...

[sidhujag]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

[solowhizkid]

Dash Contractor Points Remittance Users to Crypto ATMs Over “Funding the Wall”

https://freekeene.com/2017/11/18/dash-contractor-encourages-remittance-users-to-choose-crypto-atms-over-funding-the-wall/

#dash_force

[NibiruHybrid]

Cryptocurrency Should Avoid Bureaucracy

After a recent kerfuffle over business development dealings and communication issues with Dash Core, a discussion in the Dash community was sparked about greater accountability and management for the various operations working in the greater network. Some voices in the community advocated for more direct management over the organizations funded by the network, establishing more direction into their operations by the masternodes.

While I understand perfectly where this desire comes from, I’m very much against the concept of overregulation of a free system that has been the envy of the cryptospace.

Read more: https://www.dashforcenews.com/cryptocurrency-avoid-bureaucracy/

[GT-RR]

Seems to me that Dash and Ripple are in the same category (digital money). Which is best ? (The technology I mean)

[sidhujag]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

[Cryptorials]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

Lol. I know there's a lot of trolls here so there's maybe some reason to be so short, but I still love to see someone getting a pin stuck in their arrogance bubble. Also Syscoin is awesome, great work Sidhujag.

[NibiruHybrid]

Dash News Weekly Recap E13 📈🚀👀 Dash 12.2 Update, New Exchanges, Dash Core Q3 Report & More!

This is a repost of this weeks edition of the Dash Force News Weekly Recap video from our YouTube channel. This show is dedicated to keeping you up to date with Dash news highlights from the past week.

Press That Like Button! Smash For DASH!
Thanks For Watching Please Hit Subscribe & Share Video!

Watch here: https://www.dashforcenews.com/dash-news-weekly-recap-e13-%F0%9F%93%88%F0%9F%9A%80%F0%9F%91%80-dash-12-2-update-new-exchanges-dash-core-q3-report/

[sidhujag]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

Lol. I know there's a lot of trolls here so there's maybe some reason to be so short, but I still love to see someone getting a pin stuck in their arrogance bubble. Also Syscoin is awesome, great work Sidhujag.

Thanks I gotta give credit to evan for having the vision. Now I take that vision and build upon it with my own. I feel like evolution will be big if and only if they design it so masternodes are onchain and rid of all this p2p mess. It will help with many things and make consensus code so much easier and safer. Either way thr pow+bonded validator system is probably the ideal nakamoto consensus design. Lets enjoy it because going fwd money will be in our corners.

I had hoped he was at the dash booth at money2020 but he wasnt there. Maybe some other time.

[qwizzie]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

I'm a little confused, all i see in the mentioned commits for syscoin is either the adding of the SYSCOIN name (which is definetely not something to brag about) and giving the sync more time with the *2
in the line if(GetTime() - nTimeLastBumped > MASTERNODE_SYNC_TIMEOUT_SECONDS*2) {  (which i'm not sure is even needed for Dash)

That is literally all you did with the Dash code. So where are exactly the bugs you found and why are we not noticing the effects of your discovered bugs on Dash mainnet ?
Current code v0.12.2.1 is running pretty stable and masternodes are kept in good synchronisation, so far i can tell from the number of active masternodes and from my own masternodes.

Edit 1 : okay, i think i found the piece of code you are referring to :



I will give someone from the Dash core-team the chance to confirm if you found a valid bug or not.

Edit 2 : seeing UdjinM6 reply it looks like you were correct and found a valid bug, my apologies and my thanks.


 

[UdjinM6]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

Nice, thanks!

[sidhujag]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

Nice, thanks!

steps to reproduce, start a testnet with one masternode and notice in logs that you will get invalid message during mnw and also that setAskFor bug, it wont resync the list during mnsync but instead only try at the very beginning when headers are syncing, for some reason it skips asking for inv ther ebecause i think its still in waiting mode before list mode starts. I hope tha tmakes sense, do you want me to create a PR?

[sidhujag]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

I'm a little confused, all i see in the mentioned commits for syscoin is either the adding of the SYSCOIN name (which is definetely not something to brag about) and giving the sync more time with the *2
in the line if(GetTime() - nTimeLastBumped > MASTERNODE_SYNC_TIMEOUT_SECONDS*2) {  (which i'm not sure is even needed for Dash)

That is literally all you did with the Dash code. So where are exactly the bugs you found and why are we not noticing the effects of your discovered bugs on Dash mainnet ?
Current code v0.12.2.1 is running pretty stable and masternodes are kept in good synchronisation, so far i can tell from the number of active masternodes and from my own masternodes.

Edit : okay, i think i found the piece of code you are referring to :



I will give someone from the Dash core-team the chance to confirm if you found a valid bug or not.


 

Sorry doesn't seem you are a coder. Look I never inteded to brag dont know where you got that from. Regarding the commits comments // SYSCOIN I am very glad you asked that since not many coders in alt land actually use that idea. It is a way for me to know which parts have changed so I can easily rebase from scratch by looking for all // SYSCOIN tags and updating code without costly merge conflicts. This way I can ensure I start from a good base (dash or btc) and then add my specific stuff on top. Hope that makes sense, its something Ive been using and creates very efficient reports from base without sacrificing security and wished more developers would do the same, after all we are dealing with peoples money.

So the two bugs I reproduced by creating a simple testnet and noticing that lists wont sync deterministically, there is a codepath that sometimes syncs up MNs but the normal path of execution skips over it. Maybe having more masternodes helps fix the problem but a problem is a problem to me, with 1 MN or with more, so I think its a valid bug. I had to fix the setAskFor issue first then the increase the timeout which finally got me to sync properly in a stable manor. Anyways I will work with the developers who wrote the code, I prefer Dash makes the changes IFF they see it is a valid issue or can respond with appropriate comments.

[qwizzie]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

I'm a little confused, all i see in the mentioned commits for syscoin is either the adding of the SYSCOIN name (which is definetely not something to brag about) and giving the sync more time with the *2
in the line if(GetTime() - nTimeLastBumped > MASTERNODE_SYNC_TIMEOUT_SECONDS*2) {  (which i'm not sure is even needed for Dash)

That is literally all you did with the Dash code. So where are exactly the bugs you found and why are we not noticing the effects of your discovered bugs on Dash mainnet ?
Current code v0.12.2.1 is running pretty stable and masternodes are kept in good synchronisation, so far i can tell from the number of active masternodes and from my own masternodes.

Edit : okay, i think i found the piece of code you are referring to :



I will give someone from the Dash core-team the chance to confirm if you found a valid bug or not.


 

Sorry doesn't seem you are a coder. Look I never inteded to brag dont know where you got that from. Regarding the commits comments // SYSCOIN I am very glad you asked that since not many coders in alt land actually use that idea. It is a way for me to know which parts have changed so I can easily rebase from scratch by looking for all // SYSCOIN tags and updating code without costly merge conflicts. This way I can ensure I start from a good base (dash or btc) and then add my specific stuff on top. Hope that makes sense, its something Ive been using and creates very efficient reports from base without sacrificing security and wished more developers would do the same, after all we are dealing with peoples money.

So the two bugs I reproduced by creating a simple testnet and noticing that lists wont sync deterministically, there is a codepath that sometimes syncs up MNs but the normal path of execution skips over it. Maybe having more masternodes helps fix the problem but a problem is a problem to me, with 1 MN or with more, so I think its a valid bug. I had to fix the setAskFor issue first then the increase the timeout which finally got me to sync properly in a stable manor. Anyways I will work with the developers who wrote the code, I prefer Dash makes the changes IFF they see it is a valid issue or can respond with appropriate comments.

Thank you for your reply, i'm indeed not a coder and i overlooked at first the code part that actually contained your mentioned bug and your implemented fix.
My apologies for my post, i overreacted and the use of the // SYSCOIN tags makes much more sense now. Also thank you for describing the two bugs in more detail.

Edit : looks like your discovered bugs gets addressed here :



FYI

[UdjinM6]

Anybody playing with latest 012.2 branch notice that the mn sync list wont work on startup? Noticed bugs in the code.

............................... show us the code with the bugs.......... or stop being a Troll......


Can't believe I'm actually responding to trolls that will never actually respond with code that does not exist - breath-taking - I know :-P

gosh and gee-whiz guys

Sure. Syscoin used dashes 0.12.2 code as v1 masternodes. In v2 im going to redo masternode design more like what evolution is about but better. Im finding the p2p design of dash is overly complex for what it needs to do and theres a better way to solve the same problem and scale across new services.

https://github.com/syscoin/syscoin2/commit/f248473f50490367563af85eb116e346ee8dcacd

Im finding mnsync list doesnt give enough time before mnw starts being requested causing incorrect sig errors for votes coming in.

https://github.com/syscoin/syscoin2/commit/90216592da0afcf1429aec60cc077fb328f27272

Here setAskFor is not cleared on initial requests before mn list is requested. Therefor on subsequent requests during mn list sync state the invs on those mns are not requested because setAskFor already has the objects.

Ok your turn.

Nice, thanks!

steps to reproduce, start a testnet with one masternode and notice in logs that you will get invalid message during mnw and also that setAskFor bug, it wont resync the list during mnsync but instead only try at the very beginning when headers are syncing, for some reason it skips asking for inv ther ebecause i think its still in waiting mode before list mode starts. I hope tha tmakes sense, do you want me to create a PR?

Yep, I see. The fix is self-explanatory itself actually but thanks for additional info about steps to reproduce.

re PR: oops, I already created one https://github.com/dashpay/dash/pull/1730, please review. In general, if you see anything that can be fixed/improved (especially in Dash-specific code, and doesn't conflict with bitcoin PRs) - please feel free to submit a fix, PRs are highly welcome
Note: there is also a part for "mnv" invs/messages which is missing in your fix, and a TODO for payment blocks inv which I'd like to fix later changing the way its hash is represented first (in some another PR). These two are not that critical but probably worth fixing too to make code a bit more consistent.

re Dash network code is overly complex: agree, that's a legacy thing and one of our major goals now is to incrementally refactor all this stuff to make code easier to read/review but this takes time.