[ANN] [POW] [MSR] Masari - simple, scalable, and secure cryptocurrency

[thaer]

Has the fork already happened?

Not yet, it's running behind schedule and is due on block 63500 (it's currently at 62880)

[maximo2121]

Has the fork already happened?

Not yet, it's running behind schedule and is due on block 63500 (it's currently at 62880)

Thanks!

[zyvervago]

I stopped mining Masari because at some point I only could mine 10% of the coins I mined before Nicehash maniacs.
And this happens in many coins, suddenly difficulty and hashrate rockets that's impossible to mine for little miners like me.
It's good to know that devs took action about Nicehash, I´ll return to Masari soon. 

[thaer]

Happy fork day - we've successfully forked into v3 of Masari!

[thaer]

The new difficulty algorithm's doing great so far, happy mining everyone!

[nanona]

63742   59 to go   25004630   2c0ae9e8ccc57cfc015fb6140ece08615cee0cdd2f548209d2542cbff25c57e7   12/4/2017, 09:59:01 AM   68%
63732   49 to go   19511411   02b99f385aab0217e2f7a755294e49d4a4a21d196917ded5e7c3411ed000d261   12/4/2017, 09:56:21 AM   58%

10 blocks within less than 3 minutes looks like a very short but strong attack. Attacker now using diff < 20M as trigger to start and maybe diff > 25M to stop?
Fortunately the new DAA doesn't get "triggered" anymore and keeps cool. Much better than before, but of course the "cheaters" are still stealing rewards from the "constant-on" miners and it can't be avoided if we want to have a quasi-constant block time, as zawy wrote.

[Luisjc69]

63742   59 to go   25004630   2c0ae9e8ccc57cfc015fb6140ece08615cee0cdd2f548209d2542cbff25c57e7   12/4/2017, 09:59:01 AM   68%
63732   49 to go   19511411   02b99f385aab0217e2f7a755294e49d4a4a21d196917ded5e7c3411ed000d261   12/4/2017, 09:56:21 AM   58%

.........Much better than before, but of course the "cheaters" are still stealing rewards from the "constant-on" miners and it can't be avoided if we want to have a quasi-constant block time, as zawy wrote.

Really cheaters are "mining" this coin and also stealing it?? (this coin at moment in not profitable, why the guys want steal it?)

Thx....

[nanona]

63742   59 to go   25004630   2c0ae9e8ccc57cfc015fb6140ece08615cee0cdd2f548209d2542cbff25c57e7   12/4/2017, 09:59:01 AM   68%
63732   49 to go   19511411   02b99f385aab0217e2f7a755294e49d4a4a21d196917ded5e7c3411ed000d261   12/4/2017, 09:56:21 AM   58%

.........Much better than before, but of course the "cheaters" are still stealing rewards from the "constant-on" miners and it can't be avoided if we want to have a quasi-constant block time, as zawy wrote.

Really cheaters are "mining" this coin and also stealing it?? (this coin at moment in not profitable, why the guys want steal it?)

Thx....

Those are quotes from the discussion on github. Read the link I provided.

You can call it personally how you want. I guess it depends on the value system you were socialized into.

[zawy]

I'm trying to evaluate the difficulty algorithm, so I installed masari this morning, but it is not letting me get new blocks past 63507 (7 blocks after the changeover?).
 All it says are things like this:


2017-12-04 14:36:45.897   [P2P0]   INFO    global   src/cryptonote_protocol/cryptonote_protocol_handler.inl:302   [50.17.174.202:38080 OUT] Sync data returned a new top block candidate: 63507 -> 63879 [Your node is 372 blocks (0 days) behind]
SYNCHRONIZATION started
2017-12-04 14:37:30.716   [P2P5]   INFO    global   src/cryptonote_protocol/cryptonote_protocol_handler.inl:302   [103.28.22.111:40256 INC] Sync data returned a new top block candidate: 63507 -> 63879 [Your node is 372 blocks (0 days) behind]
SYNCHRONIZATION started
2017-12-04 14:37:32.781   [P2P8]   INFO    global   src/p2p/net_node.inl:258   Host 34.234.145.76 blocked.


Miners simply changing coins in pursuit of best price/difficulty ratio is desired behavior, but it is also an "attack" or "unfair" to your dedicated miners who are not as efficiently selfish. In one sense dedicated miners are merely whining. But the coin should take interest because they protect against 51% attacks by adding consistent diversity and because they are less likely to sell the coin.  If difficulty algorithms could be perfect, the "attack" would not exist.  They can't be perfect because the only way to know current hashrate is to collect and calculate it from recent solvetime and difficulty data, so there is a delay in response.  If price changes a lot and the difficulty is slow, then big miners come in and get coin at low difficulty when the price jumps higher, and then leave when difficulty catches up, leaving constant miners with higher-than-appropriate difficulty for the length of the averaging window.  But if the difficulty is made to respond fast, it has to base the calculation on fewer data points, so it will naturally vary more statistical "accidents" on the small N window. Historically I have pushed for low N, less than 30. But after seeing BCH do exceptionally well on keeping a low number of delays by using a large with N=144, I am having a change of heart.  Coins have told me cryptonote's original code is effectively an N=300 and they have had to fork to get away from it. The problem (presumably) is that there is a good price increase so they get a lot of mining, but then it suddenly drops and no one want to mine it and it's going to take 300/2=150 blocks to get half-way back down to where it needs to be.  I have not yet looked into cyrptonote code and data from coins to see exactly what the problem is, but that makes me afraid of N=144 for small coins.  I have also been told BCH seems to be depending on Chinese pools actively deciding to not harm BCH.  Zcash and its clones have done well with Digishield v3 with N=17 which is effectively an N=63 algorithms.  For this reason I considered N=60 to be safe, and larger like I was seeking, but not risky like N=144.  The weighted nature of this algorithm makes it respond faster to hashrate changes, which also means it will overshoot and undershoot more than Zcash which means big miners will see more opportunities to jump on when price/difficulty ratio looks good (by more accidentally lower difficulty).  However, as it responds faster quicker, they will not be able to stay on and get as many blocks as they normally do on Zcash and its clones.  On Zcash they get about 20 "cheap-difficulty" blocks about 3 times a day, a "loss" of about 10% of Zcash coins, as the difficulty accidentally goes low about 3x per day.  So constant miners have to pay an excess difficulty of 10%.  For Masari's WWHM N=60 algorithm, I expect twice as many price/difficulty opportunities per day than if Digishield v3 N=17 ("N=63") code were used, but only 1/2 as many blocks stolen per opportunity. I see this in testing.  I do not know if not being able to get as many blocks "per attack" makes attacks less appealing, but I hope so.  Also, the digishield v3 does not adjust for 5 or 6 blocks after a sudden hashrate change begins. This may cause some minor oscillations in Zcash.  Although "blocks stolen" at "cheap-difficulty-cost" might be the same, testing indicates post-"attack" delays will be 1/3 as much in Masari as Zcash.  

Review the following chart to see "state of the art" difficulty algorithms. I have learned a lot in the past few days.  I just found two levels of improvement over what Masari is using (which is what I recommended), but I have been expecting the WWHM that Masari is using to be the best algorithm. For EMA and Dynamic
 EMA details (the two new improvements) see http://zawy1.blogspot.com/2017/11/best-difficulty-algorithms.html   Someday in my blog i'll write an "all things difficulty" article to cover everything.  

https://user-images.githubusercontent.com/18004719/33560871-02d98bf6-d8df-11e7-821a-147c0ae04165.gif

[cryptomaxsun]

Code:

Error: Couldn't connect to daemon: 127.0.0.1:38081

Error: Couldn't connect to daemon: 127.0.0.1:38081

Height: 63507/63507 (100.0%) on mainnet, not mining, net hash 315.93 kH/s, v3, up to date, 1(out)+0(in) connections, uptime 0d 0h 0m 2s

Height: 63507/63507 (100.0%) on mainnet, not mining, net hash 315.93 kH/s, v3, up to date, 1(out)+0(in) connections, uptime 0d 0h 0m 54s

Height: 63507/63926 (99.3%) on mainnet, not mining, net hash 315.93 kH/s, v3, up to date, 3(out)+0(in) connections, uptime 0d 0h 1m 3s

v0.1.3.0/masari-gui-win-x64-v0.1.3.0

there is no synchronization beyond the block 63507

[thaer]

There are a set of potentially malicious blocks (not part of the main chain) starting at 63500 that then invalidly re-connect back to the main chain at 63507 and are causing a synchronization bug.

Note: the main chain is in good standing and already mined coins are safe.

I'm working on a solution to the synchronization issue.

[thaer]

The synchronization bug has been identified and binaries with the patched version will be released shortly (as v0.1.3.1), apologies for the delay as I have a day job with its own set of responsibilities

[thaer]

Patch now available for download - main chain is unaffected and all your transactions remain the same!

Linux - https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-linux-x64-v0.1.3.1.tar.gz
Windows -  https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-win-x64-v0.1.3.1.zip
Mac - https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-mac-x64-v0.1.3.1.tar.gz

GUI Mac - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.1/masari-gui-mac-x64-v0.1.3.1.tar.gz
GUI Windows - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.1/masari-gui-win-x64-v0.1.3.1.zip

If you're stuck at block #63507, please delete the current lmdb data in ~/.masari or C:\ProgramData\masari and resynchronize with v0.1.3.1 binaries

You can also download a pre-synchronized database file to speed things up, at http://getmasari.org/data.mdb

Cheers,
Thaer

[cdrx]

Thank you, all good!

[online987659329]

Patch now available for download - main chain is unaffected and all your transactions remain the same!

Linux - https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-linux-x64-v0.1.3.1.tar.gz
Windows -  https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-win-x64-v0.1.3.1.zip
Mac - https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-mac-x64-v0.1.3.1.tar.gz

GUI Mac - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.1/masari-gui-mac-x64-v0.1.3.1.tar.gz
GUI Windows - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.1/masari-gui-win-x64-v0.1.3.1.zip

If you're stuck at block #63507, please delete the current lmdb data in ~/.masari or C:\ProgramData\masari and resynchronize with v0.1.3.1 binaries

You can also download a pre-synchronized database file to speed things up, at http://getmasari.org/data.mdb

Cheers,
Thaer

Nice work Thaer - fast and easy solution to the problem. You strengthen the believe with your steady development and clear communication for this coin

[p3ngu1n]

Patch now available for download - main chain is unaffected and all your transactions remain the same!

Linux - https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-linux-x64-v0.1.3.1.tar.gz
Windows -  https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-win-x64-v0.1.3.1.zip
Mac - https://github.com/masari-project/masari/releases/download/v0.1.3.1/masari-mac-x64-v0.1.3.1.tar.gz

GUI Mac - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.1/masari-gui-mac-x64-v0.1.3.1.tar.gz
GUI Windows - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.1/masari-gui-win-x64-v0.1.3.1.zip

If you're stuck at block #63507, please delete the current lmdb data in ~/.masari or C:\ProgramData\masari and resynchronize with v0.1.3.1 binaries

You can also download a pre-synchronized database file to speed things up, at http://getmasari.org/data.mdb

Cheers,
Thaer

Good work
Thank you dev.

[ramcrash]

GUI wallets have been patched to use v0.1.3.0!

Windows: https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.3.0/masari-gui-win-x64-v0.1.3.0.zip
sha256sum: 350aa0dc2ddba332c81222f9552458dc8092117361975ffad4cbcc1ddf5dc2f9

Working fine.
Is there any way to find out version of the wallet once it is running?

The quickest way to check is running masarid.exe and you should find it saying "Masari 'Airborne Angelfish' (v0.1.3.0-0e6ed8a)" as the version (the hash at the end needs to be this value to make sure you have the updated v0.1.3.0 daemon)

Thaer how do you think to fight Nicehash? they ruin a coin!

Why do you say Nicehash ruins the coin?

[thaer]

Thanks for the kind words!

@vitiriha the new algorithm is designed to deal with hash rate spikes from services like Nicehash, and we're be able to co-exist with them without worrying about mining fairness.

[thaer]

We have another hard fork coming on block #70000 as v4, estimated to be next week on Wednesday, December 13, 2017 3:48:34 AM UTC

This brings in necessary adjustments and fine tunes the new difficulty algorithm.

Release notes: https://github.com/masari-project/masari/releases/tag/v0.1.4.0
Linux - https://github.com/masari-project/masari/releases/download/v0.1.4.0/masari-linux-x64-v0.1.4.0.tar.gz
Windows -  https://github.com/masari-project/masari/releases/download/v0.1.4.0/masari-win-x64-v0.1.4.0.zip
Mac - https://github.com/masari-project/masari/releases/download/v0.1.4.0/masari-mac-x64-v0.1.4.0.tar.gz

GUI Mac - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.4.0/masari-gui-mac-x64-v0.1.4.0.tar.gz
GUI Windows - https://github.com/masari-project/masari-wallet-gui/releases/download/v0.1.4.0/masari-gui-win-x64-v0.1.4.0.zip

Thanks,
Thaer

[vitiriha]

Thanks for the kind words!

@vitiriha the new algorithm is designed to deal with hash rate spikes from services like Nicehash, and we're be able to co-exist with them without worrying about mining fairness.

great news ! thanks dev!